“无法分配内存” Debian 6、64 位上的 psycopg2 和 libgcrypt.so 出现错误

发布于 2024-12-14 10:14:07 字数 1788 浏览 2 评论 0原文

我遇到了与 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

悲欢浪云 2024-12-21 10:14:07

它可能与 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文