Apakah mungkin untuk membuat OOM killer intervent lebih awal?

34

Saya mencoba untuk men-tweak sistem pengembangan saya untuk keandalan maksimal. Saya menonaktifkan swap, karena untuk penggunaan GUI sebagian besar membuat mesin tidak responsif sehingga tidak bisa digunakan lagi. Namun demikian, jika aplikasi yang agresif memakan memori, beberapa mekanisme tampaknya menghasilkan yang maksimal dari biaya kecepatan. Tidak ada operasi swap harddisk, tetapi sistemnya juga tidak responsif. Jadi saya ingin membiarkan pembunuh OOM menendang sebelum sistem melakukan upaya khusus untuk mendapatkan memori. Apakah mungkin untuk mengkonfigurasi pembunuh OOM untuk bertindak jika ada kurang dari 100 MB memori fisik misalnya?

linux-kernel memory-management

— dronus
sumber

2

Saya pikir masalah sebenarnya di sini adalah, tidak ada cukup ram untuk memulai. Anda tidak akan menggunakan swap kecuali tidak ada ram. Dengan mematikan swap ... Anda kehabisan ram dan tidak punya tempat untuk menyimpannya. Yang menyebabkan hal-hal buruk terjadi. Sistem Anda tampaknya disetel dengan buruk, dan tidak ada jumlah penyesuaian yang akan memperbaikinya.

— Journeyman Geek

8

Saya tidak setuju. Pengembangan dan 'penggunaan daya' sering melibatkan penggunaan eksperimental. Misalnya, saat menggunakan alat pengolah gambar baris perintah, tidak ada spesifikasi berapa banyak memori yang diambil operasinya terkait dengan ukuran gambar. Jadi saya hanya mencobanya. Dan saya tidak berharap itu membuat seluruh mesin saya tidak berguna. Untuk satu percobaan, saya bisa menggunakan ulimit untuk menjaganya tetap aman, tetapi untuk seluruh operasi sistem dengan terkadang banyak operasi, penahanan satu proses tidak begitu berguna tetapi 'asuransi jiwa' untuk seluruh mesin pasti adalah.

— dronus

1

Fakta bahwa sistem Anda berhenti ketika menggunakan swap dicurigai. Komputer Anda menggunakan swap karena kehabisan memori. Swap melambat karena akses disk lambat. Akses disk lambat karena ??? Masalahnya semua jalan turun. Bukan hanya karena Anda kekurangan ram. Anda tidak dapat menggunakan satu cara untuk mengurangi itu karena sesuatu yang lain.

— Journeyman Geek

7

@JourneymanGeek, Anda tidak aktif di bidang kiri. Disk lambat dibandingkan dengan ram, titik, maka swapping berat selalu membuat sistem terhenti. Tentu saja dia kehabisan memori karena dia mencoba menjalankan program yang menggunakan banyak memori. Pertanyaannya adalah apa yang harus dilakukan ketika kehabisan memori? Bunuh babi, atau perlambat karena tidak memiliki memori tersisa untuk cache disk.

— psusi

2

@ TomWijsman, Disk IO adalah banyak perintah yang besarnya lebih lambat dari memori IO, jadi menggunakan disk swap selalu berarti perlambatan yang sangat besar. Kadang-kadang (terutama di masa lalu di mana ram mahal dan kebanyakan orang tidak punya banyak) itu lebih baik daripada tidak bisa melakukan apa yang Anda coba sama sekali. Hari-hari ini disk SO jauh lebih lambat dari ram, dan ram cukup murah bahwa kebanyakan orang memiliki banyak, sehingga pada kesempatan langka di mana mereka sengaja menjalankan sesuatu yang menggunakan lebih ram dari yang mereka miliki, sering lebih baik menyerah daripada take 1000 kali selama melakukannya.

— psusi

36

Saya juga berjuang dengan masalah itu. Saya hanya ingin sistem saya tetap responsif, apa pun yang terjadi, dan saya lebih suka kehilangan proses daripada menunggu beberapa menit. Sepertinya tidak ada cara untuk mencapai hal ini menggunakan kernel oom killer.

Namun, di ruang pengguna, kami dapat melakukan apa pun yang kami inginkan. Jadi saya menulis Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) yang akan mematikan proses terbesar (dengan RSS) setelah RAM yang tersedia berjalan di bawah 10%.

