Mengapa Pembunuh-OOM tidak bisa begitu saja membunuh proses yang meminta terlalu banyak?


12

Dijelaskan di sini bahwa OOM-Killer dapat dikonfigurasi melalui overcommit_memorydan bahwa:

  • 2 = tidak ada komitmen berlebihan. Alokasi gagal jika terlalu banyak bertanya.
  • 0, 1 = overcommit (heuristik atau selalu). Matikan beberapa proses berdasarkan beberapa heuristik ketika terlalu banyak memori yang sebenarnya diakses.

Sekarang, saya mungkin benar-benar salah paham akan hal itu, tetapi mengapa tidak ada opsi (atau mengapa itu bukan default) untuk mematikan proses yang sebenarnya mencoba mengakses terlalu banyak memori yang dialokasikan?


Bagaimana jika suatu proses sistem kritis meminta terlalu banyak memori?
Lawrence

Pertama - dapat melakukan hal ini. Tapi, masalah terbesar dengan pertanyaan itu adalah kemungkinan besar jika suatu proses meminta memori maka itu sedang dieksekusi baru - atau, dengan kata lain, ini adalah proses baru yang terlibat dalam pemrosesan yang sangat saat ini. Apakah Anda lebih suka OOM mengizinkan klien im Anda yang tidak dibuka untuk 3 hari untuk terus membuang-buang memori sistem atau apakah Anda lebih suka YouTube benar-benar memuat beberapa waktu tahun ini? linuxatemyram.com
mikeserv

3
Inilah yang no overcommitopsi dasarnya lakukan. Jika suatu proses meminta terlalu banyak memori, itu gagal. Jika memeriksa kesalahan, biasanya akan bunuh diri; jika tidak, itu mungkin akan mendapatkan Kesalahan Segmentasi ketika mencoba untuk mengubah referensi null pointer yang malloc()kembali, dan itu akan crash.
Barmar

Perhatikan bahwa 2 sebenarnya adalah no overcommitmode, menurut sumber yang dikutip (seperti kernel.org/doc/Documentation/vm/overcommit-accounting ). Saya pikir saya akan mengedit pertanyaan Anda sesuai.
hans_meine

Jawaban:


24

Pertimbangkan skenario ini:

  • Anda memiliki memori 4GB gratis.
  • Proses yang salah mengalokasikan 3.999GB.
  • Anda membuka pengelola tugas untuk mematikan proses pelarian. Manajer tugas mengalokasikan 0,002GB.

Jika proses yang terbunuh adalah proses terakhir untuk meminta memori, manajer tugas Anda akan terbunuh.

Atau:

  • Anda memiliki memori 4GB gratis.
  • Proses yang salah mengalokasikan 3.999GB.
  • Anda membuka pengelola tugas untuk mematikan proses pelarian. Server X mengalokasikan 0,002GB untuk menangani jendela task manager.

Sekarang server X Anda terbunuh. Itu tidak menyebabkan masalah; itu hanya "di tempat yang salah di waktu yang salah". Itu adalah proses pertama untuk mengalokasikan lebih banyak memori ketika tidak ada lagi yang tersisa, tetapi bukan proses yang menggunakan semua memori untuk memulai.


Untuk memperluas contoh Anda itu berarti bahwa jika suatu proses menghabiskan 99,999% dari memori Anda, Anda tidak akan pernah bisa membunuhnya karena apa pun yang bisa membunuhnya akan membutuhkan memori dan dengan demikian terbunuh sebelum proses yang salah bisa dibunuh!
Kereta luncur

13
Pikiran Anda, ini adalah filosofi Linux, bukan fakta yang diperlukan. Windows 3.0 menyelesaikannya dengan memiliki memori yang cukup dicadangkan untuk penanganan OOM, termasuk dialog yang diperlukan.
MSalters

@ MSalters: Itu tidak benar-benar berlaku untuk contoh, meskipun; Contohnya adalah tentang proses yang telah mencadangkan hampir semua memori, yaitu. tidak cukup untuk membuat OOM terbunuh. Jelas harus ada cukup memori yang disediakan untuk penanganan OOM pada OS apa pun. Tetapi proses yang meminta penanganan OOM akan menjadi proses selanjutnya yang terjadi untuk cadangan memori, bukan yang salah. Kecuali, tentu saja, Anda bermaksud bahwa Windows 3.0 selalu memiliki cukup memori yang disediakan untuk menjalankan task manager, atau bahwa OOM handler selalu meminta pengguna untuk mematikan proses tersebut. (Yang! = Membunuh proses yang menyinggung)
Aleksi Torhamo

3
@AleksiTorhamo: Saya memang bermaksud yang terakhir. Windows 3.0 tidak memiliki task manager penuh, itu memiliki layar biru terkenal yang ingatannya dialokasikan.
MSalters
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.