OOM katili, bol miktarda (?) Boş RAM ile işleri öldürüyor

OOM katili, sistemimde fazlasıyla boş RAM olmasına rağmen bir şeyleri öldürüyor gibi görünüyor:

(Tam çözünürlük)

(Tam çözünürlük)

27 dakika 408 süreç sonra sistem tekrar cevap vermeye başladı. Yaklaşık bir saat sonra yeniden başlattım ve kısa bir süre sonra bellek kullanımı normale döndü (bu makine için).

Muayene üzerine, kutumda çalışan birkaç ilginç süreç var:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

Bu belirli sunucu yakl. 8 saat, ve bunlar böyle garip değerleri olan sadece iki işlem. Benim şüphe duyduğum şey, potansiyel olarak bu duyusal olmayan değerlerle alakalı olan "başka bir şeyin" devam etmek olduğudur. Özellikle, sistemin bellekte olmadığını, gerçekte olmadığında düşündüğünü düşünüyorum . Sonuçta, bu sistemde teorik maksimum% 400 olduğunda rsyslogd% 55383984 CPU kullandığını düşünüyor.

Bu, 768MB RAM ile tamamen güncel bir CentOS 6 kurulumudur (6.2). Bunun neden olduğunu nasıl anlayacağınız konusunda herhangi bir öneriniz takdir edilecektir!

düzenlemek: attaching the vm. sysctl tunables .. Ben swappiness ile oynuyordum (100 olduğu açıkça belli) ve ben de tamponlarımı ve önbelleği (vm.drop_caches 3 olmak belirgin) yapılan kesinlikle korkunç bir script çalıştırıyorum + her disk senkronize 15 dakika. Bu nedenle, yeniden başlatmanın ardından önbelleğe alınan veriler biraz normal bir boyuta ulaştı, ancak hızlı bir şekilde tekrar düştü. Önbelleğe sahip olmanın Çok İyi Bir Şey olduğunu biliyorum, ama bunu anlayana kadar ...

Ayrıca biraz ilginçtir, sayfa dosyam etkinlik sırasında büyürken, gerçek OOM olaylarının karakteristik olmayan toplam kullanımının sadece% 20'sine ulaştı. Spektrumun diğer ucunda, disk aynı dönemde kesinlikle delindi, bu da sayfa dosyası oynatılırken bir OOM olayının karakteristiğidir.

sysctl -a 2>/dev/null | grep '^vm':

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

edit: ve ilk OOM mesajını ekleme ... daha yakından incelendiğinde, bir şeyin açıkça takas alanımın tamamını yemek için kendi yolundan çıktığını söylüyor.

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

Oom kütük dökümünden yeni baktım ve bu grafiğin doğruluğunu sorguladım. İlk 'Düğüm 0 DMA32' satırına dikkat edin. Diyor ki free:3376kB, min:3448kBve low:4308kB. Serbest değer düşük değerin altına düştüğünde, kswapd'ın bu değer yüksek değerin üzerine çıkıncaya kadar bir şeyleri değiştirmeye başlaması beklenir. Serbest kalma süresi min'in altına düştüğünde, sistem çekirdek tekrar min değerinin üzerine çıkıncaya kadar donar. Bu mesaj aynı zamanda takasın söylediği yerde tamamen kullanıldığını da gösterir Free swap = 0kB.
Temel olarak kswapd tetiklendi, ancak takas doluydu, bu yüzden hiçbir şey yapamadı ve pages_free değeri hala pages_min değerinin altındaydı.
Kesinlikle hafızanız bitti.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html bunun nasıl çalıştığına dair gerçekten iyi bir açıklaması var. En alttaki 'Uygulama' bölümüne bakın.

Drop_caches komut dosyasından kurtulun. Buna ek olarak, sizin dmesgve /var/log/messagesçıktınızın ilgili kısımlarını OOM mesajlarını gösteren olarak göndermelisiniz.

Bu davranışı durdurmak için olsa da, bu sysctlayarlanabilir denemenizi öneririz . Bu bir RHEL / CentOS 6 sistemidir ve kısıtlı kaynaklar üzerinde açıkça çalışmaktadır. Sanal bir makine mi?

Değiştirmeyi deneyin /proc/sys/vm/nr_hugepagesve sorunların devam edip etmediğini görün. Bu bir bellek parçalanması sorunu olabilir, ancak bu ayarın bir fark yaratıp yaratmadığına bakın. Değişikliği kalıcı hale getirmek için, eklemek vm.nr_hugepages = valueadresinden Müşteri /etc/sysctl.confve çalıştırmak sysctl -pyapılandırma dosyasını yeniden okumasını ...

Ayrıca bkz: Şifreli çekirdek "sayfa ayırma hatası" iletilerini yorumlama

OOM katilinin başladığı zamandan sona kadar grafikte veri yoktur. Grafiğin kesintiye uğradığı zaman diliminde aslında bellek tüketiminin arttığına ve artık kullanılabilir bellek olmadığına inanıyorum. Aksi takdirde OOM katili kullanılmaz. OOM katili durduktan sonra boş bellek grafiğini izlerseniz, grafiğin öncekinden daha yüksek bir değerden düştüğünü görebilirsiniz. En azından işini düzgün yaptı, hafızayı boşalttı.

Takas alanınızın yeniden başlatılıncaya kadar neredeyse tamamen kullanıldığını unutmayın. Bu neredeyse hiç iyi bir şey değildir ve çok az boş hafıza kaldığından emin bir işarettir.

Belirli bir zaman dilimi için veri bulunmamasının nedeni, sistemin başka şeylerle çok meşgul olmasıdır. İşlem listenizdeki "komik" değerler yalnızca bir sonuç olabilir, bir neden olmayabilir. Duyulmamış değil.

/Var/log/kern.log ve / var / log / mesajlarını kontrol edin, orada hangi bilgileri bulabilirsiniz?

Günlüğe kaydetme de durduysa, başka şeyler deneyin, işlem listesini sistem performans bilgileriyle aynı şekilde saniyede bir dosyaya dökün. Yük yükseldiğinde hala (umarım) işini yapabilmesi için yüksek öncelikli olarak çalıştırın. Önceden hazırlanmış bir çekirdeğiniz (bazen "sunucu" çekirdeği olarak belirtilir) yoksa, bu konuda şansınız olmayabilir.

Sanırım sorunlarınız başladığı zaman en fazla CPU% (%) kullanarak işlem (ler) nedenini bulacaksınız. Ben rsyslogd ne mysql bu şekilde davranan görmedim. Büyük olasılıkla suçlular java uygulamaları ve tarayıcı gibi gui güdümlü uygulamalardır.