Pembunuh OOM membunuh banyak barang dengan RAM (?) Banyak

Pembunuh OOM tampaknya membunuh sesuatu walaupun memiliki lebih dari cukup RAM gratis di sistem saya:

Grafik pemanfaatan memori (Resolusi penuh)

27 menit dan 408 proses kemudian, sistem mulai merespons lagi. Saya mem-boot-ulangnya sekitar satu jam setelahnya, dan segera setelah itu pemanfaatan memori kembali normal (untuk mesin ini).

Setelah diperiksa, saya punya beberapa proses menarik yang berjalan di kotak saya:

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...]

Server khusus ini telah berjalan sekitar. 8 jam, dan ini hanya dua proses yang memiliki ... nilai ganjil. Kecurigaan saya adalah bahwa "sesuatu yang lain" sedang terjadi, berpotensi relevan dengan nilai-nilai yang tidak masuk akal ini. Secara khusus, saya berpikir bahwa sistem berpikir bahwa itu kehabisan memori, padahal kenyataannya tidak. Setelah semua, ia berpikir bahwa rsyslogd menggunakan CPU 55383984% secara konsisten, ketika maksimum teoritis adalah 400% pada sistem ini pula.

Ini adalah instalasi CentOS 6 yang sepenuhnya mutakhir (6.2) dengan RAM 768MB. Setiap saran tentang bagaimana mencari tahu mengapa ini terjadi akan dihargai!

edit: melampirkan vm. sysctl merdu .. Saya telah bermain dengan swappiness (dibuktikan dengan 100), dan saya juga menjalankan skrip yang benar - benar mengerikan yang membuang buffer dan cache saya (dibuktikan dengan vm.drop_caches menjadi 3) + menyinkronkan disk setiap 15 menit. Inilah sebabnya mengapa setelah reboot, data yang di-cache tumbuh ke ukuran yang agak normal, tetapi kemudian dengan cepat turun lagi. Saya menyadari bahwa memiliki cache adalah hal yang sangat bagus, tetapi sampai saya menemukan ini ...

Juga agak menarik adalah bahwa sementara pagefile saya tumbuh selama acara, itu hanya mencapai ~ 20% dari total utilisasi yang mungkin, yang tidak seperti biasanya acara OOM yang sebenarnya. Di ujung lain dari spektrum, disk menjadi benar-benar gila selama periode yang sama, yang merupakan karakteristik dari peristiwa OOM ketika pagefile sedang bermain.

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

sunting: dan melampirkan pesan OOM pertama ... setelah diperiksa lebih dekat, dikatakan bahwa ada sesuatu yang jelas keluar dari jalannya untuk memakan keseluruhan ruang swap saya juga.

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

— Kyle Brantley
sumber

Bisakah Anda memberikan output sysctl -a 2>/dev/null | grep '^vm'?

— Patrick

Ditambahkan. Semoga Anda (atau seseorang) dapat menemukan sesuatu yang saya lewatkan.

— Kyle Brantley

Satu-satunya hal yang melompat ke arah saya adalah overcommit_memorypengaturan. Mengaturnya ke 1 seharusnya tidak menyebabkan perilaku ini, tetapi saya belum pernah memiliki kebutuhan untuk mengaturnya ke 'selalu berlebihan' sebelumnya, jadi tidak banyak pengalaman di sana. Melihat catatan lain yang Anda tambahkan, Anda mengatakan bahwa swap hanya digunakan 20%. Namun menurut dump log OOM Free swap = 0kB,. Pasti mengira swap digunakan 100%.

— Patrick

Jawaban:

