psql: FATAL: üzgünüm, zaten çok fazla müşteri var

Aniden postgresql veritabanını kullanan web sitesine erişmeye çalışırken veya psql yardımcı programını veya pgadmin3'ü kullanırken bu hatayı alıyorum.

Veritabanım maksimum 150 bağlantıyı işleyecek şekilde ayarlanmış:

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

Web sitemin bulunduğu ubuntu sunucusunu yeniden başlattıktan sonra (ki bu gerçekten bağlantıları kullanan tek şey), mevcut bağlantı miktarının 140 olduğunu görüyorum:

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

Sunucumu yeniden başlattıktan sonra ne kadar çok bağlantı olduğunu anlamıyorum. Bu yüzden postgresql etkinliğini kontrol ediyorum:

# SELECT * FROM pg_stat_activity;

Ve 100 sütun üzerinde aynı sorguyu şöyle görünüyor görüyorum:

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

Daha da önemlisi, hepsinin aynı istemci adresi (web sunucum) olması.

Bu web sunucusu, bağlantı havuzu 50 olan raylarda ruby kullanıyor. 50 bağlantı havuzu olmasına rağmen, Yolcu işlemi / prefork apache yapılandırması tek iş parçacıklıdır ve bu nedenle her işlem 50 iş parçacığı ve 50 veritabanı bağlantısı oluşturamaz. Dahası, bu, tüm kullanıcıları web sunucumdan çalan bir sistem yeniden başlatıldıktan sonra meydana geldi. Büyük olasılıkla veritabanı sunucusundaki postgresql, web sunucusunun yeniden başlatıldığının farkında değildir ve hala bu sorguları yürütmeye çalışmaktadır.

Craig'in yorumlarını cevaplamak için, bekleyen sütun altında 'f' harfini gösterir. Sorgu hala yürütülüyor ve kilit henüz serbest bırakılmamış gibi görünüyor. Daha önce de belirttiğim gibi, bu kadar garip olan şey, aniden bu yürütme durumunda aniden milisaniye içinde 100'den fazla sorgunun birbiriyle aynı olmasıdır. Bu benim için bir sır:

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
kaynak

Bir göz atın pg_stat_activity.backend_start. Bu bağlantılar web sunucusu yeniden başlatılmadan önce veya sonra mı oluşturuldu? Eğer hepsi yeni bağlantılar ise, sorunun web sunucusunun sonunda olduğu anlamına gelirdi.

— Nick Barnes

@NickBarnes bu bağlantıların tümü "current_query" sütunu altında aynı sorguya sahiptir ve backend_start zamanı pratikte hepsi için aynıdır (milisaniye aralıklı). Bu çok garip olan şeydir ve eğer bellek bana doğru hizmet ederse, bunların yeniden başlatılmadan önce olduğuna inanıyorum. Ama yeniden başlatmanın bağlantıyı keseceğini varsaydım.

— JohnMerlino

Tamam ... topBu işlemlerin meşgul olup olmadığını görmek için sunucuyu kontrol etmeniz gerekebilir . Eğer öyleyse, sorgular bittikten sonra bağlantıların kaybolması gerektiğini düşünüyorum (veya alternatif olarak bunları şimdi öldürebilirsiniz). Boşta kalırlarsa ve bağlantılar kesinlikle ölürse, o zaman ne olup bittiğinden veya bir dahaki sefere nasıl önleneceğinden emin değilim ...

— Nick Barnes

waitingBayrağı kontrol edin, pg_stat_activitykilide takılıp kalmadıklarına bakın.

— Craig Ringer

Yapıştırdığınız çıktı SELECT * FROM pg_stat_activity;inanılır değil - yeterli sütun yok. Durum sütunu ne diyor? Bu soru için en önemli alan bu.

— eradman

Bu istemci programlamaya özgü bir sorun gibi görünüyor. Örneğin "max_connections" parametresini yükselterek bunu düzeltemezsiniz.

Olası bir sorun buldum: Ruby veritabanı bağlantı havuzu oluşturma

Her ne kadar biraz daha sunucu tarafı hata ayıklama yapabilirsiniz:

"Log_connections" ve "log_disconnections" işlevlerini etkinleştirin. Ayrıca "% m% a% p" ile "log_line_prefix" kullanın.

PostgreSQL sunucularının hata ayıklaması için çok kullanışlı uygulamalar powa veya daha fazlasıdır:

Gerçek zamanlı sunucu hata ayıklaması için pg_activity'yi tercih ederim - özellikle engelleyicileri görüntüleme ve oturumları öldürme özelliği ile.

— Josef Hopfgartner
kaynak

-4

Sorunu çözmenin en iyi yolu bu ... işe yarıyor

SSH macunu kullanarak sunucuya giriş yapın,

sudo /etc/init.d/postgresql durağı

bu, veritabanındaki ölü günlük işlemlerini öldürür,

sudo /etc/init.d/postgresql başlangıç

— Maduka
kaynak

Ve bir dahaki sefere tekrar bir üretim sunucusunu durdurursunuz? Çözümünüz sıkışmış süreçleri açıkça kaldırır, ancak neden orada olduklarını veya sürdürülebilir bir süreci açıklamaz.

— dezso