Soru OOM-Killer'in Adli Analizi


Ubuntu'nun Out-Of-Memory Killer'i sunucumda hasara yol açtı, uygulamalarımı, sendmail'i, apache'yi ve diğerlerini sessizce öldürdüm.

OOM Killer'in ne olduğunu ve "kötülük" kurallarını öğrenmeyi başardım. Makinem küçük olsa da, uygulamalarım daha da küçüktür ve tipik olarak fiziksel belleğimin yalnızca yarısı kullanımdadır, takas alanı olsun, bu yüzden şaşırdım. Ben suçluyu çözmeye çalışıyorum ama OOM-Killer kayıtlarını nasıl okuyacağımı bilmiyorum.

Lütfen kütüklerin içindeki verileri nasıl okuyacağınız konusunda bana bir öğretici yazabilir miyim? ve, free ve gen?) veya bu günlükleri ayrıştırmama yardım etsin mi?

Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 1, exc 2326 0 goal 2326 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 1, exc 2326 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 2, exc 122 0 goal 383 0...
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 1
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 2, exc 383 0 red 61795 745
Apr 20 20:03:27 EL135 kernel: kill_signal(13516.0): task ebb0c6f0, thg d33a1b00, sig 2
Apr 20 20:03:27 EL135 kernel: OOM killed process watchdog (pid=14490, ve=13516) exited, free=43104 gen=24501.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=4457, ve=13516) exited, free=43104 gen=24502.
Apr 20 20:03:27 EL135 kernel: OOM killed process ntpd (pid=10816, ve=13516) exited, free=43104 gen=24503.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=27401, ve=13516) exited, free=43104 gen=24504.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29009, ve=13516) exited, free=43104 gen=24505.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=10557, ve=13516) exited, free=49552 gen=24506.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=24983, ve=13516) exited, free=53117 gen=24507.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=29129, ve=13516) exited, free=68493 gen=24508.
Apr 20 20:03:27 EL135 kernel: OOM killed process sendmail-mta (pid=941, ve=13516) exited, free=68803 gen=24509.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=12418, ve=13516) exited, free=69330 gen=24510.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=22953, ve=13516) exited, free=72275 gen=24511.
Apr 20 20:03:27 EL135 kernel: OOM killed process apache2 (pid=6624, ve=13516) exited, free=76398 gen=24512.
Apr 20 20:03:27 EL135 kernel: OOM killed process python (pid=23317, ve=13516) exited, free=94285 gen=24513.
Apr 20 20:03:27 EL135 kernel: OOM killed process tail (pid=29030, ve=13516) exited, free=95339 gen=24514.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=20583, ve=13516) exited, free=101663 gen=24515.
Apr 20 20:03:28 EL135 kernel: OOM killed process logger (pid=12894, ve=13516) exited, free=101694 gen=24516.
Apr 20 20:03:28 EL135 kernel: OOM killed process bash (pid=21119, ve=13516) exited, free=101849 gen=24517.
Apr 20 20:03:28 EL135 kernel: OOM killed process atd (pid=991, ve=13516) exited, free=101880 gen=24518.
Apr 20 20:03:28 EL135 kernel: OOM killed process apache2 (pid=14649, ve=13516) exited, free=102748 gen=24519.
Apr 20 20:03:28 EL135 kernel: OOM killed process grep (pid=21375, ve=13516) exited, free=132167 gen=24520.
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 4, exc 4215 0 goal 4826 0...
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 1
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 4, exc 4826 0 red 189481 331
Apr 20 20:03:57 EL135 kernel: kill_signal(13516.0): task ede29370, thg df98b880, sig 2
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 5, exc 3564 0 goal 3564 0...
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 1
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 5, exc 3564 0 red 189481 331
Apr 20 20:04:53 EL135 kernel: kill_signal(13516.0): task c6c90110, thg cdb1a100, sig 2
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selecting to kill, queued 0, seq 6, exc 8071 0 goal 8071 0...
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 1
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): selected 1, signalled 1, queued 1, seq 6, exc 8071 0 red 189481 331
Apr 20 20:07:14 EL135 kernel: kill_signal(13516.0): task d7294050, thg c03f42c0, sig 2

Watchdog bekçi köpeği görevidir, bu boşta; Günlerce hiçbir şey yapmadığını önermek için günlüklerde hiçbir şey yok. İşi, eğer ölürse uygulamalardan birini yeniden başlatmaktır, bu yüzden öldürüldüğü ilk şey ironiktir.

Kuyruk birkaç günlük dosyasını izliyordu. Bellek delice tüketmek olası değildir.

Apache web sunucusu sadece sadece Pazar günü kiliseye gitmek için kullanan küçük bir yaşlı kadın uykuda olan ve birkaç hafta boyunca sitede bir sayfayı ziyaret etmemiş olan geliştiricilerden birkaçı. Sahip olabileceği tek trafik, liman tarayıcılarından geliyor; Tüm içerik şifre korumalı ve hiçbir yerden bağlantılandırılmamış, böylece hiçbir örümcek ilgilenmiyor.