Saya hanya melihat oom log dump, dan saya mempertanyakan keakuratan grafik itu. Perhatikan baris 'Node 0 DMA32' pertama. Dikatakan free:3376kB, min:3448kB, dan low:4308kB. Setiap kali nilai bebas turun di bawah nilai rendah, kswapd seharusnya mulai bertukar sesuatu sampai nilai itu kembali di atas nilai tinggi. Setiap kali free drop di bawah min, sistem pada dasarnya membeku sampai kernel mendapatkannya kembali di atas nilai min. Pesan itu juga menunjukkan bahwa swap sepenuhnya digunakan di mana dikatakan Free swap = 0kB.
Jadi pada dasarnya kswapd terpicu, tetapi swap penuh, jadi tidak bisa melakukan apa-apa, dan nilai pages_free masih di bawah nilai pages_min, jadi satu-satunya pilihan adalah mulai membunuh sesuatu sampai bisa mendapatkan kembali Page_free.
Anda benar-benar kehabisan memori.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html memiliki penjelasan yang sangat bagus tentang cara kerjanya. Lihat bagian 'Implementasi' di bagian bawah.

— Patrick
sumber

Jadi OP benar-benar hanya membutuhkan lebih banyak RAM ...

— ewwhite

lebih banyak ram, atau cari tahu apa yang memakannya.

— Patrick

Saya menempatkan garis pada grafik itu dengan sangat tepat. Itu menghentikan data logging ~ 1-2m sebelum proses pertama dibunuh, dan melanjutkan data logging ~ 4-5m setelah yang terakhir terbunuh. Pada titik ini, saya bertaruh bahwa beberapa proses benar-benar rusak dan mulai meronta-ronta pagefile saya - setelah akhirnya mendapatkan segalanya, itu membunuh proses yang secara fungsional kehabisan pagefile juga, itulah sebabnya ketika data kembali, file halaman ditinggikan tetapi tidak penuh. Saran tentang bagaimana menentukan apa yang melakukan ini akan disambut baik!

— Kyle Brantley

@KyleBrantley Nilai apa yang Anda tarik untuk menghasilkan grafik? Salah satu kelemahan sistem memori virtual linux adalah tidak ada definisi konkret 'bebas'. Ada selusin cara mendefinisikan 'memori bebas'. Yang paling penting sejauh kswapd adalah nilai pages_free. Adapun pertukaran gratis, saya tidak tahu nilai apa yang Anda baca yang akan sejauh itu. Satu-satunya cara untuk benar-benar melihat apa yang memakan memori adalah mencatat snapshot terus-menerus dari semua proses pada kotak dan melihat apa yang menghabiskan semua memori ketika pembunuh mulai membuat gila.

— Patrick

Yup, saya kehabisan memori. Saya akhirnya memeriksa log untuk menemukan bahwa proses anak apache saya berulang kali dibunuh, yang membuat saya mengetahui bahwa saya memiliki proses anak yang secara tak terbatas secara fungsional dapat dimulai. Yang diperlukan hanyalah bot blogspam otomatis yang melempar banyak permintaan / detik pada tuan rumah agar jatuh. Apache Tweaking memecahkan segalanya.

— Kyle Brantley

Singkirkan skrip drop_caches. Selain itu, Anda harus memposting bagian yang relevan dari Anda dmesgdan /var/log/messagesoutput menampilkan pesan OOM.

Untuk menghentikan perilaku ini, saya sarankan mencoba sysctlmerdu ini . Ini adalah sistem RHEL / CentOS 6 dan jelas berjalan pada sumber daya terbatas. Apakah ini mesin virtual?

Coba modifikasi /proc/sys/vm/nr_hugepagesdan lihat apakah masalah masih ada. Ini bisa menjadi masalah fragmentasi memori, tetapi lihat apakah pengaturan ini membuat perbedaan. Untuk menjadikan perubahan itu permanen, tambahkan vm.nr_hugepages = valueke Anda /etc/sysctl.confdan jalankan sysctl -puntuk membaca kembali file konfigurasi ...

Juga lihat: Menafsirkan pesan kernel "kegagalan alokasi halaman" cryptic

— putih
sumber

Menambahkan pesan oom-killer pertama. Sementara MySQL adalah hal yang paling intensif RAM yang saya jalankan, saya telah menyetelnya agar tidak membanjiri kotak, jadi selain dari nilai-nilai gila yang saya lihat di atas, saya tidak benar-benar mencurigainya (5.1%) penggunaan memori baik-baik saja, semua hal dipertimbangkan). Ini adalah VPS, dengan 768MB RAM. Saya akan membaca tentang nr_hugepages dan mencobanya, terima kasih!

