Bagaimana pembunuh OOM memutuskan proses mana yang harus dibunuh terlebih dahulu?

Jawaban ini menjelaskan tindakan yang diambil oleh kernel ketika situasi OOM ditemui berdasarkan nilai sysctl vm.overcommit_memory.

Ketika overcommit_memorydiatur ke 0 atau 1, overcommitdiaktifkan, dan program diizinkan untuk mengalokasikan lebih banyak memori daripada yang sebenarnya tersedia.

Sekarang apa yang terjadi ketika kita kehabisan memori dalam situasi ini? Bagaimana pembunuh OOM memutuskan proses mana yang harus dibunuh terlebih dahulu?

Jika memori habis digunakan oleh proses, sejauh yang mungkin dapat mengancam stabilitas sistem, maka pembunuh OOM muncul dalam gambar.

CATATAN: Adalah tugas Pembunuh OOM untuk melanjutkan proses pembunuhan sampai cukup banyak memori yang dibebaskan untuk kelancaran fungsi dari sisa proses yang coba dijalankan oleh Kernel.

Pembunuh OOM harus memilih proses terbaik untuk dibunuh. Terbaik di sini merujuk pada proses yang akan membebaskan memori maksimum setelah membunuh dan juga yang paling tidak penting bagi sistem.

Tujuan utamanya adalah untuk membunuh jumlah proses yang meminimalkan kerusakan yang dilakukan dan pada saat yang sama memaksimalkan jumlah memori yang dibebaskan.

Untuk memfasilitasi ini, kernel memelihara sebuah oom_scoreuntuk setiap proses. Anda dapat melihat oom_scoremasing-masing proses dalam sistem /procfile di bawah piddirektori.

$ cat /proc/10292/oom_score

Semakin tinggi nilai dari oom_scoresetiap proses, semakin tinggi kemungkinan terbunuh oleh Pembunuh OOM dalam situasi di luar memori.

Bagaimana cara OOM_Scoremenghitungnya?

Dalam set patch David, heuristik kejahatan lama () hampir seluruhnya hilang. Sebagai gantinya, perhitungan berubah menjadi pertanyaan sederhana tentang berapa persen dari memori yang tersedia yang digunakan oleh proses. Jika sistem secara keseluruhan kekurangan memori, maka "memori yang tersedia" adalah jumlah dari semua RAM dan ruang swap yang tersedia untuk sistem.

Jika sebaliknya, situasi OOM disebabkan oleh kehabisan memori yang diizinkan untuk cpuset / kelompok kontrol yang diberikan, maka "memori yang tersedia" adalah jumlah total yang dialokasikan untuk kelompok kontrol tersebut. Perhitungan serupa dibuat jika batas yang diberlakukan oleh kebijakan memori telah terlampaui. Dalam setiap kasus, penggunaan memori dari proses dianggap sebagai jumlah dari set residennya (jumlah halaman RAM yang digunakannya) dan penggunaan swapnya.

Perhitungan ini menghasilkan angka persen-kali-sepuluh sebagai hasilnya; suatu proses yang menggunakan setiap byte dari memori yang tersedia untuk itu akan memiliki skor 1000, sedangkan proses yang tidak menggunakan memori sama sekali akan mendapatkan skor nol. Ada sedikit perubahan heuristik untuk skor ini, tetapi kode masih mengurangi sejumlah kecil (30) dari skor proses yang dimiliki root dengan anggapan bahwa mereka sedikit lebih berharga daripada proses yang dimiliki pengguna.

Satu tweak lain yang diterapkan adalah menambahkan nilai yang disimpan dalam variabel oom_score_adj setiap proses, yang dapat disesuaikan melalui / proc. Kenop ini memungkinkan penyesuaian daya tarik setiap proses dengan pembunuh OOM di ruang pengguna; mengaturnya ke -1000 akan menonaktifkan sepenuhnya membunuh OOM, sementara pengaturan ke +1000 adalah setara dengan melukis target besar pada proses terkait.

Referensi

http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326