姜戈 + FastCGI - 随机引发OperationalError

Question

我正在运行 Django 应用程序。 之前在Apache + mod_python下装过，一切OK。 切换到 Lighttpd + FastCGI。 现在我随机得到以下异常（它出现的地点和时间似乎都不可预测）。 由于它是随机的，并且只有在切换到 FastCGI 后才会出现，我认为它与某些设置有关。

谷歌搜索时发现了一些结果，但它们似乎与设置 maxrequests=1 有关。 但是，我使用默认值，即 0。

有什么想法可以在哪里寻找吗？

附言。 我正在使用 PostgreSQL。 可能也与此有关，因为在进行数据库查询时会出现异常。

 File "/usr/lib/python2.6/site-packages/django/core/handlers/base.py", line 86, in get_response
   response = callback(request, *callback_args, **callback_kwargs)

 File "/usr/lib/python2.6/site-packages/django/contrib/admin/sites.py", line 140, in root
   if not self.has_permission(request):

 File "/usr/lib/python2.6/site-packages/django/contrib/admin/sites.py", line 99, in has_permission
   return request.user.is_authenticated() and request.user.is_staff

 File "/usr/lib/python2.6/site-packages/django/contrib/auth/middleware.py", line 5, in __get__
   request._cached_user = get_user(request)

 File "/usr/lib/python2.6/site-packages/django/contrib/auth/__init__.py", line 83, in get_user
   user_id = request.session[SESSION_KEY]

 File "/usr/lib/python2.6/site-packages/django/contrib/sessions/backends/base.py", line 46, in __getitem__
   return self._session[key]

 File "/usr/lib/python2.6/site-packages/django/contrib/sessions/backends/base.py", line 172, in _get_session
   self._session_cache = self.load()

 File "/usr/lib/python2.6/site-packages/django/contrib/sessions/backends/db.py", line 16, in load
   expire_date__gt=datetime.datetime.now()

 File "/usr/lib/python2.6/site-packages/django/db/models/manager.py", line 93, in get
   return self.get_query_set().get(*args, **kwargs)

 File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line 304, in get
   num = len(clone)

 File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line 160, in __len__
   self._result_cache = list(self.iterator())

 File "/usr/lib/python2.6/site-packages/django/db/models/query.py", line 275, in iterator
   for row in self.query.results_iter():

 File "/usr/lib/python2.6/site-packages/django/db/models/sql/query.py", line 206, in results_iter
   for rows in self.execute_sql(MULTI):

 File "/usr/lib/python2.6/site-packages/django/db/models/sql/query.py", line 1734, in execute_sql
   cursor.execute(sql, params)

OperationalError: server closed the connection unexpectedly
       This probably means the server terminated abnormally
       before or while processing the request.

Answer 1

可能的解决方案：http://groups.google.com/group/django-用户/browse_thread/thread/2c7421cdb9b99e48

直到最近我很好奇想要测试一下
这是 Django 1.1.1 上的。 这会吗
再次抛出异常...惊喜，
又来了。 我花了一些时间
是时候调试这个了，有用的提示是
它仅在（预）分叉时显示。
所以对于那些随机获得的人
那些例外，我可以说......修复
你的代码:) 好吧..说真的，有
总是很少有方法可以做到这一点，所以
首先让我解释一下 a 在哪里
问题先。 如果你访问数据库
当您的任何模块将导入时
例如，从读取配置
数据库，然后你会得到这个错误。
当您的 fastcgi-prefork 应用程序
开始，首先导入所有模块，
并且只有在这之后才分叉孩子。
如果您已经建立了数据库连接
在导入所有子进程期间
将有一份精确的副本
目的。 此连接正在
在请求阶段结束时关闭
（请求完成信号）。 所以首先
将被调用来处理的子进程
您的请求，将关闭此
联系。 但会发生什么
其余的子进程？ 他们
会相信他们有开放和
大概是工作连接到
db，所以任何db操作都会导致
例外。 为什么这没有显示在
线程执行模型？ 我想
因为线程正在使用同一个对象
并知道任何其他线程何时
关闭连接。 如何解决这个问题？
最好的方法是修复你的代码......但是
有时这可能很困难。
我认为还有其他选择
clean，就是在你的某个地方写
应用程序的一小段代码：

from django.db import connection 
from django.core import signals 
def close_connection(**kwargs): 
    connection.close() 