Tanpa awal, mudah untuk mengunci mesin saya (RAM 8GB) dengan memulai http://www.unrealengine.com/html5/ beberapa kali. Sekarang, tab browser yang bersalah terbunuh sebelum hal-hal tidak terkendali.

— Jakob
sumber

3

Terima kasih telah menggaruk gatal ini! Mencintai sejak dini sejauh ini.

— Thomas Ferris Nicolaisen

1

Baru tahu Android melakukan hal yang sama untuk waktu yang lama. Saya tidak yakin apakah itu menggunakan kode khusus seperti milik Anda untuk itu.

— Dronus

1

Saya menguji earlyoomsekarang, itu baik dalam tes pemicu pertama. Saya hanya ingin tahu mengapa ini tidak dapat diimplementasikan oleh konfigurasi kernel atau alat sistem.

— dronus

12

Kebijakan default kernel adalah mengizinkan aplikasi untuk tetap mengalokasikan memori virtual selama ada memori fisik yang kosong. Memori fisik tidak benar-benar digunakan sampai aplikasi menyentuh memori virtual yang mereka alokasikan, sehingga aplikasi dapat mengalokasikan lebih banyak memori daripada yang dimiliki sistem, kemudian mulai menyentuhnya nanti, menyebabkan kernel kehabisan memori, dan memicu keluar pembunuh memori (OOM). Sebelum proses hogging dimatikan, ia telah menyebabkan cache disk dikosongkan, yang membuat sistem lambat merespons untuk sementara waktu hingga cache diisi ulang.

Anda dapat mengubah kebijakan default untuk melarang overcommit memori dengan menulis nilai 2 menjadi /proc/sys/vm/overcommit_memory. Nilai defaultnya /proc/sys/vm/overcommit_ratioadalah 50, sehingga kernel tidak akan mengizinkan aplikasi untuk mengalokasikan lebih dari 50% ram + swap. Jika Anda tidak memiliki swap, maka kernel tidak akan mengizinkan aplikasi untuk mengalokasikan lebih dari 50% dari ram Anda, meninggalkan 50% lainnya gratis untuk cache. Itu mungkin sedikit berlebihan, jadi Anda mungkin ingin meningkatkan nilai ini untuk mengatakan, 85% atau lebih, sehingga aplikasi dapat mengalokasikan hingga 85% dari ram Anda, menyisakan 15% untuk cache.

— psusi
sumber

1

Mengubah nilai-nilai ini dari standar di sana tanpa latar belakang teoritis tidak akan mencapai dalam sistem yang lebih andal, Anda hanya bisa membenarkan perubahan itu dengan statistik yang tepat. Hanya karena Anda dapat mengubahnya bukan berarti Anda harus mengubahnya. Jika Anda terus-menerus dalam kondisi memori rendah itu berarti Anda menggunakan lebih banyak memori daripada yang Anda miliki dan harus membeli lebih banyak memori, itu tidak berarti Anda harus mengutak-atik pengaturan Anda dan membunuh aplikasi acak. Mengganggu pekerjaan harian Anda atau memperkenalkan korupsi, itu benar-benar bukan cara untuk pergi ...

— Tamara Wijsman

3

@ TomWijsman, pertanyaannya memperjelas bahwa dia tidak terus-menerus dalam kondisi memori rendah; dia kadang-kadang menjalankan perintah yang mengambil banyak sekali memori. Membeli lebih banyak memori bukan satu-satunya solusi ketika Anda kehabisan. Solusi potensial lainnya termasuk menemukan cara yang lebih baik untuk menggunakan memori yang Anda miliki, atau hanya tidak melakukan apa pun yang membutuhkan banyak memori. Pertanyaannya memperjelas bahwa yang terakhir lebih dapat diterima daripada pergi keluar dan membeli lebih banyak ram.

— psusi

Baris mana dalam pertanyaan yang membuat ini jelas? Saya melihat kebalikannya diberikan I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Dia menyebutkan GUI, sementara Anda mengasumsikan dia menjalankan perintah. Membeli lebih banyak memori adalah solusi pertama, menggunakan lebih sedikit memori sendiri adalah solusi kedua, membuat sistem Anda tidak stabil dengan mengutak-atik standar stabil adalah solusi terakhir. Pertanyaannya tidak harus dijawab secara harfiah, jadi saya tidak melihat apa masalah Anda sehingga Anda harus mengganggu kami berdua di komentar. Kata-kata kasar tidak membantu ...

