python - uWSGI で Pandas を使用する際のセグメンテーション エラー

Question

Flask で uWSGI プロセスとして実行されている Pandas で HDF5 ストアから選択を行っているときに、セグメンテーション エラーが発生します。いくつかのチャンクは問題なく実行されますが、しばらくすると問題が発生します。*は私自身のログです。基本的には、14531 行のチャンクをベース テーブルと比較し、結果を保存するプロセスのラウンド 16 に到達します。HDF5 からデータを取得するときに問題が発生します。

*** Processing Chunk:  16
*** Saving # Rows:  14531
*** Measure list:  [-3, -2]
*** Retrieve Data
*** No Cache In Memory!
!!! uWSGI process 14786 got Segmentation Fault !!!
*** backtrace of 14786 ***
uwsgi(uwsgi_backtrace+0x29) [0x45f029]
uwsgi(uwsgi_segfault+0x21) [0x45f1b1]
/lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fb50c92c4a0]
/srv/www/li/venv/local/lib/python2.7/site-packages/pandas/hashtable.so(+0x10ae9) [0x7fb506cc9ae9]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/srv/www/li/venv/local/lib/python2.7/site-packages/pandas/index.so(+0xda6c) [0x7fb505f90a6c]
/srv/www/li/venv/local/lib/python2.7/site-packages/pandas/index.so(+0xac77) [0x7fb505f8dc77]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3bff) [0x7fb50cf88e2f]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(+0x5c86d) [0x7fb50cf4a86d]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(+0x12539f) [0x7fb50d01339f]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(+0xc7676) [0x7fb50cfb5676]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x3bff) [0x7fb50cf88e2f]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(+0x5c970) [0x7fb50cf4a970]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2b2a) [0x7fb50cf87d5a]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b) [0x7fb50cf8b37b]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5420) [0x7fb50cf8a650]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b) [0x7fb50cf8b37b]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(+0x5c970) [0x7fb50cf4a970]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2b2a) [0x7fb50cf87d5a]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(+0x5c970) [0x7fb50cf4a970]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x2b2a) [0x7fb50cf87d5a]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b) [0x7fb50cf8b37b]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b) [0x7fb50cf8b37b]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x614b) [0x7fb50cf8b37b]
/usr/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x855) [0x7fb50cf4a6b5]
/usr/lib/libpython2.7.so.1.0(+0x5c86d) [0x7fb50cf4a86d]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(+0x12539f) [0x7fb50d01339f]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(+0x13153c) [0x7fb50d01f53c]
/usr/lib/libpython2.7.so.1.0(PyObject_Call+0x53) [0x7fb50d02f053]
/usr/lib/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47) [0x7fb50d02f9a7]
uwsgi(python_call+0x1f) [0x470daf]
uwsgi(uwsgi_request_wsgi+0x11e) [0x472ffe]
*** end of backtrace ***
DAMN ! worker 1 (pid: 14786) died, killed by signal 11 :( trying respawn ...
Respawned uWSGI worker 1 (new pid: 15975)
mapping worker 1 to CPUs: 0

誰がこれを引き起こしているのか考えていますか? Flask 開発:5000 ポートを使用してプロセスを実行すると、最初から最後まで正常に実行されます。また、メモリ不足の問題でもありません (各 uWSGI には十分なメモリが割り当てられており、実行中に不足することはありません)。近い将来、プロセスをuWSGIからCeleryまたは何かに分離する必要があることは承知しています;）しかし、今のところうまくいくといいですね! 私はそれがuWSGIハラキリでもないと思います（とにかく別のログを与えるでしょう）

セットアップ:

• フラスコ: 0.10.0
• uWSGI: 1.9.18
• パンダ: 0.12.0
• パイソン: 2.7.3
• Ubuntu 12.04LTS サーバー、64 ビット
• 32 GB RAM、4 個の 8 GB uwsgi ワーカー

uwsgi 設定:

<uwsgi>
        <uid>www-data</uid>
        <gid>www-data</gid>
        <socket>/tmp/li.socket</socket>
        <chmod-socket>666</chmod-socket>
        <chdir>/srv/www/li</chdir>
        <pythonpath>/srv/www/li</pythonpath>
        <virtualenv>/srv/www/li/venv</virtualenv>
        <module>li</module>
        <wsgi-file>/srv/www/li/li.py</wsgi-file>
        <callable>app</callable>
        <master/>
        <processes>4</processes>
        <pidfile>/tmp/li.pid</pidfile>
        <harakiri>12000</harakiri>
        <reload-mercy>8</reload-mercy>
        <cpu-affinity>1</cpu-affinity>
        <stats>/tmp/stats.socket</stats>
        <max-requests>2000</max-requests>
        <limit-as>8192</limit-as>
        <reload-on-as>8192</reload-on-as>
        <reload-on-rss>8192</reload-on-rss>
        <no-orphans/>
        <vacuum/>
</uwsgi>

どんな助けでも大歓迎です！

Edit: after trying a series of configs, 3 workers with 10gb do not run into segmentation faults. it's still really weird as the workers do not use more than 4.5gb at most and 1.8gb normally...

Edit 2: For anyone finding this by google, in the end i created a pre-fork caching solution meaning that I could have many workers but still be very memory efficient. it does mean you have to restart a uwsgi process after data is altered though