Python uWSGI中使用Pandas时的分段错误

在Flask下从Pandas中的HDF5存储（作为uWSGI进程运行）中进行选择时，我遇到了一个分段错误。它做了几块很好，但过了一段时间又遇到了问题。*是我自己的日志记录，基本上我们进入流程的第16轮，它将14531行的数据块与基表进行比较，然后保存结果。从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 development:5000端口运行该进程，它从头到尾都运行良好。这也不是内存不足的问题（每个uWSGI都分配了足够的内存，并且在运行期间不会耗尽内存）。 我知道我应该在不久的将来将uWSGI与芹菜或其他东西分离；）但如果它现在能起作用那就太好了！我也不认为是uWSGI harakiri（无论如何，这会给出不同的日志）

设置：

• 烧瓶：0.10.0
• uWSGI:1.9.18
• 熊猫：0.12.0
• Python:2.7.3
• Ubuntu 12.04LTS服务器，64位
• 32gb ram，4个8gb 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>

www数据
www数据
/tmp/li.socket
666
/srv/www/li
/srv/www/li
/srv/www/li/venv
锂
/srv/www/li/li.py
应用程序
4.
/tmp/li.pid
12000
8.
1.
/tmp/stats.socket
2000
8192
8192
8192

任何帮助都将不胜感激

编辑：在尝试一系列配置后，3个10gb工作线程不会遇到分段错误。这仍然很奇怪，因为工人们最多使用4.5gb，正常情况下使用1.8gb

---

编辑2：对于谷歌发现的任何人来说，最后我创建了一个fork前缓存解决方案，这意味着我可以有很多工作人员，但仍然非常节省内存。这确实意味着您必须在数据更改后重新启动uwsgi进程，尽管HDFStore对于写入来说不是线程或进程安全的。您可以读取多个进程，但一次只能从单个进程写入单个存储，请参见（此处）[；HDF5本身对于同步写入不安全是的，我确认前面的注释，您可以使用uwsgi.lock（）和uwsgi.unlock（）序列化写入（独立于进程或线程）您好，谢谢您的评论Jeff，Roberto。唯一的一点是：多个uwsgi进程没有并发写入（我内置了一个检查，确保每个HDF5文件都有一个唯一的写入进程）。此外，错误发生在读取过程中，而不是写入过程中……我将查看锁（）但这不应该导致它…顺便说一句，尝试删除--限制，因为它已知会导致某些应用程序出现问题（特别是64位），感谢roberto，建议还与nginx、uwsgi、web2py、pandas一起工作，我收到了这个错误“从上游读取响应头时，上游过早关闭连接”