psql: FATAL: Вибачте, занадто багато клієнтів вже є

Я несподівано отримую цю помилку при спробі доступу до веб-сайту, що використовує базу даних postgresql, або навіть при використанні утиліти 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

Ще важливіше те, що всі вони мають однакову адресу клієнта (мій веб-сервер).

Цей веб-сервер використовує рубін на рейках із пулом з'єднання 50. Хоча в пулі з'єднань 50, конфігурація апашерного процесу / префорка є однопотоковою і тому кожен процес не може породити 50 потоків та 50 підключень до бази даних. Більше того, це сталося після перезавантаження системи, яка вибила всіх користувачів з мого веб-сервера. Ймовірність полягає в тому, що postgresql на сервері баз даних не знає перезавантаження веб-сервера і все ще намагається виконати ці запити.

Щоб відповісти на коментарі Крейга, під стовпцем очікування відображається літера "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. Чи були створені ці з'єднання до або після перезавантаження веб-сервера? Якщо у них все нові з'єднання, я думаю, це означає, що проблема в кінці веб-сервера.

— Нік Барнс

@NickBarnes всі ці з'єднання мають один і той же запит у стовпці "current_query", і час backend_start практично однаковий для всіх них (в мілісекундах один від одного). Це те, що так дивно, і я вважаю, що якщо пам'ять слугує мені правильною, вони були перед перезавантаженням. Але я припускав, що перезавантаження розірве з'єднання.

— ДжонМерліно

Гаразд ... Можливо, вам доведеться перевірити topна сервері, щоб перевірити, чи зайняті ці процеси. Якщо вони є, то я думаю, що з'єднання повинні зникнути, як тільки запити закінчуються (або, ви можете просто вбити їх зараз). Якщо вони простоюють, а з'єднання напевно мертві, то я не впевнений, що відбувається, або як запобігти цьому наступного разу ...

— Нік Барнс

Перевірте waitingпрапор pg_stat_activity, побачте, чи не застряг він у замці.

— Крейг Рінгер

Вихід, з якого ви вставили SELECT * FROM pg_stat_activity;, не є правдоподібним - стовпців недостатньо. Що говорить стовпець штату? Це найважливіше поле для цього питання.

— eradman

Здається, це специфічна проблема програмування клієнта. Ви не зможете це виправити, наприклад, підвищивши параметр "max_connections".

Я знайшов можливу пов’язану проблему: об'єднання з'єднань бази даних Ruby

Незважаючи на те, що ви також можете зробити налагодження на стороні сервера:

Увімкніть "log_connections" та "log_disconnections". Також використовуйте "log_line_prefix" з "% m% a% p".

Дуже корисними програмами для налагодження серверів PostgreSQL є powa або набагато більше зверху, як: pg_activity

Для налагодження сервера в режимі реального часу я віддаю перевагу pg_activity - особливо з його функцією відображати блокатори та знищувати сеанси.

— Йозеф Хопфгартнер
джерело

-4

Це найкращий спосіб вирішити проблему ... це працює

Увійдіть на сервер за допомогою SSH putty,

sudo /etc/init.d/postgresql зупинка

це вбиває мертві процеси журналу в базі даних,

sudo /etc/init.d/postgresql start

— Мадука
джерело

А потім наступного разу, коли ви знову зупините виробничий сервер? Ваше рішення чітко усуває застряглі процеси, але не пояснює, чому вони там є, і не є стійким.

— dezso