2

您如何诊断 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()，而我没有这样做。

4

3 回答 3

4

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

于 2014-03-03T01:15:15.570 回答
1 
2012-09-01 12:24:01 EDT LOG:  unexpected EOF on client connection

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

于 2012-09-01T19:43:32.777 回答
1

程序 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.
于 2012-09-01T19:44:12.557 回答