Penyebab Proses Mati Mendadak karena OOM Killer

Pernah menemukan MySQL, PHP-FPM, atau aplikasi Node.js tiba-tiba mati, padahal tidak ada yang mematikannya dan log aplikasinya berhenti begitu saja? Salah satu tersangka paling umum adalah OOM killer (Out Of Memory killer).

OOM killer adalah bagian dari kernel Linux yang turun tangan ketika RAM dan swap benar-benar habis. Daripada seluruh sistem macet, kernel memilih satu proses untuk dimatikan secara paksa supaya memorinya bisa dipakai lagi. Kernel menyelamatkan server, tapi korbannya sering justru layanan terpenting, karena proses yang memakai memori paling banyak biasanya database atau aplikasi utama.

Bagaimana memastikan dan mengatasinya?

Langkah 1: Cari jejaknya di log kernel

Aplikasi yang dimatikan OOM killer tidak sempat menulis pesan, jadi jangan mencari di log aplikasinya. Jejaknya ada di log kernel:

journalctl -k | grep -iE "out of memory|oom-kill|killed process"

Bila journal tidak menyimpan log lama, coba dmesg -T | grep -i oom atau cari di /var/log/kern.log (Ubuntu dan Debian) atau /var/log/messages (AlmaLinux dan Rocky Linux). Baris yang dicari kurang lebih berbunyi Out of memory: Killed process 1234 (mysqld) disertai angka pemakaian memori proses itu.

Kalau barisnya diawali atau disertai Memory cgroup out of memory, yang habis bukan RAM seluruh server, melainkan batas memori sebuah grup proses, misalnya container Docker atau layanan systemd yang diberi batas MemoryMax.

Langkah 2: Cek apakah ada pembunuh lain di ruang pengguna

Sebagian distribusi Linux juga memakai systemd-oomd, yang bisa mematikan proses lebih awal berdasarkan tekanan memori, sebelum kernel turun tangan. Periksa lognya dengan journalctl -u systemd-oomd. Untuk container Docker, docker inspect --format '{{.State.OOMKilled}}' nama-container akan bernilai true bila container itu mati karena kehabisan memori.

Langkah 3: Lihat kenapa memori habis

Kehabisan memori jarang terjadi tanpa sebab. Periksa beberapa kemungkinan:

• Pengaturan aplikasi lebih besar dari RAM. Misalnya InnoDB buffer pool MySQL diatur hampir sebesar RAM, padahal server juga menjalankan web server dan PHP.
• Terlalu banyak worker. Setiap worker PHP-FPM, Apache, atau Gunicorn memakan memori. Jumlah maksimal worker dikali pemakaian rata-rata per worker harus muat di RAM yang tersisa.
• Kebocoran memori. Pemakaian memori sebuah proses naik terus dari hari ke hari dan baru turun setelah di-restart.
• Lonjakan sesaat. Impor data besar, pembuatan laporan, atau trafik yang naik mendadak.
• Tidak ada swap sama sekali, sehingga lonjakan kecil pun langsung memicu OOM.

Jalankan ps aux --sort=-rss | head -n 10 untuk melihat pemakai memori terbesar saat ini. Penting juga memahami bahwa RAM yang terlihat penuh oleh cache bukan masalah; bedanya dijelaskan di artikel RAM server selalu penuh, bahaya atau normal.

Langkah 4: Atur batas memori aplikasi

Perbaikan yang paling tahan lama adalah membuat total kebutuhan memori muat di server. Kecilkan buffer pool database bila terlalu besar, kurangi jumlah maksimal worker, atau beri batas pada pekerjaan berat. Untuk MySQL yang sering menjadi korban, artikel MySQL sering mati sendiri membahas pengaturannya lebih rinci.

Di Docker, beri batas memori per container supaya satu container yang bocor tidak menyeret seluruh server. Caranya ada di artikel membatasi CPU dan RAM container Docker.

Langkah 5: Tambahkan swap sebagai bantalan

Swap tidak menggantikan RAM, tapi memberi ruang napas saat terjadi lonjakan, sehingga kernel tidak langsung membunuh proses. Di VPS kecil, swap beberapa GB sering sudah cukup sebagai pengaman. Pertimbangan ukurannya dibahas di artikel perlukah swap di VPS kecil.

Langkah 6: Lindungi layanan terpenting

Kernel memilih korban berdasarkan skor yang bisa kamu lihat di /proc/<PID>/oom_score. Skor ini bisa digeser lewat oom_score_adj dengan rentang -1000 sampai 1000. Nilai -1000 berarti proses itu tidak akan pernah dipilih.

Untuk layanan systemd, cara yang rapi adalah membuat override dengan systemctl edit nama-layanan, lalu menambahkan:

[Service]
OOMScoreAdjust=-500

Lalu jalankan systemctl restart nama-layanan. Gunakan ini dengan hati-hati. Melindungi database berarti proses lain yang akan dimatikan, dan memberi -1000 ke terlalu banyak proses bisa membuat kernel tidak punya pilihan sehat saat memori habis.

Langkah 7: Pasang pemantauan dan restart otomatis

Tambahkan Restart=on-failure di unit systemd layanan penting supaya layanan hidup lagi bila mati, dan pasang alert untuk memori available yang menipis. Restart otomatis hanya menambal gejala; tetap cari penyebabnya dari langkah 3.

Ringkasan perintah

Checklist pencegahan

• Total pengaturan memori aplikasi muat di RAM dengan sisa untuk sistem.
• Ada swap sebagai bantalan lonjakan.
• Container dan layanan berat diberi batas memori.
• Layanan penting punya Restart=on-failure dan alert memori.
• Log kernel diperiksa setiap kali ada proses yang mati tanpa sebab.