menerima sinyal sebelum proses dibunuh oleh OOM killer / cgroups

11

Di cluster kami, kami membatasi sumber daya proses kami, misalnya memori ( memory.limit_in_bytes).

Saya pikir, pada akhirnya, ini juga ditangani melalui pembunuh OOM di kernel Linux (sepertinya itu dengan membaca kode sumber ).

Apakah ada cara untuk mendapatkan sinyal sebelum proses saya terbunuh? (Sama seperti -notifyopsi untuk SGEqsub , yang akan mengirim SIGUSR1sebelum prosesnya terbunuh.)

Saya membaca di /dev/mem_notify sini tapi saya tidak memilikinya - apakah ada sesuatu yang lain saat ini? Saya juga membaca ini yang sepertinya agak relevan.

Saya ingin setidaknya dapat membuang jejak stack kecil dan mungkin beberapa info debug berguna lainnya - tapi mungkin saya bahkan dapat memulihkan dengan membebaskan beberapa memori.

Satu solusi yang saat ini saya gunakan adalah skrip kecil ini yang sering memeriksa apakah saya tutup (95%) hingga batasnya dan jika demikian, ia mengirimkan proses a SIGUSR1. Di Bash, saya memulai skrip ini di latar belakang ( cgroup-mem-limit-watcher.py &) sehingga ia mengawasi procs lain di cgroup yang sama dan berhenti secara otomatis ketika proses induk Bash mati.

— Albert
sumber

Saya tidak dapat menemukan sumber otoritas, atau saya tidak dapat menemukan cara untuk memanggil pembunuh OOM untuk proses spesifik secara manual (untuk menguji ide) , tetapi dari apa yang saya temukan tampaknya pembunuh OOM hanya mengirimkan SIGTERM, jadi Anda harus mengatur seorang pawang untuk sinyal ini.

— Hi-Angel

5

@ Hi-Angel: Dari kode sumber Linux , tampaknya ia mengirimkan SIGKILL.

— Albert

@Albert Setelah membaca kode sumber, saya juga berpikir bahwa OOM Killer akan langsung mengirim sinyal SIGKILL.

— andy

5

Mungkin untuk mendaftar pemberitahuan ketika penggunaan memori cgroup melampaui ambang batas. Pada prinsipnya, menetapkan ambang pada titik yang sesuai di bawah batas yang sebenarnya akan membiarkan Anda mengirim sinyal atau mengambil tindakan lain.

Lihat:

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

— Chris Emerson
sumber

5

Pembunuh OOM memang mengirimkan SIGKILL karena jika tidak demikian akan menjadi kontraproduktif untuk membiarkan program yang bermasalah menjadi pilihan untuk melanjutkan.

Ini berarti bahwa sama sekali tidak ada cara bagi proses untuk mengetahui kapan akan terbunuh olehnya.

Mengelola masalah seperti itu biasanya menyiratkan membuat koreksi ke program atau konfigurasinya. Kadang-kadang, tergantung pada konfigurasi sistem, hanya menambah ruang swap dapat memberikan OS lebih banyak fleksibilitas manajemen memori untuk menghindari tindakan drastis tersebut.

— Julie Pelletier
sumber