/ Var / log / messages ile bellek yetersiz hata ayıklama

İletiler günlüğüme aşağıdaki rapor gönderildi:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Bu sorunun olmasının önemi yok mu httpd, mysqldyoksa postfixmerak ediyorum, problemi nasıl ayıklamaya devam edebilirim.

PID 9163'ün neden öldürüldüğü hakkında nasıl daha fazla bilgi edinebilirim ve linux'un sonlandırılmış PID'ler için bir yerde geçmiş olup olmadığından emin değilim.

Mesaj günlük dosyanızda bu meydana gelirse, bu sorunu nasıl adım adım çözeceksiniz?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

Bu gerçekleşmeden önce çekirdek bir sürü şey kaydetmiş olacak, ancak /var/log/messagesnasıl (r)syslogdyapılandırıldığına bağlı olarak büyük olasılıkla içinde olmayacak . Deneyin:

grep oom /var/log/*
grep total_vm /var/log/*

İlki bir kaç kez ortaya çıkmalı ve ikincisi sadece bir veya iki yerde ortaya çıkmalı. Bakmak istediğiniz dosya budur.

Orijinal "Bellek Dolu" satırını da içeren dosyalardan birinde bulun total_vm. Bir dakika otuz saniye (daha fazla olabilir, daha az olabilir) bu satırdan önce şöyle bir şey bulacaksınız:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Ayrıca bu satırla "Bellek Dolu" satırı arasında bir yerde bir tablo bulmalısınız:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Bu size bildiğinizden çok daha fazlasını söylemeyebilir, ancak alanlar şunlardır:

• pid İşlem kimliği.
• kullanıcı kimliği.
• tgid Konu grubu kimliği.
• total_vm Sanal bellek kullanımı (4 kB sayfalarda)
• rss Yerleşik bellek kullanımı (4 kb sayfalarda)
• nr_ptes Sayfa tablosu girdileri
• swapents girdileri takas
• oom_score_adj Genellikle 0; düşük bir sayı, OOM katili çağrıldığında işlemin ölme olasılığının düşük olacağını gösterir.

Çoğunlukla görmezden gelebilirsiniz nr_ptesve swapentsbunların kimi öldüreceğini belirleyen faktörler olduğuna inanıyorum. Bu mutlaka en fazla belleği kullanan işlem değildir, ancak büyük olasılıkla öyle. Seçim süreci hakkında daha fazla bilgi için buraya bakınız . Temel olarak, en yüksek oom skoruyla biten süreç öldürülür - bu, "Bellek Dolu" satırında rapor edilen "puan" dır; ne yazık ki diğer puanlar bildirilmemiştir ancak bu tablo faktörler açısından bazı ipuçları vermektedir.

Yine, bu muhtemelen açık olanı aydınlatmaktan daha fazlasını yapmayacaktır: sistem belleği tükendi ve mysqldölmek seçildi çünkü onu öldürmek çoğu kaynağı serbest bırakacaktı . Bu gerekli değil demek mysqldyanlış bir şey yapıyor demektir . O sırada başka bir şey olup olmadığını görmek için masaya bakabilirsiniz, ancak net bir suçlu olmayabilir: sadece çalışan işlemleri yanlış yaptığınız veya yanlış yapılandırdığınız için sistem belleği yetersiz tutabilir.

Bunun anahtarı mesajın kendisinde - Bellek yetersiz . Linux çekirdeği sanal belleğe aç kaldığında (fiziksel RAM artı takas), öldürme işlemlerine başlayacak ve işte tam olarak burada olanlar. mysqld2GB'ın üzerinde sanal bellek kullanıyor gibi görünüyor .

Sistemde ne kadar RAM ve takas var? Fazladan RAM eklemeyi ya da mümkün değilse fazladan takas eklemeyi düşünürdüm. En azından işlemlerin sonlandırılmasını önlemek için hızlı bir düzeltme olarak, bir takas dosyası ekleyebilirsiniz.

Güncelleme: Sahip olduğunuz RAM miktarına bakarak sorunu hemen görebilirsiniz. ~ 1,6 GB RAM ve 100 MB takas var, ancak MySQL bundan çok daha fazla RAM kullanıyor. Bu, neden işlemlerin sona erdiğini gördüğünüzü açıklar.