psql: FATAL: scusa, troppi clienti già

16

Ricevo improvvisamente questo errore quando provo ad accedere al sito Web che utilizza il database postgresql o anche quando utilizzo l'utilità psql o pgadmin3.

Il mio database è impostato per gestire 150 connessioni massime:

# SHOW max_connections;
 max_connections 
-----------------
 150
(1 row)

Dopo aver riavviato il server Ubuntu su cui si trova il mio sito Web (che è davvero l'unica cosa che utilizza le connessioni), vedo che la quantità attuale di connessioni è 140:

# select count(*) from pg_stat_activity;
 count 
-------
   140
(1 row)

Non capisco quanto all'improvviso tante connessioni dopo aver riavviato il mio server. Quindi controllo l'attività postgresql:

# SELECT * FROM pg_stat_activity;

E vedo oltre 100 colonne con la stessa query esatta che assomiglia a questo:

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

Ancora più importante è che tutti abbiano lo stesso indirizzo client (il mio server web).

Questo web server utilizza ruby ​​su rotaie con un pool di connessioni di 50. Anche se esiste un pool di connessioni di 50, il processo Passenger / prefork apache è a thread singolo e pertanto ogni processo non può generare 50 thread e 50 connessioni al database. Inoltre, ciò si è verificato dopo un riavvio del sistema che ha eliminato tutti gli utenti dal mio server Web. È probabile che postgresql sul server di database non sia a conoscenza del riavvio del server Web e stia ancora tentando di eseguire queste query.

Per rispondere ai commenti di Craig, sotto la colonna di attesa mostra la lettera 'f'. Sembra che la query sia ancora in esecuzione e il blocco non è stato ancora rilasciato. Come ho affermato in precedenza, ciò che è così strano è che all'improvviso in questo stato di esecuzione sono comparse improvvisamente oltre 100 query identiche tra loro a pochi millisecondi di distanza. Questo è il mistero per me:

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 
— JohnMerlino
fonte
Dai un'occhiata pg_stat_activity.backend_start. Queste connessioni sono state create prima o dopo il riavvio del server Web? Se sono tutte nuove connessioni, immagino che ciò significhi che il problema è dovuto al server Web.
— Nick Barnes,
@NickBarnes tutte queste connessioni hanno tutte la stessa query nella colonna "current_query" e il tempo di backend_start è praticamente lo stesso per tutti (a distanza di millisecondi). Questo è ciò che è così strano e credo che se la memoria mi serve correttamente erano tutti prima del riavvio. Ma supponevo che il riavvio avrebbe interrotto la connessione.
— John Merlino,
1
Ok ... Potrebbe essere necessario controllare topsul server per vedere se questi processi sono occupati. Se lo sono, penso che le connessioni dovrebbero scomparire al termine delle query (o, in alternativa, puoi semplicemente ucciderle ora). Se sono inattivi e le connessioni sono definitivamente interrotte, non sono sicuro di cosa stia succedendo o di come impedirlo la prossima volta ...
— Nick Barnes,
1
Controlla la waitingbandiera pg_stat_activity, vedi se sono bloccati su una serratura.
— Craig Ringer,
1
L'output da cui hai incollato SELECT * FROM pg_stat_activity;non è credibile - non ci sono abbastanza colonne. Cosa dice la colonna di stato? Questo è il campo più importante per questa domanda.
— Eradman,

Risposte:

5

Questo sembra essere un problema specifico di programmazione client. Non sarai in grado di risolvere questo problema, ad esempio aumentando il parametro "max_connections".

Ho riscontrato un possibile problema correlato: pool di connessioni al database Ruby

Anche se potresti anche fare un po 'di debug sul lato server:

Abilita "log_connections" e "log_disconnections". Utilizzare anche "log_line_prefix" con "% m% a% p".

Le applicazioni molto utili per il debug dei server PostgreSQL sono powa o molto altro come: pg_activity

Per il debug del server in tempo reale preferisco pg_activity , in particolare con la sua funzione per visualizzare i blocchi e uccidere le sessioni.

— Josef Hopfgartner
fonte
-4

Questo è il modo migliore per risolvere il problema ... funziona

Accedi al server usando SSH putty,

sudo /etc/init.d/postgresql stop

questo uccide i processi di log morti nel database quindi,

sudo /etc/init.d/postgresql start

— Maduka
fonte
5
E la prossima volta che ti fermi di nuovo un server di produzione? La tua soluzione rimuove chiaramente i processi bloccati, ma non spiega perché sono lì, né è sostenibile.
— dezso
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.