Itu bisa.
Ada dua kondisi kehabisan memori berbeda yang dapat Anda temui di Linux. Yang Anda temui bergantung pada nilai sysctl vm.overcommit_memory (/proc/sys/vm/overcommit_memory )
Pengantar:
Kernel dapat melakukan apa yang disebut 'memory overcommit'. Ini adalah saat kernel mengalokasikan lebih banyak memori untuk program daripada yang sebenarnya ada di sistem. Hal ini dilakukan dengan harapan program tidak benar-benar menggunakan semua memori yang mereka alokasikan, karena hal ini cukup umum terjadi.
overcommit_memory =2
Ketika overcommit_memory diatur ke 2 , kernel tidak melakukan overcommit sama sekali. Alih-alih, ketika sebuah program dialokasikan memori, dijamin akses untuk memiliki memori itu. Jika sistem tidak memiliki cukup memori bebas untuk memenuhi permintaan alokasi, kernel hanya akan mengembalikan kegagalan untuk permintaan tersebut. Terserah program untuk menangani situasi dengan anggun. Jika tidak memeriksa apakah alokasi berhasil padahal benar-benar gagal, aplikasi akan sering mengalami segfault.
Dalam kasus segfault, Anda harus menemukan baris seperti ini di keluaran dmesg :
[1962.987529] myapp[3303]: segfault at 0 ip 00400559 sp 5bc7b1b0 error 6 in myapp[400000+1000]
at 0 berarti bahwa aplikasi mencoba mengakses pointer yang tidak diinisialisasi, yang mungkin merupakan hasil dari panggilan alokasi memori yang gagal (namun itu bukan satu-satunya cara).
overcommit_memory =0 dan 1
Ketika overcommit_memory disetel ke 0 atau 1 , overcommit diaktifkan, dan program diizinkan untuk mengalokasikan lebih banyak memori daripada yang sebenarnya tersedia.
Namun, ketika sebuah program ingin menggunakan memori yang dialokasikan, tetapi kernel menemukan bahwa itu sebenarnya tidak memiliki cukup memori untuk memuaskannya, program perlu mendapatkan kembali beberapa memori. Ini pertama kali mencoba melakukan berbagai tugas pembersihan memori, seperti sebagai pembilasan cache, tetapi jika ini tidak cukup maka akan menghentikan suatu proses. Pemutusan ini dilakukan oleh OOM-Killer. OOM-Killer melihat sistem untuk melihat program apa yang menggunakan memori apa, sudah berapa lama mereka berjalan, siapa yang menjalankannya, dan sejumlah faktor lain untuk menentukan mana yang dimatikan.
Setelah proses dimatikan, memori yang digunakan dibebaskan, dan program yang baru saja menyebabkan kondisi kehabisan memori kini memiliki memori yang diperlukan.
Namun, bahkan dalam mode ini, permintaan alokasi program masih dapat ditolak. Saat overcommit_memory adalah 0 , kernel mencoba menebak dengan baik kapan ia harus mulai menolak permintaan alokasi. Ketika disetel ke 1 , saya tidak yakin penentuan apa yang digunakan untuk menentukan kapan harus menolak permintaan tetapi dapat menolak permintaan yang sangat besar.
Anda dapat melihat apakah OOM-Killer terlibat dengan melihat output dari dmesg , dan menemukan pesan seperti:
[11686.043641] Out of memory: Kill process 2603 (flasherav) score 761 or sacrifice child
[11686.043647] Killed process 2603 (flasherav) total-vm:1498536kB, anon-rss:721784kB, file-rss:4228kB
Yang benar adalah bahwa terlepas dari cara Anda melihatnya - apakah proses Anda tersendat karena pengelola memori sistem atau karena hal lain - itu tetap sebuah bug. Apa yang terjadi dengan semua data yang baru saja Anda proses di memori? Seharusnya disimpan.
Sedangkan overcommit_memory= adalah cara paling umum untuk mengonfigurasi manajemen OOM Linux, ini juga dapat disesuaikan per proses seperti:
echo [-+][n] >/proc/$pid/oom_adj
Menggunakan -17 di atas akan mengecualikan proses dari manajemen kehabisan memori. Mungkin bukan ide yang bagus secara umum, tetapi jika Anda mencari bug, melakukannya bisa bermanfaat - terutama jika Anda ingin tahu apakah itu OOM atau kode Anda. Menambah angka secara positif akan membuat proses lebih mungkin untuk dimatikan dalam peristiwa OOM, yang dapat memungkinkan Anda untuk meningkatkan ketahanan kode Anda dengan lebih baik dalam situasi memori rendah dan untuk memastikan Anda keluar dengan anggun bila diperlukan.
Anda dapat memeriksa pengaturan penangan OOM saat ini per proses seperti:
cat /proc/$pid/oom_score
Kalau tidak, Anda bisa bunuh diri:
sysctl vm.panic_on_oom=1
sysctl kernel.panic=X
Itu akan mengatur komputer untuk reboot jika terjadi kondisi kehabisan memori. Anda mengatur X di atas ke jumlah detik yang Anda inginkan agar komputer berhenti setelah kepanikan kernel sebelum mem-boot ulang. Menjadi liar.
Dan jika, karena alasan tertentu, Anda memutuskan menyukainya, buatlah tetap bertahan:
echo "vm.panic_on_oom=1" >> /etc/sysctl.conf
echo "kernel.panic=X" >> /etc/sysctl.conf