Hindari pembongkaran aplikasi kehabisan memori linux

Solusi 1:

Secara default Linux memiliki konsep manajemen memori yang agak merusak otak:ini memungkinkan Anda mengalokasikan lebih banyak memori daripada yang dimiliki sistem Anda, lalu secara acak menghentikan proses ketika mendapat masalah. (Semantik sebenarnya dari apa yang terbunuh lebih kompleks dari itu - Google "Linux OOM Killer" untuk banyak detail dan argumen tentang apakah itu hal yang baik atau buruk).

Untuk mengembalikan kewarasan manajemen memori Anda:

1. Nonaktifkan OOM Killer (Letakkan vm.oom-kill = 0 di /etc/sysctl.conf)
2. Nonaktifkan overcommit memori (Letakkan vm.overcommit_memory = 2 di /etc/sysctl.conf)
   Perhatikan bahwa ini adalah nilai trinary:0 ="perkirakan jika kita memiliki cukup RAM", 1 ="Selalu katakan ya", 2 ="katakan tidak jika kita tidak memiliki memori")

Pengaturan ini akan membuat Linux berperilaku dengan cara tradisional (jika proses meminta lebih banyak memori daripada yang tersedia malloc() akan gagal dan proses yang meminta memori diharapkan dapat mengatasi kegagalan tersebut).

Nyalakan ulang mesin Anda untuk memuat ulang /etc/sysctl.conf , atau gunakan proc sistem file untuk segera diaktifkan, tanpa reboot:

echo 2 > /proc/sys/vm/overcommit_memory 

Solusi 2:

Anda dapat menonaktifkan overcommit, lihat http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Solusi 3:

Jawaban singkatnya, untuk sebuah server, adalah membeli dan memasang lebih banyak RAM.

Server yang cukup rutin mengalami OOM (Kehabisan Memori), maka selain opsi overcommit sysctl manajer VM (memori virtual) di kernel Linux, ini bukan hal yang baik.

Meningkatkan jumlah swap (memori virtual yang telah dikeluarkan ke disk oleh manajer memori kernel) akan membantu jika nilai saat ini rendah, dan penggunaannya melibatkan banyak tugas, masing-masing sejumlah besar memori, daripada satu atau beberapa memproses setiap permintaan sejumlah besar dari total memori virtual yang tersedia (RAM + swap).

Untuk banyak aplikasi yang mengalokasikan lebih dari dua kali (2x) jumlah RAM sebagai swap memberikan hasil perbaikan yang semakin berkurang. Dalam beberapa simulasi komputasi besar, ini mungkin dapat diterima jika penurunan kecepatan dapat ditahan.

Dengan RAM (ECC atau tidak) cukup terjangkau untuk jumlah sedang, mis. 4-16 GB, harus saya akui, saya sendiri sudah lama tidak mengalami masalah ini.

Dasar-dasar dalam melihat konsumsi memori termasuk menggunakan free dan top , diurutkan berdasarkan penggunaan memori, sebagai dua evaluasi cepat paling umum dari pola penggunaan memori. Jadi, pastikan Anda setidaknya memahami arti dari setiap kolom dalam output dari perintah tersebut.

Tanpa aplikasi spesifik (misalnya basis data, server layanan jaringan, pemrosesan video real-time) dan penggunaan server (beberapa pengguna daya, 100-1000 koneksi pengguna/klien), saya tidak dapat memikirkan rekomendasi umum apa pun sehubungan dengan berurusan dengan masalah OOM.

Solusi 4:

Anda dapat menggunakan ulimit untuk mengurangi jumlah memori yang boleh diklaim oleh suatu proses sebelum dimatikan. Ini sangat berguna jika masalah Anda adalah satu atau beberapa proses lari yang merusak server Anda.

Jika masalah Anda adalah Anda tidak memiliki cukup memori untuk menjalankan layanan yang Anda perlukan, hanya ada tiga solusi:

1. Kurangi memori yang digunakan oleh layanan Anda dengan membatasi cache dan sejenisnya

2. Buat area swap yang lebih besar. Ini akan membebani Anda dalam kinerja, tetapi dapat memberi Anda waktu.

3. Beli lebih banyak memori

Solusi 5:

Meningkatkan jumlah memori fisik mungkin bukan respons yang efektif dalam segala situasi.

Salah satu cara untuk memeriksa ini adalah perintah 'di atas'. Terutama dua baris ini.

Ini keluar server saat masih sehat:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Ketika itu berjalan buruk (dan sebelum kami menyesuaikan overcommit_memory dari 50 menjadi 90, kami akan melihat perilaku dengan vmcom berjalan lebih dari 50G, oom-killer meledakkan proses setiap beberapa detik, dan beban terus memantul secara radikal karena proses anak NFSd meledak dan dibuat ulang terus-menerus.

Kami baru-baru ini menggandakan kasus di mana server terminal Linux multi-pengguna secara besar-besaran melakukan over-commit alokasi memori virtual tetapi sangat sedikit halaman yang diminta yang benar-benar digunakan.

Meskipun tidak disarankan untuk mengikuti rute persis ini, kami menyesuaikan memori overcommit dari default 50 menjadi 90 yang mengatasi beberapa masalah. Kami akhirnya harus memindahkan semua pengguna ke server terminal lain dan memulai ulang untuk melihat manfaat penuh.