Bisakah Anda mengatur ukuran buffer disk linux minimum?

Saya memiliki mesin Linux yang agak tua dengan ram 2GB, tanpa swap, dan bekerja dengan sangat baik, dengan sistem menggunakan setiap bagian memori yang tidak digunakan untuk melakukan caching dengan efek yang luar biasa.

Namun, ketika saya hampir menekankan memori (mis., Dialokasikan> 1950MB), itu melambat untuk merangkak; Saya menduga itu karena tidak ada buffer disk yang tersisa. Saya tahu bahwa pembunuh OOM akan segera berlaku, tetapi biasanya tidak sampai di sana - itu menjadi sangat lambat sehingga beban menembak hingga 30-40, tidak ada proses membuat kemajuan (sehingga tidak mengalokasikan lebih banyak memori), dan Saya harus me-restart itu.

Ketika saya mencoba untuk hanya mematikan satu proses untuk membuat mesin merespons, misalnya dengan masuk ke konsol (melalui Alt-F1, masuk, dan hanya melakukan "proses killall bad",) biasanya berfungsi, kecuali bahwa saya harus menunggu ~ 10 menit antara pengguna / kata sandi dan mendapatkan prompt - semua saat ada aktivitas disk.

Sekali lagi, tidak ada swap, jadi tidak bertukar - itu hanya meronta-ronta karena tidak ada buffer yang tersisa.

Saya akan memiliki 100MB atau lebih yang didedikasikan khusus untuk buffer disk, yang akan memicu pembunuh OOM lebih awal (bagaimanapun, lebih sedikit memori untuk program) tetapi di sisi lain akan membuat mesin responsif setiap saat.

Apakah ada cara untuk melakukan itu? Saya belum dapat menemukan entri / proc / kernel atau / sys / vm yang melakukan hal semacam ini.

linux cache

— HopelessN00b
sumber

Saya juga memiliki masalah yang sama, dan sayangnya tidak ada jawaban untuk tanggal ini yang membantu dalam masalah ini.

— Krišjānis Nesenbergs

Jawaban:

Lihatlah / proc / sys / vm / min_free_kbytes . Ini adalah batas kbytes gratis yang memicu oom-killer. Juga akan baik untuk memeriksa di log untuk kata kunci oom-pembunuh untuk mengetahui apa yang sedang dibunuh {propably Anda tidak ingin membunuh ssh , Anda lebih baik untuk Renice itu}

— Nikolaidis Fotis
sumber

Terima kasih. Saya memperbesarnya, tetapi itu tampaknya tidak menyelesaikan masalah - setelah memori fisik hampir habis, tidak ada memori buffer yang tersisa, dan mesin melambat menjadi merangkak.

Tidak ada bantuan di sini, sistem masih berjalan sepenuhnya tidak responsif.

— Tronic

Ini sebenarnya membantu saya, saya juga punya ram 2GB dan saya mengatur ini hampir 500MB - untuk saat ini tidak ada perlambatan /

— hangup

Saat ini saya sedang menguji pengaturan ini di workstation saya. Saya memiliki 8 GB RAM dan sebagian besar waktu saya tidak menggunakan lebih dari 5 ... kecuali ketika karena alasan tertentu saya harus menjalankan VM Windows yang membutuhkan sekitar 4 GB RAM. Saya sudah mengatur ZRAM pada OS host saya karena hard drive saya mekanis, tetapi masih menjadi sangat lambat dengan RAM yang hampir penuh karena ruang RAM yang rendah untuk buffer dan cache sistem file. Saya baru saja menggunakan vm.min_free_kbytes untuk memastikan saya selalu memiliki minimal 2 GB gratis dan sisanya di-paged ke zip RAM (yang jauh lebih cepat daripada ruang swap normal). Akan dikirim nanti dengan hasil.

— RAKK

