Postgresqlデータベースを使用するWebサイトにアクセスしようとしたとき、またはpsqlユーティリティまたはpgadmin3を使用しているときにも、突然このエラーが発生します。
私のデータベースは最大150の接続を処理するように設定されています。
# SHOW max_connections;
max_connections
-----------------
150
(1 row)
私のウェブサイトが存在するubuntuサーバーを再起動した後(これは実際に接続を使用する唯一のものです)、現在の接続数は140であることがわかります。
# select count(*) from pg_stat_activity;
count
-------
140
(1 row)
サーバーを再起動した後、接続が突然どれほど多くなるかわかりません。だから私はpostgresqlの活動をチェックします:
# SELECT * FROM pg_stat_activity;
そして、私はこのように見える同じ正確なクエリで100以上の列を見ます:
SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1
さらに重要なのは、それらすべてが同じクライアントアドレス(私のWebサーバー)を持っていることです。
このWebサーバーは、Ruby on Rails with a connection pool of 50)を使用しています。50の接続プールがある場合でも、Passengerプロセス/ prefork Apache構成はシングルスレッドであるため、各プロセスは50スレッドと50データベース接続を生成できません。さらに、システムの再起動後にすべてのユーザーがWebサーバーからノックされた後に、これが発生します。データベースサーバーのpostgresqlがWebを認識していない可能性がありますサーバーが再起動しても、これらのクエリを実行しようとしています。
クレイグのコメントに答えるために、待機列の下には「f」の文字が表示されています。クエリはまだ実行中で、ロックはまだ解放されていないようです。先ほど述べたように、奇妙なのは、この実行状態で突然、ミリ秒以内に100を超える互いに同一のクエリが突然出現したことです。それが私にとっての謎です。
mydb=# SELECT * FROM pg_stat_activity;
datid | datname | procpid | usesysid | usename | current_query | waiting | xact_start | query_start | backend_start | client_addr | client_port
--------+----------+---------+----------+---------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------+-------------------------------+-------------------------------+-------------------------------+----------------+-------------
464875 | mydb | 4992 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:48.437081-04 | 2014-06-28 22:46:44.089764-04 | 192.111.11.111 | 37166
464875 | mydb | 4993 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:48.497764-04 | 2014-06-28 22:46:44.277856-04 | 192.111.11.111 | 37167
464875 | mydb | 4994 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:48.504425-04 | 2014-06-28 22:46:44.485269-04 | 192.111.11.111 | 37168
464875 | mydb | 4996 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:48.482695-04 | 2014-06-28 22:46:44.688203-04 | 192.111.11.111 | 37169
464875 | mydb | 4998 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:48.432836-04 | 2014-06-28 22:46:44.703883-04 | 192.111.11.111 | 37170
-- many more
464875 | mydb | 5052 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:59.584386-04 | 2014-06-28 22:46:51.85682-04 | 192.111.11.111 | 37360
464875 | mydb | 5053 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:59.506483-04 | 2014-06-28 22:46:52.083316-04 | 192.111.11.111 | 37367
464875 | mydb | 8958 | 16387 | myuser | <IDLE> | f | | 2014-06-29 00:05:06.735249-04 | 2014-06-27 16:34:39.307312-04 | 192.111.11.111 | 52759
464875 | mydb | 5054 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:52.285867-04 | 192.111.11.111 | 37371
464875 | mydb | 5055 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:52.303562-04 | 192.111.11.111 | 37372
464875 | mydb | 5056 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:52.31447-04 | 192.111.11.111 | 37373
464875 | mydb | 5057 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:52.323721-04 | 192.111.11.111 | 37374
464875 | mydb | 5058 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:52.334238-04 | 192.111.11.111 | 37375
464875 | mydb | 5059 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:52.347227-04 | 192.111.11.111 | 37376
464875 | mydb | 5060 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:46:52.360008-04 | 192.111.11.111 | 37377
464875 | mydb | 5061 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:52.369496-04 | 192.111.11.111 | 37378
これはクライアントプログラミング固有の問題のようです。たとえば、これを修正することはできません。 「max_connections」パラメータを上げます。
関連する可能性のある問題を発見しました: Rubyデータベース接続プール
ただし、サーバー側のデバッグをさらに行うこともできます。
「log_connections」と「log_disconnections」を有効にします。また、「log_line_prefix」と「%m%a%p」を使用します。
PostgreSQLサーバーのデバッグに非常に役立つアプリケーションは powa 以上です top like:pg_activity
リアルタイムサーバーのデバッグには、pg_activityを優先します。特に、ブロッカーを表示し、セッションを強制終了する機能があります。