“无法分配内存” Debian 6、64 位上的 psycopg2 和 libgcrypt.so 出现错误
我遇到了与 Python psycopg2 postgresql 驱动程序和 libgcrypt 模块相关的奇怪的生产特定错误。
我正在运行 Debian 6, 32 位来使用 uWSGI 和 Nginx 托管我的应用程序。我决定通过全新安装切换到 64 位。一切看起来都很好,除了 uwsgi.log 中的每个请求都低于 Python 回溯:
File ".../python2.7/site-packages/django/core/handlers/wsgi.py", line 272, in __call__
response = self.get_response(request)
File ".../python2.7/site-packages/django/core/handlers/base.py", line 169, in get_response
response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
File ".../python2.7/site-packages/django/core/handlers/base.py", line 203, in handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File ".../python2.7/site-packages/django/views/debug.py", line 59, in technical_500_response
html = reporter.get_traceback_html()
and so on...
因此,我转到 django/core/handlers/base.py (Django 版本 1.3.1)第 166 行,这似乎是最后一个异常处理程序一切都非常出色。我将其替换为:
except Exception, why:
并将“原因”写入文本文件。例外之处在于:
Error loading psycopg2 module: libgcrypt.so.11: failed to map segment from shared object: Cannot allocate memory
我阅读了几乎所有类似的错误/问题/博客文章,并且只能找到认为问题不完全相同但非常相似的一个: http://www.johngirvin.com /archives/dovecot-error-127-after-upgrading-to-debian-squeeze.html
我确实尝试过:
- Django==1.3.1
- Django==1.3
- psycopg2==2.4.2
- psycopg2==2.4.1
也重新启动,但没有结果。我的系统上安装了 postgresql-8.4、libgcrypt11 和 libgcrypt11-dev。 PostgreSQL 没有模型,除了带有 Django 默认模型的新 ./manage.py 同步数据库。有一半以上的内存只是空的。
而且...我还尝试在生产环境中运行 ./manage.py runserver ,效果非常好。 VPS在Linode上,所以我不认为有任何硬件问题。
任何帮助将不胜感激。
I am having a weird production specific error related to Python psycopg2 postgresql driver and libgcrypt module.
I was running Debian 6, 32bit to host my application with uWSGI and Nginx. I decided to switch to 64bit with fresh install. Everything seemed fine except I am getting below Python traceback for every request in the uwsgi.log:
File ".../python2.7/site-packages/django/core/handlers/wsgi.py", line 272, in __call__
response = self.get_response(request)
File ".../python2.7/site-packages/django/core/handlers/base.py", line 169, in get_response
response = self.handle_uncaught_exception(request, resolver, sys.exc_info())
File ".../python2.7/site-packages/django/core/handlers/base.py", line 203, in handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File ".../python2.7/site-packages/django/views/debug.py", line 59, in technical_500_response
html = reporter.get_traceback_html()
and so on...
So, I went to django/core/handlers/base.py (Django version 1.3.1) line 166 which seems the last exception handler that holds everything really exceptional. I replaced it with:
except Exception, why:
and write the "why" to a text file. The exception is exactly that:
Error loading psycopg2 module: libgcrypt.so.11: failed to map segment from shared object: Cannot allocate memory
I read almost every similar bug / issue / blogpost and could only find that one that believe not exactly same issue but quite similar:
http://www.johngirvin.com/archives/dovecot-error-127-after-upgrading-to-debian-squeeze.html
I did try with:
- Django==1.3.1
- Django==1.3
- psycopg2==2.4.2
- psycopg2==2.4.1
also rebooted which gave no result. I have postgresql-8.4, libgcrypt11 and libgcrypt11-dev installed on the system. PostgreSQL has no model except a fresh ./manage.py syncdb with Django default ones. There is more than half of the memory is just empty.
And... I also tried to run ./manage.py runserver on production which works perfectly fine. The VPS is on Linode, so I don't think there is any hardware problem.
Any help will be appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
它可能与 Python、Django、PostgreSQL、psycopg2 或 libsomething.so 无关。
检查您是否有类似 --limit-as 的选项在你的uWSGI配置中。在 64 位系统上,地址空间可以是两倍大。 512 或 1024 应该可以完成这项工作,因此请根据需要提高它。
It is perhaps not about Python, Django, PostgreSQL, psycopg2 nor libsomething.so.
Check if you have option like --limit-as in your uWSGI configuration. On 64bit systems address space can be twice big. 512 or 1024 should do the job so raise it as necessary.