— Kyle Brantley

@ewwhite mengalokasikan banyak hugepage yang akan membunuh kotak itu. Kotak hanya memiliki ram 768mb, dan dengan hugepagesz default 2mb, yang akan mengalokasikan 2gb hugepage. Kotak itu tidak akan mampu menangani itu dan akan segera mati.

— Patrick

Diperbarui. Nilainya harus ditingkatkan dari nol.

— ewwhite

Masih lebih rumit dari itu. Anda harus mengatur izin halaman besar, dan mysql harus dikonfigurasi untuk menggunakan halaman besar, jika tidak, Anda hanya mengalokasikannya tanpa alasan.

— Patrick

Tidak ada data tersedia pada grafik mulai dari saat pembunuh OOM dimulai sampai berakhir. Saya percaya pada kerangka waktu di mana grafik terputus bahwa pada kenyataannya konsumsi memori tidak lonjakan dan tidak ada memori yang tersedia lagi. Kalau tidak, pembunuh OOM tidak akan digunakan. Jika Anda menonton grafik memori bebas setelah pembunuh OOM berhenti, Anda dapat melihatnya turun dari nilai yang lebih tinggi dari sebelumnya. Setidaknya itu melakukan tugasnya dengan benar, membebaskan memori.

Perhatikan bahwa ruang swap Anda hampir sepenuhnya digunakan sampai reboot. Itu hampir tidak pernah merupakan hal yang baik dan pertanda pasti ada sedikit memori yang tersisa.

Alasan tidak ada data yang tersedia untuk kerangka waktu tertentu adalah karena sistem terlalu sibuk dengan hal-hal lain. Nilai-nilai "Lucu" dalam daftar proses Anda mungkin hanya hasil, bukan penyebab. Itu tidak pernah terdengar.

Periksa /var/log/kern.log dan / var / log / messages, informasi apa yang dapat Anda temukan di sana?

Jika logging juga berhenti kemudian coba hal-hal lain, buang daftar proses ke file setiap detik, sama dengan informasi kinerja sistem. Jalankan dengan prioritas tinggi sehingga masih bisa melakukan tugasnya (semoga) ketika beban melonjak. Meskipun jika Anda tidak memiliki kernel preempt (kadang-kadang diindikasikan sebagai kernel "server") Anda mungkin kurang beruntung dalam hal itu.

Saya pikir Anda akan menemukan bahwa proses yang menggunakan CPU% paling banyak saat masalah Anda mulai adalah penyebabnya. Saya belum pernah melihat rsyslogd dan mysql tidak berlaku seperti itu. Penyebab lebih mungkin adalah aplikasi java dan aplikasi yang digerakkan gui seperti browser.

— aseq
sumber

Tidak ada data di celah itu karena beban pada kotak itu sangat tinggi sehingga semuanya, termasuk agen pemantau, terhenti total. Agen itu sendiri tidak pernah benar-benar terbunuh selama periode mendekati kematian, tetapi agen itu juga tidak dapat melaporkan data apa pun. Ruang swap saya sebenarnya baik-baik saja. Itu menggunakan ~ 130 / 512MB total sebelum reboot. rsyslogd dikonfigurasi untuk melaporkan log ke lokasi jaringan, di mana semua yang terjadi dicatat - dan selain itu membunuh 408 proses (beberapa di antaranya adalah anak-anak apache yang dihidupkan ulang), tidak ada yang menonjol.

— Kyle Brantley

Saya mungkin berakhir dengan membuang daftar proses lengkap ke file (atau jaringan) setiap beberapa detik jika saya tidak dapat mengetahui apa yang sebenarnya terjadi di sini, jadi terima kasih atas ide bagusnya.

— Kyle Brantley

Ya Anda harus melakukan itu, pastikan Anda juga merekam penggunaan CPU dari setiap proses, lihat "top -b" (mode batch). Proses yang paku bisa menjadi biang keladinya.

— aseq