PostgreSQL 数据库服务器无响应答案

【问题标题】：PostgreSQL Database Server UnresponsivePostgreSQL 数据库服务器无响应
【发布时间】：2012-09-01 16:32:24
【问题描述】：

您如何诊断 PostgreSQL 性能问题？

我有一个基于 Django 的 webapp，在 Ubuntu 12 上使用 PostgreSQL 作为数据库后端，在重负载下，数据库似乎刚刚消失，导致 Django 接口无法访问并导致如下错误：

django.db.utils.DatabaseError: error with no message from the libpq

django.db.utils.DatabaseError: server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.

奇怪的是 /var/log/postgresql 中的日志没有显示任何异常。日志 /var/log/postgresql/postgresql-9.1-main.log 显示的唯一内容是很多行，例如：

2012-09-01 12:24:01 EDT LOG:  unexpected EOF on client connection

运行 top 表明 PostgreSQL 似乎没有消耗任何 CPU，尽管 service postgresql status 表明它仍在运行。

执行“service postgresql restart”可以暂时解决问题，但一旦数据库负载过大，问题就会再次出现。

我检查了 dmesg 和 syslog，但我没有看到任何可以解释问题所在的内容。我应该检查哪些其他日志？如何确定我的 PostgreSQL 服务器出了什么问题？

编辑：我的 max_connections 设置为 100。虽然我正在做很多手动交易。在手动模式下使用 PostgreSQL 阅读 Django 的 ORM 行为，看起来我可能必须明确地执行 connection.close()，我没有这样做。

【问题讨论】：

可能是数据库的最大连接已用完，或者有太多的连接在没有关闭的情况下什么都不做（超时设置太高）。
您是在专用服务器上还是在 VPS 上？
@Catcall，基于 KVM 的 VPS。

标签： django postgresql postgresql-9.1

【解决方案1】：

我发现这是由于 Django 的错误 Postgres 后端与多处理相结合。本质上，Django 没有正确地自动关闭它的连接，从而导致一些奇怪的行为，比如大量的“空闲事务”连接。我通过将connection.close() 添加到我的多处理启动函数的末尾以及抛出此错误的某些查询之前来修复它。

【讨论】：

问题不在于 django，django 不会分叉连接，因此看起来正在运行的进程可能会提前关闭连接，因为它在进程之间共享。这就是我发生的事情。当我尝试在多处理时更新数据库时，它发生在我身上。我收集了要更新的数据以及多处理部分何时完成。然后我运行了一个更新查询。像魅力一样工作:)

【解决方案2】：

2012-09-01 12:24:01 EDT LOG:  unexpected EOF on client connection

这条消息显示，所以客户端有一些问题 - 可能是 libpq 的一些异常？可能存在相关问题 - 当客户端在没有正确注销的情况下挂起时，您有很多空闲连接，并且您会提前收到其他错误。

【讨论】：

【解决方案3】：

pg_ctl 程序有一些可能有帮助的选项。 (man pg_ctl)

   -c
       Attempt to allow server crashes to produce core files, on platforms
       where this is possible, by lifting any soft resource limit placed
       on core files. This is useful in debugging or diagnosing problems
       by allowing a stack trace to be obtained from a failed server
       process.

   -l filename
       Append the server log output to filename. If the file does not
       exist, it is created. The umask is set to 077, so access to the log
       file is disallowed to other users by default.

postgres 程序也有一些调试选项。 (man postgres)

   -d debug-level
       Sets the debug level. The higher this value is set, the more
       debugging output is written to the server log. Values are from 1 to
       5. It is also possible to pass -d 0 for a specific session, which
       will prevent the server log level of the parent postgres process
       from being propagated to this session.

在“半内部选项”部分。 . .

   -n
       This option is for debugging problems that cause a server process
       to die abnormally. The ordinary strategy in this situation is to
       notify all other server processes that they must terminate and then
       reinitialize the shared memory and semaphores. This is because an
       errant server process could have corrupted some shared state before
       terminating. This option specifies that postgres will not
       reinitialize shared data structures. A knowledgeable system
       programmer can then use a debugger to examine shared memory and
       semaphore state.

   -T
       This option is for debugging problems that cause a server process
       to die abnormally. The ordinary strategy in this situation is to
       notify all other server processes that they must terminate and then
       reinitialize the shared memory and semaphores. This is because an
       errant server process could have corrupted some shared state before
       terminating. This option specifies that postgres will stop all
       other server processes by sending the signal SIGSTOP, but will not
       cause them to terminate. This permits system programmers to collect
       core dumps from all server processes by hand.

【讨论】：