Pembunuh OOM tidak bekerja dengan benar, mengarah ke OS beku

23

Selama bertahun-tahun, pembunuh OOM sistem operasi saya tidak berfungsi dengan benar dan mengarah ke sistem beku.
Ketika penggunaan memori sangat tinggi, seluruh sistem cenderung "membeku" (pada kenyataannya: menjadi sangat lambat) selama berjam - jam atau bahkan berhari - hari , alih-alih mematikan proses untuk membebaskan memori.
Maksimum yang saya rekam adalah 7 hari sebelum mengundurkan diri untuk mengoperasikan reset.
Ketika OOM akan dicapai, iowait sangat sangat tinggi (~ 70%), sebelum menjadi tidak terukur.
Alat: iotoptelah 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?
- Kode yang dapat dieksekusi itu sendiri?
Saya tidak tahu persis sekarang.

[diedit] Pada saat saya menulis pesan ini (pada 2017) saya menggunakan ArchLinux uptodate (4.9.27-1-lts), tetapi sudah mengalami masalah ini selama bertahun-tahun sebelumnya.
Saya telah 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 uptodate. Saya memiliki ram fisik 16 GB , SSD tempat OS saya dipasang, dan bukan partisi swap .

Karena jumlah ram yang saya miliki, saya tidak ingin mengaktifkan partisi swap, karena itu hanya akan menunda kemunculan masalah.
Juga, dengan menukar SSD terlalu sering berpotensi mengurangi masa pakai disk.
By the way, saya sudah mencoba dengan dan tanpa partisi swap, itu terbukti hanya menunda kemunculan masalah, tetapi tidak menjadi solusi.

Bagi saya masalah ini 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 menjatuhkan halaman kode yang dapat dijalankan 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 mengatur /proc/sys/vm/min_free_kbyteske 1000000(1 GB).
Karena 1 GB ini harus tetap gratis, saya pikir memori ini akan dicadangkan oleh Linux untuk menyimpan data penting.
Tapi itu tidak berhasil.

Juga, saya pikir berguna untuk menambahkan bahwa bahkan jika itu bisa terdengar besar secara teori, membatasi ukuran memori virtual dengan ukuran memori fisik, dengan mendefinisikan /proc/sys/vm/overcommit_memoryuntuk 2tidak sopan teknis mungkin dalam situasi saya, karena jenis aplikasi yang saya gunakan, membutuhkan lebih banyak memori virtual daripada yang mereka gunakan secara efektif untuk beberapa alasan.
Menurut file tersebut /proc/meminfo, Commited_ASnilainya sering lebih tinggi dari dua kali lipat ram fisik pada sistem saya (16 GB, Commited_AS sering> 32 GB).

Saya telah mengalami masalah ini dengan /proc/sys/vm/overcommit_memorynilai defaultnya:, 0dan untuk sementara saya telah mendefinisikannya sebagai:, 1karena saya lebih suka program untuk dibunuh oleh pembunuh OOM daripada berperilaku salah karena mereka tidak memeriksa nilai pengembalian mallocketika alokasi ditolak.

Ketika saya berbicara tentang masalah ini di IRC , saya telah bertemu dengan pengguna Linux lain yang telah mengalami masalah yang sama ini, jadi saya rasa banyak pengguna yang khawatir dengan hal ini.
Bagi saya ini tidak dapat diterima karena bahkan Windows lebih baik berurusan dengan penggunaan memori yang tinggi.

Jika Anda memerlukan informasi lebih lanjut, mintalah 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 killer out-of-memory (OOM) linux tidak berjalan secara otomatis, tetapi bekerja pada sysrq-key?
Mengapa OOM-killer terkadang gagal membunuh babi sumber daya?
Preloading the OOM Killer
Apakah mungkin untuk memicu OOM-killer di swapping paksa?
Bagaimana cara menghindari latensi tinggi di dekat situasi OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

