psql：致命的：申し訳ありませんが、すでにクライアントが多すぎます

15

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サーバーは、接続プールが50のRails on Railsを使用しています。接続プールが50であっても、Passengerプロセス/プリフォーク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
postgresql  max-connections 
— ジョンメルリーノ
ソース
を見てくださいpg_stat_activity.backend_start。これらの接続は、Webサーバーの再起動の前または後に作成されましたか？それらがすべて新しい接続である場合、問題はWebサーバーの端にあることを意味すると思います。
— ニックバーンズ14年
@NickBarnesのこれらの接続はすべて、「current_query」列の下に同じクエリを持ち、backend_startの時間はすべての接続で実質的に同じです（ミリ秒間隔）。それはとても奇妙なことであり、メモリが私に役立つなら、それらはすべて再起動前でしたと信じています。しかし、再起動すると接続が切断されると想定しました。
— JohnMerlino 14年
1
OK ... topこれらのプロセスがビジーかどうかを確認するためにサーバーをチェックする必要があるかもしれません。存在する場合、クエリが終了すると接続が消えるはずです（または、今すぐ接続を強制終了することもできます）。彼らしているアイドル、との接続は間違いなく死んでいる場合は、私は...何が起こっているのかわからない、またはどのように次の時間、それを防ぐために
— ニック・バーンズ
1
でwaitingフラグを確認pg_stat_activityし、ロックでスタックしているかどうかを確認します。
— クレイグリンガー14年
1
貼り付けた出力SELECT * FROM pg_stat_activity;は信じられません-十分な列がありません。州の列は何と言っていますか？それがこの質問の最も重要な分野です。
— エラドマン

回答:

5

これは、クライアントプログラミング固有の問題のようです。たとえば、「max_connections」パラメータを上げることでこれを修正することはできません。

関連する可能性のある問題を発見しました： Rubyデータベース接続プーリング

ただし、サーバー側でさらにデバッグを行うこともできます。

「log_connections」および「log_disconnections」を有効にします。また、「log_line_prefix」と「％m％a％p」を使用します。

PostgreSQLサーバーをデバッグするための非常に便利なアプリケーションは、powaまたはpg_activityのような上位のものです。

リアルタイムのサーバーデバッグには、pg_activityが好まれます。特に、ブロッカーを表示したり、セッションを終了したりする機能が気に入っています。

— ヨーゼフ・ホップフガルトナー
ソース
-4

これは問題を解決するための最良の方法です...それは動作します

SSHパテを使用してサーバーにログインし、

sudo /etc/init.d/postgresql stop

これにより、データベース内のデッドログプロセスが強制終了されます。

sudo /etc/init.d/postgresql start

— マドゥカ
ソース
5
そして、次に実動サーバーを再び停止したときはどうでしょうか？あなたのソリューションは、行き詰まったプロセスを明確に取り除きますが、なぜそこにあるのかを説明せず、持続可能なものでもありません。
— -dezso
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.