öldür -9 postgres süreci

Bir postgres SELECT sorgusu, DB sunucumuz üzerinde kontrolden çıktı ve tonlarca hafıza yemeye başladı ve sunucu belleği doluncaya kadar takas etti. Belirli bir işlem ile bulundu ps aux | grep postgresve koştu kill -9 pid. Bu işlemi öldürdü ve bellek beklendiği gibi serbest kaldı. Sistemin geri kalanı ve postgres sorguları etkilenmedi. Bu sunucu SLES 9 SP4'te postgres 9.1.3 kullanıyor.

Ancak geliştiricilerimizden biri postgres sürecini öldürdüğü için beni mahvetti kill -9ve tüm postgres hizmetini devralacağını söyledi. Gerçekte, olmadı. Bunu birkaç kez daha önce yaptım ve herhangi bir olumsuz yan etki görmedim.

Bununla birlikte, daha fazla okuduktan sonra, kill pidbayraksız kaçak postgres sürecini öldürmek için tercih edilen bir yol gibi görünüyor , ancak postgres topluluğundaki diğer kullanıcılar için, postgres yıllar içinde "daha iyi olmuş" kill -9bireysel bir sorgu sürecinde / konu artık ölüm cezası değildir.

Birisi beni kaçak postgres sürecini öldürmenin doğru yolunda ve kill -9bu günlerde Postgres ile ne kadar feci (veya iyi huylu) kullanmanın aydınlatıcı olabilir ? İçgörü için teşekkürler.

voretaq7 'ın cevabı da dahil kilit noktaları kapsar arka uçları sonlandırmak için doğru yöntem ama biraz daha açıklama eklemek istiyorum.

kill -9(yani SIGKILL) asla, asla, asla ilk tercihiniz olan varsayılan olmamalı . İşlem normal kapatma isteklerine cevap vermediğinde ve SIGTERM( kill -15) etkisiz kaldığında son başvurunuz olmalıdır . Bu Pg için geçerlidir ve hemen hemen her şey.

kill -9 Öldürülen sürece hiç temizlik yapma şansı vermez.

PostgreSQL'e gelince, Pg, kill -9yedeklenmiş bir çökme olarak sonlandırılan bir destek görür . Arka uç paylaşılan hafızayı bozmuş olabileceğini biliyor - örneğin bir sayfayı shm içine yazarak ya da değiştirerek yarı yarıya kesmiş olabilirsiniz - örneğin - bir arka uçta aniden ortadan kalktığını fark ettiğinde diğer tüm arka uçları sonlandırır ve yeniden başlatır. ve sıfır olmayan bir hata kodu ile çıkıldı.

Bunu günlüklerde rapor edilmiş olarak göreceksiniz.

Zarar vermeyecek gibi görünüyorsa, Pg, kazadan sonra her şeyi yeniden başlatıyor ve uygulamanız kayıp bağlantılardan temiz bir şekilde çıkıyor. Bu iyi bir fikir yapmaz. Başka hiçbir arka uç çarpışması Pg'nin normal işleyen parçalarından daha az iyi test edilmemişse ve çok daha karmaşık / çeşitli ise, arka uç çarpışma ele alma ve kurtarmada gizlenen bir böcek şansı daha yüksektir.

Btw, eğer kill -9postacı sonra kaldırmak postmaster.pidve her postgresarka uç gitti olduğundan emin olmadan tekrar başlatın , çok kötü şeyler olabilir . Yanlışlıkla arka uç yerine postacıyı öldürdüyseniz, veritabanının düştüğünü gördüyseniz, yeniden başlatmaya çalıştıysanız, yeniden başlatma başarısız olduğunda "eski" .pid dosyasını kaldırdıysanız ve yeniden başlatmayı denediyseniz, bu kolayca olabilirdi. Bu kill -9, Pg etrafında dalgalanmaktan kaçınmanız ve silmemelisiniz postmaster.pid.

Bir gösteri:

kill -9Bir arka uç yaparken tam olarak ne olduğunu görmek için , bu basit adımları deneyin. İki terminal açın, her birinde psql ve her seferinde açın SELECT pg_backend_pid();. Başka bir terminalde kill -9PID'lerden biri. Şimdi SELECT pg_backend_pid();her iki psql oturumunda tekrar çalıştırın . İkisinin de bağlantılarını nasıl kaybettiğine dikkat et.

Öldürdüğümüz 1. Oturum:

$ psql regress
psql (9.1.4)
Type "help" for help.

regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6357
(1 row)

[kill -9 of session one happens at this point]

regress=# select pg_backend_pid();
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6463
(1 row)

Teminat hasarı olan 2. Seans:

$ psql regress
psql (9.1.4)
Type "help" for help.

regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6283
(1 row)

[kill -9 of session one happens at this point]

regress=# select pg_backend_pid();
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.
regress=# select pg_backend_pid();
 pg_backend_pid 
----------------
           6464
(1 row)

Her iki seansın nasıl kırıldığını gördün mü? Bu yüzden kill -9arka uç yapmıyorsun .

I found the particular process via ps aux | grep postgres and ran kill -9 pid.
YOK HAYIR! KÖTÜ! GERİ DÖNÜŞÜNDE ADIM!

Cidden - Postgres'i böyle öldürmeyin - Tüm DB'nizi çöpe atabilecek KORKUNÇ şeyler olabilir (7.x günden beri yapılan tüm stabilite iyileştirmelerinde bile olsa) ve geliştiriciniz çiğneme konusunda haklıdır. Bunu yaptığın için dışarı çıktın.

Aslında, bunu Postgres içinden yapmanın kutsanmış ve onaylanmış bir yolu var - SO post'un açıklamak için daha iyi bir iş çıkarmasına rağmen , Postgres kılavuzunda bile var ...

SELECT pg_cancel_backend(pid)
SIGINTBelirtilen arka uca, şu anda çalışan sorguyu iptal eden bir cancel ( ) sinyali gönderir .

select pg_terminate_backend(pid)
SIGTERMBelirtilen arka uca sorguyu iptal eden ve arka ucunu iptal eden (bağlantısını keserek) bir terminate ( ) sinyali gönderir .

Arka uç kimlikleri pg_stat_activitytablodan (veya ps) elde edilebilir

PostgreSQL istemcisini öldürmek iyi bir işlem olmalı. PostgreSQL arka plan süreci öldürmek sizi azarlayabilir.

SQL servetlerinde de dahili işlem kontrolleri olduğu için, tercih edilen yol önce o kanalı kullanmayı denemektir.

StackOverflow'tan PostgreSQL'de SQL sorgusu çalıştıran Dur (uzun) bölümüne bakın .