M89
sumber
1
Saya pikir ini adalah apa yang Anda harapkan, jika Anda meronta-ronta, tetapi Anda tidak benar-benar mendekati 100% "digunakan" yaitu ada terlalu banyak penggunaan memori yang didukung file, dihitung sebagai "buff / cache". (Ugh, frasa ini mengasumsikan alokasi tmpf Anda sepele, karena ini ditampilkan sebagai "buff / cache", tetapi tidak dapat diarahkan ke sistem file fisik). min_free_kbytestidak relevan, ini bukan cadangan untuk halaman yang di-cache. AFAICT tidak satu pun dari vm sysctls yang memungkinkan pemesanan memori apa pun secara khusus untuk halaman yang di-cache, yaitu membatasi alokasi MAP_ANONYMOUS :(.
sourcejedi
2
Saya telah mencari solusi untuk masalah yang tepat ini selama bertahun-tahun sekarang tanpa hasil. Saya percaya saya pertama kali melihat masalah setelah mengganti HDD saya dengan SSD, yang juga mengharuskan saya menonaktifkan swapping sama sekali, tetapi saya tidak bisa benar-benar menjamin bahwa itu tidak pernah terjadi sebelum perubahan ini, jadi mungkin tidak terkait. Saya di Archlinux btw.
brunocodutra
2
Saya baru saja diposting di forum Arch Linux tentang ini.
Ignat Insarov
1
@ dsstorefile1 Terima kasih, saya akan mencobanya. Tetapi bagaimana itu bisa memicu pembunuh OOM pasti ketika kernel dalam situasi ini tidak dapat melakukannya dengan benar?
M89
1
Ini membantu ketika chrome berhasil bocor melalui semua RAM saya ... (Meskipun saya akhirnya menambahkan partisi swap disk yang sebenarnya juga dan akhirnya ditingkatkan ke jumlah RAM yang layak)
Gert van den Berg

Jawaban:

5

Saya telah menemukan dua penjelasan (dari hal yang sama) tentang mengapa kswapd0 melakukan pembacaan disk konstan terjadi jauh sebelum OOM-killer membunuh proses yang menyinggung:

  1. lihat jawaban dan komentar dari jawaban SE askubuntu ini
  2. lihat jawabannya 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 terus membaca disk saat semuanya membeku :

Sebagai contoh, perhatikan suatu kasus di mana Anda memiliki nol swap dan sistem hampir kehabisan RAM. Kernel akan mengambil memori dari mis. Firefox (dapat melakukan ini karena Firefox menjalankan kode yang dapat dieksekusi yang telah dimuat dari disk - kode dapat diambil dari disk lagi jika diperlukan). Jika Firefox kemudian perlu mengakses RAM itu lagi N detik kemudian, CPU menghasilkan "kesalahan keras" yang memaksa Linux untuk membebaskan beberapa RAM (misalnya mengambil beberapa RAM dari proses lain), memuat data yang hilang dari disk dan kemudian memungkinkan Firefox untuk melanjutkan biasa. Ini sangat mirip dengan swapping normal dan kswapd0 melakukannya. - Mikko Rantalainen 15 Feb jam 13:08

Jika ada yang memiliki cara untuk menonaktifkan perilaku ini (mungkin mengkompilasi ulang kernel dengan opsi apa? ), Tolong beri tahu saya sesegera mungkin! Sangat dihargai, terima kasih!

UPDATE: Satu-satunya cara yang saya temukan sejauh ini adalah dengan menambal kernel, dan itu berfungsi untuk saya dengan swap dinonaktifkan (mis. CONFIG_SWAP is not set) Tetapi tidak bekerja untuk orang lain dengan swap diaktifkan sepertinya ; lihat tambalan di dalam pertanyaan ini .


sumber
Harap hapus teks yang tidak valid. Jangan menandai pengeditan dengan "EDIT" dalam teks. Mereka jelas dari sejarah revisi .
Kusalananda
1
@ Kusalananda Pengguna ini harus didorong karena dia mungkin orang yang paling berkontribusi.
M89
@ Kusalananda, saya pikir penting untuk menjaga mereka agar orang lain bisa melihat apa yang dicoba dan tidak berhasil. Mungkin UPDATEalih-alih EDITlebih baik?
@MarcusLinsner Tidak, maaf, Anda salah paham. Menampilkan apa yang telah Anda coba adalah apa yang Anda lakukan ketika Anda mengajukan pertanyaan. The jawaban harus benar untuk pertanyaan seperti itu saat berpose. Maksudku, satu edit bahkan meminta pembaca untuk mengabaikan suntingan sebelumnya . Jika seseorang tertarik melihat riwayat sunting, Anda dapat melihatnya di sini .
Kusalananda
0

The memory.minparameter dalam cgroups-v2memory controller harus membantu.

Yaitu, izinkan saya mengutip:

Perlindungan memori keras. Jika penggunaan memori cgroup berada dalam batas min efektifnya, memori cgroup tidak akan direklamasi dalam kondisi apa pun. Jika tidak ada memori reklamasi tanpa pengaman yang tersedia, pembunuh OOM dipanggil.

Sumber: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

Vladimir Nikishkin
sumber
Bisakah Anda menjelaskan lebih lanjut? Jawaban Anda sedikit kurang dalam menjawab pertanyaan OP.
Paradox