Mengapa linux out-of-memory (OOM) killer tidak berjalan secara otomatis, tetapi bekerja pada sysrq-key?

Alasan pembunuh OOM tidak dipanggil secara otomatis adalah, karena sistem, meskipun benar-benar melambat dan sudah tidak responsif ketika hampir kehabisan memori y, belum benar-benar mencapai situasi kehabisan memori.

Disederhanakan, ram yang hampir penuh berisi 3 jenis data:

1. data kernel, itu penting
2. halaman data proses penting (mis. data apa pun yang dibuat proses di ram saja)
3. halaman data proses yang tidak penting (misalnya data seperti kode yang dapat dieksekusi, yang salinannya ada di disk/ dalam sistem file, dan yang saat ini dipetakan ke memori dapat "dibaca ulang" dari disk saat digunakan )

Dalam situasi kekurangan memori, kernel linux sejauh yang saya tahu adalah kswapd0 utas kernel, untuk mencegah hilangnya data dan hilangnya fungsionalitas, tidak dapat membuang 1. dan 2. , tetapi bebas untuk setidaknya menghapus sementara data file yang dipetakan ke dalam memori dari ram yang membentuk proses yang saat ini tidak berjalan.

Meskipun ini adalah perilaku yang melibatkan meronta-ronta disk, untuk terus-menerus membuang data dan membacanya kembali dari disk, dapat dianggap membantu karena menghindari, atau setidaknya menunda penghapusan/pembunuhan proses yang diperlukan dan pembebasan-tetapi-juga- kehilangan ingatannya, ia memiliki tinggi harga:performa.

[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ] 
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ] 
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ] 
[evict pages with binary of process 1 from ram]

jelas IO mahal dan sistem cenderung menjadi tidak responsif, meskipun secara teknis belum habis sepenuhnya memori.

Dari perspektif pengguna bagaimanapun tampaknya, untuk digantung/dibekukan dan UI yang tidak responsif yang dihasilkan mungkin tidak terlalu disukai, daripada hanya mematikan proses (misalnya tab browser, yang penggunaan memorinya mungkin menjadi akar penyebab/penyebabnya mulai dengan.)

Di sinilah pertanyaan menunjukkan pemicu kunci SysRq Ajaib untuk memulai OOM secara manual tampak hebat, karena SysRq Ajaib tidak terlalu terpengaruh oleh sistem yang tidak responsif.

Meskipun mungkin ada kasus penggunaan yang penting untuk mempertahankan proses sama sekali (kinerja ) biaya, untuk desktop, kemungkinan penggunaan akan lebih memilih OOM-killer daripada UI yang dibekukan. Ada tambalan yang mengklaim untuk mengecualikan file yang didukung fs yang dipetakan bersih dari memori dalam situasi seperti ini dalam jawaban ini di stackoverflow.

Anda dapat menonton file /sys/fs/cgroup/memory/memory.oom_control, selama stress test.

atau

Anda dapat melihat tanggal modifikasi terakhirnya, untuk melihat apakah tanggal tersebut diubah sekitar waktu penguncian terakhir. Ini akan memberi tahu Anda apakah itu mencoba melakukan tugasnya.

under_oom 0

Itu masalah Anda:

under_oom    0 or 1 (if 1, the memory cgroup is under OOM, tasks may
             be stopped.)

Jika diatur ke 1, itu berarti di bawah kendali oom. Diaktifkan.
Jika disetel ke 0, seperti itu tidak di bawah kendali. Dinonaktifkan.