signals.request_started.connect(close_connection) 

不理想的想法，连接两次到数据库充其量是一种解决方法。

---

可能的解决方案：使用连接池（pgpool、pgbouncer），这样您就可以拥有稳定的数据库连接池，并快速传递给 FCGI 守护进程。

问题是这会触发另一个错误，psycopg2 会引发 InterfaceError 因为它尝试断开两次连接（pgbouncer 已经处理了这个问题）。

现在，罪魁祸首是 Django 信号 request_finished 触发 connection.close()，并且即使已经断开连接，也会大声失败。 我认为这种行为是不需要的，就好像请求已经完成一样，我们不再关心数据库连接。 纠正这个问题的补丁应该很简单。

相关回溯：

 /usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/core/handlers/wsgi.py in __call__(self=<django.core.handlers.wsgi.WSGIHandler object at 0x24fb210>, environ={'AUTH_TYPE': 'Basic', 'DOCUMENT_ROOT': '/storage/test', 'GATEWAY_INTERFACE': 'CGI/1.1', 'HTTPS': 'off', 'HTTP_ACCEPT': 'application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', 'HTTP_AUTHORIZATION': 'Basic dGVzdGU6c3VjZXNzbw==', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_COOKIE': '__utma=175602209.1371964931.1269354495.126938948...none); sessionid=a1990f0d8d32c78a285489586c510e8c', 'HTTP_HOST': 'www.rede-colibri.com', ...}, start_response=<function start_response at 0x24f87d0>)
  246                 response = self.apply_response_fixes(request, response)
  247         finally:
  248             signals.request_finished.send(sender=self.__class__)
  249 
  250         try:
global signals = <module 'django.core.signals' from '/usr/local/l.../Django-1.1.1-py2.6.egg/django/core/signals.pyc'>, signals.request_finished = <django.dispatch.dispatcher.Signal object at 0x1975710>, signals.request_finished.send = <bound method Signal.send of <django.dispatch.dispatcher.Signal object at 0x1975710>>, sender undefined, self = <django.core.handlers.wsgi.WSGIHandler object at 0x24fb210>, self.__class__ = <class 'django.core.handlers.wsgi.WSGIHandler'>
 /usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/dispatch/dispatcher.py in send(self=<django.dispatch.dispatcher.Signal object at 0x1975710>, sender=<class 'django.core.handlers.wsgi.WSGIHandler'>, **named={})
  164 
  165         for receiver in self._live_receivers(_make_id(sender)):
  166             response = receiver(signal=self, sender=sender, **named)
  167             responses.append((receiver, response))
  168         return responses
response undefined, receiver = <function close_connection at 0x197b050>, signal undefined, self = <django.dispatch.dispatcher.Signal object at 0x1975710>, sender = <class 'django.core.handlers.wsgi.WSGIHandler'>, named = {}
 /usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/db/__init__.py in close_connection(**kwargs={'sender': <class 'django.core.handlers.wsgi.WSGIHandler'>, 'signal': <django.dispatch.dispatcher.Signal object at 0x1975710>})
   63 # when a Django request is finished.
   64 def close_connection(**kwargs):
   65     connection.close()
   66 signals.request_finished.connect(close_connection)
   67 
global connection = <django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>, connection.close = <bound method DatabaseWrapper.close of <django.d...ycopg2.base.DatabaseWrapper object at 0x17b14c8>>
 /usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/db/backends/__init__.py in close(self=<django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>)
   74     def close(self):
   75         if self.connection is not None:
   76             self.connection.close()
   77             self.connection = None
   78 
self = <django.db.backends.postgresql_psycopg2.base.DatabaseWrapper object at 0x17b14c8>, self.connection = <connection object at 0x1f80870; dsn: 'dbname=co...st=127.0.0.1 port=6432 user=postgres', closed: 2>, self.connection.close = <built-in method close of psycopg2._psycopg.connection object at 0x1f80870>

此处的异常处理可以增加更多宽容：

/usr/local/lib/python2.6/dist-packages/Django-1.1.1-py2.6.egg/django/db/__init__.py< /strong>

   63 # when a Django request is finished.
   64 def close_connection(**kwargs):
   65     connection.close()
   66 signals.request_finished.connect(close_connection)

或者它可以在 psycopg2 上处理得更好，所以如果我们想要做的只是断开连接并且它已经是：

/usr/local/lib/python2.6/dist-packages ，则不会抛出致命错误/Django-1.1.1-py2.6.egg/django/db/backends/__init__.py

   74     def close(self):
   75         if self.connection is not None:
   76             self.connection.close()
   77             self.connection = None

除此之外，我缺乏想法。

Answer 2

在交换机中，您是否更改了 PostgreSQL 客户端/服务器版本？

我在 php+mysql 上看到过类似的问题，罪魁祸首是客户端/服务器版本之间的不兼容（即使它们有相同的主要版本！）

Answer 3

闻起来像是可能存在线程问题。 Django 不保证线程安全，尽管文件内文档似乎表明 Django/FCGI 可以以这种方式运行。 尝试使用 prefork 运行，然后击败服务器。 如果问题消失了...

Answer 4

也许两种设置（Apache+mod_python 和 lighttpd + FastCGI）的 PYTHONPATH 和 PATH 环境变量是不同的。

Answer 5

最后我切换回 Apache + mod_python（除了这个之外，我在使用 fcgi 时还遇到了其他随机错误），现在一切都很好并且稳定。

这个问题仍然悬而未决。 如果以后有人遇到这个问题并解决了，可以在这里记录解决方案以供将来参考。 :)