— Tamara Wijsman

4

Hei, jawaban ini terdengar sangat keren. Sayangnya, 'komit' sepertinya merujuk pada permintaan memori virtual, yang diperkirakan cukup buruk oleh pemrogram aplikasi. Misalnya dengan saya (tidak ada swap) berjalan desktop ada sekitar 400 dari 2000MB memori fisik yang digunakan, tetapi 1600mb 'commit'ted sebagai /proc/meminfo' s Committed_ASnegara. Dengan beberapa aplikasi berjalan, nilai ini dengan mudah melebihi memori fisik sehingga sulit untuk menetapkan batas yang masuk akal dengan ini.

— dronus

3

Simpan pekerjaan Anda sebelum mencoba ini! : PI mengalami kegagalan langsung dari segalanya (bash, window manager dll).

— jozxyqk

8

Bagi saya pengaturan vm.admin_reserve_kbytes = 262144 melakukan hal ini. OOM killer mengintervensi sebelum sistem benar-benar tidak responsif.

— Michael Vigovsky
sumber

1

Saya suka ide, tetapi apakah ini berarti Anda memiliki memori fisik 256MiB yang tidak pernah digunakan?

— Jérôme Pouiller

1

256MiB akan digunakan untuk cache. Cache sangat penting, ini bukan tentang hanya berjalan lebih cepat, sistem tidak akan berfungsi sama sekali jika tidak ada cukup memori untuk cache. Kode setiap program yang berjalan dapat diturunkan dari memori karena ini mmaped dan dapat dibaca kembali dari disk. Tanpa cache, setiap switch tugas memerlukan pembacaan disk dan sistem akan menjadi benar-benar tidak responsif.

— Michael Vigovsky

4

Jawaban lain memiliki solusi otomatis yang baik, tetapi saya merasa dapat membantu juga mengaktifkan SysRqkunci ketika hal-hal keluar dari tangan. Dengan SysRqkuncinya, Anda akan mengirim pesan ke kernel secara manual, dan Anda dapat melakukan hal-hal seperti reboot yang aman (dengan SysRQ + REISUB) bahkan jika userspace telah benar-benar beku.

Untuk memungkinkan kernel mendengarkan permintaan, setel kernel.sysrq = 1, atau aktifkan fungsi yang mungkin Anda gunakan dengan bitmask (didokumentasikan di sini ). Misalnya kernel.sysrq = 244akan mengaktifkan semua kombo yang diperlukan untuk boot ulang yang aman di atas serta permintaan manual dari pembunuh OOM SysRq + F.

— timuzhti
sumber

-2

Keandalan tidak tercapai oleh kondisi memori rendah dan pembunuh OOM.

Adalah salah untuk mengatur pesta di lemari dan menempatkan "membersihkan lemari saya" di daftar putar kecil Anda.

Apakah mungkin untuk membuat OOM killer intervent lebih awal?

Melakukan ini akan memiliki hasil samping yang tidak diinginkan, karena Anda tidak memiliki kendali atas apa yang terbunuh.

Saya mencoba untuk men-tweak sistem pengembangan saya untuk keandalan maksimal.

Keandalan maksimal melibatkan pengujian sistem Anda dan peningkatan sistem Anda berdasarkan tes-tes ini.

Hanya mengutak - atik hal-hal acak tidak akan membawa Anda ke mana pun ...

Saya menonaktifkan swap, karena untuk penggunaan GUI sebagian besar membuat mesin tidak responsif sehingga tidak bisa digunakan lagi. Namun demikian, jika aplikasi yang agresif memakan memori, beberapa mekanisme tampaknya menghasilkan yang maksimal dari biaya kecepatan.

Karena kondisi memori yang rendah, menonaktifkan swap tidak akan meningkatkan perilaku , itu sebaliknya .

Untuk meningkatkan keandalan dalam situasi ini, tambahkan lebih banyak memori sehingga sistem Anda lebih responsif dan tidak ada proses acak yang dimatikan tanpa niat pengguna. Anda seharusnya tidak menggunakan kondisi dengan memori rendah dan mekanisme seperti ini, terutama di lingkungan pengembangan ...