Menunggu oom-killer untuk membebaskan memori sama seperti menunggu mesin berhenti di mobil Anda untuk memberi tahu Anda kapan saatnya mengisi tangki bensin Anda. Oom-killer adalah alat berat dari upaya terakhir dan keputusasaan untuk mesin yang kekurangan sumber daya. Itu membunuh program berikutnya yang disentuhnya tanpa mempertimbangkan bagaimana ini akan mempengaruhi aplikasi Anda, jangkauan, keandalan, dan sebagainya. Ketika oom-killer dipanggil, server Anda terengah-engah dan dalam kondisi kritis.

Sebaliknya, Anda jauh lebih baik mengambil pendekatan aktif dalam mengelola penggunaan memori Anda dalam lingkungan aplikasi Anda. Anda dapat memonitor / proc / meminfo untuk masalah dan mengambil tindakan yang tepat dan mempercepat kembali beban kerja Anda sebelum situasi serius menjadi buruk.

— tylerl
sumber

Situasi yang saya temukan adalah tepat waktu di mana server saya terengah-engah dan dalam kondisi kritis. Dibutuhkan kurang dari 20 detik dari mesin yang sepenuhnya responsif hingga 1 menit untuk merespons Ctrl-Alt-F1 (beralih dari X ke konsol). Dan masuk tidak mungkin karena waktu habis setelah 1 menit bahkan tanpa meminta kata sandi. Ini adalah mesin yang memiliki banyak proses berjalan; masing-masing secara mandiri BUKAN masalahnya. Juga, ini benar-benar masalah memori - CPU baik-baik saja, dan disk baik-baik saja selama ada sekitar 50 MB buffer disk yang tersisa.

bagaimana jika Anda menggunakan ulimit dan jika aplikasi menggunakan lebih dari ambang untuk mengambil tindakan?

— Nikolaidis Fotis

Masalahnya adalah jumlah semua aplikasi; 20 atau lebih sedang berjalan, masing-masing dengan alokasi 20-100 MB. Ini berfungsi dengan baik selama berminggu-minggu, bahkan berbulan-bulan, tetapi ketika mereka semua ingin memiliki ~ 100MB dialokasikan pada saat yang sama, semuanya macet dan terbakar; Saya lebih suka oom_killer membunuh salah satunya daripada saya harus reboot mesin. Bagaimanapun, saya telah mengaktifkan swap untuk saat ini - sebagian besar aplikasi tidak menggunakan semua memori mereka sepanjang waktu, sehingga mesin tetap stabil bahkan ketika ditekan hingga akhir memori fisik; Namun, saya lebih suka tidak memiliki swap sama sekali untuk mesin ini, jika saya bisa.

Tidak menyelesaikan masalah aktual yang merupakan kombinasi dari tidak menetapkan batas penggunaan memori yang tepat (ulimits tidak terlalu berguna), aplikasi dengan mudah menjadi malapetaka dengan alokasi memori, pembunuh OOM gagal untuk memecat cukup awal dan disk besar sampah dan tidak responsif disebabkan oleh semua itu. Saya hanya menghabiskan 30 menit dari waktu majikan saya karena mesin pengembangan akan menghancurkan disk selama setengah jam saat mengkompilasi kode saya, daripada hanya membunuh proses Chromium yang diperlukan untuk membunuh (atau mengkompilasi sendiri) dalam waktu kurang dari satu detik kemudian dilakukan dengan itu.

— Tronic

Jika Anda mengatur oom_adjdengan benar, Anda dapat memiliki sistem desktop Anda bekerja sedikit seperti Android di mana sistem praktis selalu berjalan melawan pembunuh OOM (secara teknis ada "pembunuh memori rendah" dan disetel melalui /sys/module/lowmemorykiller). Logikanya adalah untuk terus menandai proses latar belakang non-kritis sebagai korban potensial untuk pembunuh OOM dan mencari proses yang terbunuh dan secara perlahan memulai kembali program yang diperlukan untuk menghindari terbebani sistem. Pastikan saja bahwa proses yang terus meluncurkan kembali proses lain ditandai di luar batas untuk pembunuh OOM.

— Mikko Rantalainen