Python iki ayrı özel uygulama çalıştırıyor. Günlüklerde hiçbir şey normal olarak uğultu etmediklerini öne sürecek bir şey değil. Bunlardan biri, 1 numaralı şüpheli olan nispeten yeni bir uygulama idi. Herhangi bir önem taşıyan veri yapıları yoktur ve normalde toplam fiziksel RAW'ın sadece% 8'ini kullanır. O zamandan beri yanlış davranmadı.

Grep şüpheli # 2 ve suçlu olmak istediğim, çünkü bir kerelik bir emirdir. Komut (grep -r çıktısını başka bir grep'e ileten) en az 30 dakika önce başlamıştı ve hala çalışıyor olması şüpheli. Ancak, grep'in önemli miktarda bellek kullanacağını düşünmezdim. OOM katilinin ona ulaşması biraz zaman aldı, ki bu delirmediğini gösteriyordu, ama OOM katili öldürüldükten sonra durdu, o zaman OOM katilin kanını tatmin eden bir anı olduğu düşünülebilirdi. .


7
2018-04-22 02:45


Menşei


olası kopyası serverfault.com/questions/134669/... - Dennis Williamson
Bu soruya bakmıştım ve bunun bir kopya olmadığına karar verdim. Geçmiş olduğumu düşündüğüm OOM Killer hakkında genel bilgi arıyor. Bazı günlük dosyalarının nasıl okunacağı hakkında özel bilgiler arıyorum - özellikle bazı parametrelerin ne anlama gelebileceğini. - Oddthinking
Aşağıdaki iş parçacığı sizin için yararlı olabilir. serverfault.com/questions/134669 - vasco.debian
Uygulamalarınız küçük olsa da sormak istiyorum - sunucunuzda herhangi bir trend istatistikleri var mı? Bellek kullanımı büyüme modellerini izlemek faydalı olabilir. Örneğin. bellek bir kerede ya da bir süre boyunca yavaşça kullanılır mı? Her zaman aynı saatte olur mu? Buna göre nereye bakacağınız konusunda daha fazla ipucunuz olabilir. Gibi bir araç Munin ile başlamak kolaydır. - Fred Clausen
@Fred: Bu üç yıllık sorudan panik flop terimini sildiğinizde, OOM Killer'den nasıl bir ipucu alabileceğimin açık bir şekilde nasıl hata ayıklanacağıyla ilgili genel talimatlar istemediğimi göreceksiniz. günlükleri. Günlük dosyasının bu sisli gecede ne olduğu hakkında çok şey anlattığına inanıyorum, ancak Linux çekirdeği için kaynak kodları okumadan ne yazdığını açıklamak için çeviriler yok. - Oddthinking


Cevaplar:


ServerFault'da yeniyim ve bu yazıyı yeni gördüm. Eski olmasına rağmen kuyruğun ön yüzünde yeniden ortaya çıkmış gibi görünüyor. Bu korkutucu olanı belki yatağa koyalım mı?

Her şeyden önce, çok sayıda kullanıcı işlemini güvenli bir şekilde yürütmek için sınırlı RAM'li sistemleri optimize ettiğim için bu konuya ilgi duyuyorum.

Bu kayıttaki hata mesajlarının OpenVZ Linux kapsayıcılarına başvurduğunu düşünüyorum.

Bir "ve", bir sanal ortamdır ve OpenVZ'de bir kap olarak da bilinir. Her konteynere bir ID verilir ve gördüğünüz sayı bu ID'dir. Bu konuda daha fazlası:

https://openvz.org/Container

"Boş" terimi, o andaki bayt cinsinden boş belleği ifade eder. Süreçler öldürüldükçe boş hafızaların giderek arttığını görebilirsiniz.

"Gen" terimi biraz emin değilim. Bence bu, nesile atıfta bulunur. Yani, 1'de başlar ve bir konteynırdaki her işlem nesli için bir artar. Yani, sisteminiz için, açılıştan beri 24K + süreçler yürütüldü. Yanılıyorsam lütfen beni düzeltin. Bunu test etmek kolay olmalı.

İşlemleri neden öldürdüğüne dair, OOM katil konfigürasyonunun sebebi bu. Boş belleği beklenen miktara geri getirmeye çalışıyor (ki bu 128 Kb gibi görünüyor). Oracle'ın, bunu nasıl daha iyi bir şekilde yapabileceğinize göre nasıl yapılandırılacağı iyi bir şekilde yazılmıştır:

http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html

Ayrıca, kapsayıcınızın her biri için bellek yapılandırmasını görmek isterseniz, şuna bakın:

https://openvz.org/Setting_UBC_parameters


1
2017-09-24 06:26