Selama bertahun-tahun, pembunuh OOM sistem operasi saya tidak berfungsi dengan baik dan menyebabkan sistem beku.
Saat penggunaan memori sangat tinggi, seluruh sistem cenderung "beku" (bahkan:menjadi sangat lambat) selama jam atau bahkan hari , alih-alih mematikan proses untuk mengosongkan memori.
Maksimum yang saya rekam adalah 7 hari sebelum mengundurkan diri untuk mengoperasikan reset.
Saat OOM akan tercapai, iowait sangat sangat tinggi (~ 70%), sebelum menjadi tidak terukur.
Alat:iotop telah menunjukkan bahwa setiap program membaca pada throughput yang sangat tinggi (per puluhan MB/detik) dari hard drive saya.
Program apa yang sedang dibaca ?
– Hirarki direktori ?
– The kode yang dapat dieksekusi itu sendiri ?
Saya tidak melakukannya sekarang.
[edit] Pada saat saya menulis pesan ini (tahun 2017) saya menggunakan ArchLinux (4.9.27-1-lts) yang terbaru, tetapi sudah mengalami masalah ini selama bertahun-tahun sebelumnya.
Saya pernah mengalami masalah yang sama dengan berbagai distribusi Linux dan konfigurasi perangkat keras yang berbeda.
Saat ini (2019), saya menggunakan Debian 9.6 (4.9.0) yang terbaru
Saya memiliki 16 GB ram fisik, SSD tempat OS saya diinstal, dan bukan swap partisi.
Karena jumlah ram yang saya miliki, saya tidak ingin mengaktifkan partisi swap, karena itu hanya akan menunda munculnya masalah.
Juga, dengan terlalu sering menukar SSD berpotensi mengurangi masa pakai disk.
Omong-omong, saya sudah mencoba dengan dan tanpa partisi swap, terbukti hanya menunda kemunculan masalah, tetapi bukan solusi.
Bagi saya masalahnya disebabkan oleh fakta bahwa Linux menjatuhkan data penting dari cache , yang mengarah ke sistem beku karena harus membaca semuanya, setiap saat dari hard drive.
Saya bahkan bertanya-tanya apakah Linux tidak akan menghapus halaman kode yang dapat dieksekusi dari program yang sedang berjalan, yang akan menjelaskan mengapa program yang biasanya tidak membaca banyak data, berperilaku seperti ini dalam situasi ini.
Saya telah mencoba beberapa hal dengan harapan dapat memperbaiki masalah ini.
Salah satunya adalah menyetel /proc/sys/vm/min_free_kbytes ke 1000000 (1 GB).
Karena ini 1 GB seharusnya tetap bebas, saya pikir memori ini akan dicadangkan oleh Linux untuk menyimpan data penting.
Tapi tidak berhasil.
Juga, saya pikir berguna untuk menambahkan bahwa meskipun secara teori kedengarannya bagus, membatasi ukuran memori virtual ke ukuran memori fisik, dengan mendefinisikan /proc/sys/vm/overcommit_memory ke 2 secara teknis tidak memungkinkan dalam situasi saya, karena jenis aplikasi yang saya gunakan, memerlukan lebih banyak memori virtual daripada yang mereka gunakan secara efektif karena beberapa alasan.
Menurut file /proc/meminfo , Commited_AS nilainya sering kali lebih tinggi dari dua kali lipat ram fisik di sistem saya (16 GB, Commited_AS sering> 32 GB).
Saya mengalami masalah ini dengan /proc/sys/vm/overcommit_memory ke nilai defaultnya: , dan untuk sementara saya mendefinisikannya menjadi:1 , karena saya lebih suka program dibunuh oleh pembunuh OOM daripada berperilaku salah karena mereka tidak memeriksa nilai kembalian malloc ketika alokasi ditolak.
Saat saya membicarakan masalah ini di IRC , Saya telah bertemu dengan pengguna Linux lain yang pernah mengalami masalah yang sama, jadi saya rasa banyak pengguna yang khawatir dengan hal ini.
Bagi saya ini tidak dapat diterima karena bahkan Windows lebih baik menangani penggunaan memori yang tinggi.
Jika Anda memerlukan informasi lebih lanjut, punya saran, tolong beri tahu saya.
Dokumentasi:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www. kernel.org/doc/Documentation/sysctl/vm.txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/ 317814/
Mereka membicarakannya:
Mengapa linux out-of-memory (OOM) killer tidak berjalan secara otomatis, tetapi bekerja pada sysrq-key?
Mengapa OOM-killer terkadang gagal membunuh resource hog?
Memuat Pembunuh OOM
Apakah mungkin untuk memicu OOM-killer pada pertukaran paksa?
Bagaimana cara menghindari latensi tinggi di dekat situasi OOM?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843
Jawaban yang Diterima:
Saya telah menemukan dua penjelasan (hal yang sama) mengapa kswapd0 tidak pembacaan disk konstan terjadi jauh sebelum OOM-killer menghentikan proses yang menyinggung:
- lihat jawaban dan komentar dari jawaban SE askubuntu ini
- lihat jawaban dan komentar David Schwartz tentang jawaban ini di unix SE
Saya akan mengutip di sini komentar dari 1. yang benar-benar membuka mata saya mengapa saya mendapatkan pembacaan disk yang konstan saat semuanya dibekukan:
Misalnya, pertimbangkan kasus di mana Anda tidak memiliki swap dan sistem
hampir kehabisan RAM. Kernel akan mengambil memori dari mis.
Firefox (ini dapat dilakukan karena Firefox menjalankan kode yang dapat dieksekusi
yang telah dimuat dari disk – kode tersebut dapat dimuat dari disk
lagi jika diperlukan). Jika Firefox kemudian perlu mengakses RAM itu lagi N
detik kemudian, CPU menghasilkan “hard fault” yang memaksa Linux untuk
membebaskan sebagian RAM (mis. mengambil sebagian RAM dari proses lain), memuat
data hilang dari disk dan kemudian biarkan Firefox melanjutkan seperti biasa.
Ini sangat mirip dengan swapping normal dan kswapd0 melakukannya. – Mikko
Rantalainen 15 Februari pukul 13:08
Jika ada yang memiliki cara untuk menonaktifkan perilaku ini (mungkin mengkompilasi ulang kernel dengan opsi apa?), beri tahu saya sesegera mungkin! Sangat dihargai, terima kasih!
PERBARUI: Satu-satunya cara yang saya temukan sejauh ini adalah dengan menambal kernel, dan ini bekerja untuk saya dengan swap yang dinonaktifkan (mis. CONFIG_SWAP is not set ) tetapi tampaknya tidak berfungsi untuk orang lain dengan swap diaktifkan; lihat patch di dalam pertanyaan ini.