2

PostgreSQLのパフォーマンスの問題をどのように診断しますか?

Ubuntu 12でデータベースバックエンドとしてPostgreSQLを使用しているDjangoベースのWebアプリがありますが、負荷が高いとデータベースが消えてしまい、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

実行中は、PostgreSQLがまだ実行中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 に答える