Tidak ada operasi swap harddisk, tetapi sistemnya juga tidak responsif.

Kondisi memori yang rendah memang mengakibatkan tidak ada respons, apakah Anda memiliki swap atau tidak.

Jadi saya ingin membiarkan pembunuh OOM menendang sebelum sistem melakukan upaya khusus untuk mendapatkan memori.

Upaya khusus yang akan melakukan lebih banyak kerusakan daripada kebaikan, seperti yang saya jelaskan di atas. Sebagai gantinya, Anda dapat membunuh proses yang tidak Anda butuhkan sendiri, tetapi saya kira Anda tidak dapat melakukannya sehingga OOM akan membunuh proses yang Anda butuhkan.

Apakah mungkin untuk mengkonfigurasi pembunuh OOM untuk bertindak jika ada kurang dari 100 MB memori fisik misalnya?

Mungkin, tetapi Anda mendapatkan pengembalian investasi yang lebih tinggi jika Anda hanya membeli beberapa memori tambahan yang tidak terlalu mahal akhir-akhir ini. Pertimbangkan bahwa Anda akan memukul diri sendiri dalam jangka panjang jika Anda terus bekerja pada kondisi memori rendah. OOM seperti juru sita, itu tidak membantu Anda, itu membantu OS ...

— Tamara Wijsman
sumber

7

Tentu saja menonaktifkan swap meningkatkan perilaku karena alih-alih meronta-ronta disk, OOM menendang dan membunuh babi memori. Kehabisan ram bukanlah masalahnya (dan menambahkan lebih banyak berarti Anda harus berusaha lebih keras untuk kehabisan). Masalahnya adalah apa yang harus dilakukan ketika Anda DO kehabisan. Anda ingin OOM untuk membunuh babi, dan dengan demikian meringankan kondisi memori rendah.

— psusi

7

Karena mematikan aplikasi yang mencoba menggunakan lebih banyak memori daripada yang Anda miliki lebih disukai untuk membuat seluruh sistem bertekuk lutut. Di dunia yang sempurna Anda akan memiliki memori tidak terbatas dan tidak pernah kehabisan, tetapi dalam kenyataannya, kadang-kadang Anda kehabisan karena kecelakaan dan lebih suka diberitahu "tidak cukup memori" daripada membuat sistem terhenti.

— psusi

5

Membeli beberapa memori tambahan dapat menyelesaikan beberapa masalah, tergantung pada jumlah yang dibeli. Tapi itu tidak mengubah fakta bahwa mungkin ada penggunaan tak terduga oleh perintah besarnya. Jadi saya ingin aplikasi gagal, tetapi BUKAN sistem dalam kondisi seperti itu. Beberapa contoh: Memproses folder yang penuh dengan gambar yang dikompresi, sebagian besar berukuran "normal", tetapi beberapa di antaranya sangat besar. Sebuah kesalahan kecil bisa membuat loop mati dengan memory runaway memakan 1GB / s. Secara tidak sengaja membuka file video dalam editor teks. Biasanya ini berakhir dengan gejala-gejala seperti tikus yang tersentak-sentak dan UI yang hampir mati sampai OOM muncul.

— dronus

6

@ TomWijsman ada juga loop hampir mati karena ada algoritma yang berperilaku linier dalam kasus rata-rata tetapi eksponensial dalam kasus terburuk, tergantung pada data input. Dan saya tidak dapat mengirim sinyal kill jika mouse tersentak dan klik serta input keyboard menunjukkan latensi satu menit. Saya biasanya berubah ke terminal mode teks kemudian dan menunggu beberapa menit untuk login untuk melanjutkan hanya untuk mengeluarkan killsecara acak.

— dronus

7

Saya tidak punya masalah dengan membunuh aplikasi yang akan mati juga. Pertimbangkan sistem dengan 2GB fisik + 2GB swap. Aplikasi yang cepat kehabisan memori fisik dapat dengan mudah memakan swap juga. Itu hanya akan mati kemudian, setelah membuat sistem tidak responsif selama beberapa menit hingga berjam-jam. Jadi mengapa tidak membunuhnya dengan cepat sebelum operasi GUI terkelupas? Banyak proses melakukan semua pekerjaan mereka dengan 10MB, beberapa mengambil 1GB, dan beberapa langka membutuhkan 10GB, itu hidup.

— dronus