Answer 6

我在使用 geodjango 模型时修复了类似的问题，该模型未对其功能之一使用默认 ORM。 当我添加一行来手动关闭连接时，错误消失了。

http://code.djangoproject.com/ticket/9437

我仍然随机看到错误（然而，当使用用户登录/会话进行操作时，约 50% 的请求。

Answer 7

我最近遇到了同样的问题（lighttpd、fastcgi 和 postgre）。 找了好几天的解决办法没有成功，最后只好改用mysql。 问题就消失了。

Answer 8

为什么不将会话存储在缓存中？
另外

SESSION_ENGINE = "django.contrib.sessions.backends.cache"

，您可以尝试将 postgres 与 pgbouncer 一起使用（postgres - prefork 服务器，不喜欢每次连接/断开连接），但首先检查您的 postgresql.log。

另一个版本 - 会话表中有很多记录，django-admin.py cleanup 可以提供帮助。

Answer 9

问题可能主要出在进口方面。 至少那是发生在我身上的事。
在从网上找不到任何内容后，我编写了自己的解决方案。 请在这里查看我的博文： 简单的 Python 实用程序来检查所有导入你的项目

当然，这只会帮助你很快地找到原始问题的解决方案，而不是问题本身的实际解决方案。

Answer 10

从 method=prefork 更改为 method=threaded 解决了我的问题。

Answer 11

即使我不使用 django 而是使用金字塔作为框架，我也会尝试给出答案。 我很长时间以来都遇到这个问题。 问题是，在测试中产生这个错误真的很困难......无论如何。 最后，我通过挖掘会话、范围会话、会话实例、引擎和连接等的全部内容来解决这个问题。我发现了这个：

http://docs.sqlalchemy.org/en/rel_0_7/core/pooling.html#disconnect-handling-pessimistic

这种方法只是添加了一个引擎连接池的监听器。 在侦听器中，向数据库查询静态选择。 如果失败，池会尝试在失败之前建立与数据库的新连接。 重要提示：这发生在任何其他内容被扔到数据库之前。 因此可以预先检查连接，以防止其余代码失败。

这不是一个干净的解决方案，因为它本身不能解决错误，但它的作用就像一个魅力。 希望这对某人有帮助。

Answer 12

适用的引用：

“2019 年有人吗？”
- 一半的 YouTube 评论，大约 2019 年


如果有人仍在处理此问题，请确保您的应用程序“急切分叉”，以便您的 Python DB 驱动程序（对我来说是 psycopg2）不会在进程之间共享资源。

我通过添加lazy-apps = true选项解决了uWSGI上的这个问题，这会导致直接分叉应用程序进程，而不是等待写入时复制。 我想其他 WSGI / FastCGI 主机也有类似的选项。

Answer 13

您是否考虑过降级到 Python 2.5.x（特别是 2.5.4）？ 我认为 Django 在 Python 2.6 上不会被认为是成熟的，因为有一些向后不兼容的更改。 但是，我怀疑这能否解决您的问题。

另外，Django 1.0.2 修复了一些邪恶的小错误，因此请确保您正在运行它。 这很好地可以解决你的问题。