Membaca Log dmesg untuk Memastikan Aplikasi Dimatikan OOM Killer

Proses database seperti mysqld atau worker queue di server sering kali berhenti mendadak tanpa menyisakan jejak error di berkas log aplikasinya sendiri. Di log database atau worker, kita biasanya hanya melihat catatan restart otomatis atau proses tiba-tiba terputus di tengah query. Situasi ini kerap membingungkan karena aplikasi tidak sempat menulis stack trace atau pesan exception sebelum prosesnya hilang dari daftar proses aktif. Dalam sistem operasi Linux, saat memori fisik (RAM) dan ruang swap benar-benar habis, kernel akan mengaktifkan mekanisme proteksi yang disebut Out-Of-Memory Killer (OOM Killer). Kernel terpaksa memilih satu atau beberapa proses untuk dimatikan seketika demi menjaga integritas sistem operasi agar tidak mengalami kernel panic atau hang total. Untuk memastikan apakah proses aplikasi berhenti karena OOM Killer, kita perlu memeriksa buffer pesan kernel melalui utilitas dmesg atau log sistem.

Menemukan Jejak OOM Killer di dmesg

Kernel Linux mencatat semua aksi OOM Killer ke dalam ring buffer kernel. Kita bisa menyaring catatan ini menggunakan dmesg. Jika server menjalankan systemd, perintah journalctl -k juga bisa digunakan untuk melihat pesan kernel yang tersimpan secara persisten. Contoh perintah read-only untuk memfilter baris OOM Killer dari log kernel:

BASH

sudo dmesg -T | grep -i -E 'oom[-_]killer|killed process'

Jika OOM Killer memang aktif, terminal akan menampilkan baris peringatan seperti Out of memory: Killed process <PID> (<nama_proses>). Di sekitar baris tersebut, kernel juga biasanya menyertakan daftar proses lengkap dengan jumlah halaman memori virtual (vsize) dan memori fisik yang dialokasikan (rss atau resident set size) pada saat insiden terjadi. Penting dipahami bahwa proses yang dimatikan belum tentu merupakan biang kerok utama yang menghabiskan memori. OOM Killer menggunakan perhitungan skor (badness heuristic) yang mempertimbangkan seberapa banyak memori yang digunakan proses tersebut serta nilai preferensi sistem (oom_score_adj). Sering kali worker background yang menghabiskan RAM secara masif, tetapi database yang justru dimatikan karena memegang alokasi memori aktif terbesar saat itu. Jika layanan kamu dikelola oleh systemd dan mati tiba-tiba, ada baiknya juga meninjau status keluaran service. Pada artikel terkait, kita pernah membahas cara melacak status exit systemd untuk melihat sinyal terminasi yang diterima service, seperti sinyal SIGKILL (Signal 9) yang dipicu oleh kernel.

Memilih Solusi: Tiga Opsi Mengatasi Masalah Memori

Setelah memastikan bahwa OOM Killer memang penyebab matinya aplikasi, kita dihadapkan pada pilihan mitigasi. Tidak semua kasus OOM harus diselesaikan dengan menambah kapasitas RAM fisik, terutama bila akar masalahnya adalah kebocoran memori (memory leak) atau konfigurasi worker yang tidak terkendali. Berikut adalah panduan memilih antara tiga pendekatan umum:

Opsi 1: Menambah Kapasitas Swap atau RAM Fisik (Vertical Scaling)

Pendekatan ini adalah pilihan paling langsung jika beban kerja server memang bertumbuh secara organik dan seluruh proses yang berjalan memang membutuhkan memori riil tersebut. Menambahkan swap darurat juga sering digunakan sebagai peredam lonjakan beban (cushion) sementara agar kernel memiliki waktu untuk menukar halaman memori tidak aktif ke disk alih-alih langsung mematikan proses.

Beban kerja (Workload): Server tunggal yang menjalankan database dengan pertumbuhan data stabil, atau aplikasi monolithic yang lonjakan memorinya bisa diprediksi.
Kebutuhan keahlian (Skill level): Rendah. Menambah RAM di VPS atau membuat file swap hanya membutuhkan beberapa perintah administratif.
Risiko: Menambah swap di disk yang lambat (HDD atau I/O cloud terbatas) dapat memicu thrashing, di mana CPU habis hanya untuk membaca dan menulis swap sehingga server menjadi sangat lambat.

Opsi 2: Membatasi Konkurensi Worker dan Proses Anak

Sering kali OOM terjadi bukan karena database itu sendiri, melainkan karena server web atau antrean tugas memicu terlalu banyak worker paralel (seperti PHP-FPM, Celery, atau Puma). Setiap proses anak membutuhkan jatah RAM sendiri. Ketika lonjakan trafik terjadi bersamaan, akumulasi konsumsi RAM dari puluhan worker dapat menghabiskan seluruh sisa memori fisik server.

Beban kerja (Workload): Aplikasi web dengan lalu lintas fluktuatif atau server yang menjalankan pemrosesan berkas di latar belakang.
Kebutuhan keahlian (Skill level): Menengah. Perlu menghitung rata-rata pemakaian RAM per worker dan menyesuaikan batas maksimal proses (misalnya pm.max_children pada PHP-FPM).
Risiko: Jika batasan worker terlalu ketat, antrean permintaan akan menumpuk dan pengguna bisa mengalami connection timeout atau respon yang lambat saat jam sibuk.

Opsi 3: Tuning Alokasi Memori Aplikasi (Buffer & Pool)

Pada server database, komponen seperti pool memori internal sering kali dikonfigurasi terlalu agresif melampaui kemampuan hardware. Pembahasan mendalam mengenai penyesuaian ini dapat dipelajari di panduan memastikan ukuran InnoDB Buffer Pool sudah pas. Selain itu, membuka parameter koneksi terlalu tinggi juga membawa risiko fatal, seperti yang diulas pada dampak menaikkan max_connections di MySQL.

Beban kerja (Workload): Dedicated database server atau VPS gabungan (LAMP stack) di mana alokasi database bersaing langsung dengan web server.
Kebutuhan keahlian (Skill level): Menengah hingga tinggi. Memerlukan pemahaman tentang arsitektur internal database, alokasi memori per thread, dan alokasi global.
Risiko: Menyetel buffer terlalu kecil akan meningkatkan I/O disk (karena cache sering miss), yang berdampak pada penurunan performa query secara keseluruhan.

Panduan Komparasi Pengambilan Keputusan

Untuk mempermudah pemilihan langkah penanganan berdasarkan batasan yang kamu miliki di lapangan, perhatikan pertimbangan berikut:

Pendekatan	Biaya / Resource	Waktu Implementasi	Kapan Sebaiknya Dipilih	Kapan Harus Dihindari
Vertical Scaling (RAM / Swap)	Biaya infrastruktur bertambah	Sangat cepat	Memori server konsisten di atas 90% sepanjang hari tanpa ada lonjakan aneh	Ada indikasi memory leak pada aplikasi yang tidak kunjung reda
Limitasi Worker	Gratis (konfigurasi sistem)	Cepat (butuh observasi)	OOM hanya terjadi saat lonjakan pengunjung atau lonjakan job antrean	Aplikasi membutuhkan pemrosesan throughput tinggi yang tidak bisa ditunda
Tuning Buffer Aplikasi	Gratis (konfigurasi aplikasi)	Bertahap (memerlukan uji beban)	Database memakan porsi terbesar dan sering dimatikan OOM Killer	Beban kerja read/write sangat intensif dan memang membutuhkan cache besar

Langkah pertama saat proses aplikasi mati mendadak selalu sama: pastikan fakta teknisnya terlebih dahulu lewat log kernel dmesg sebelum berasumsi bahwa aplikasi mengalami crash internal. Dari data alokasi memori di log tersebut, kamu bisa menentukan apakah masalahnya diselesaikan dengan membatasi proses yang tamak, menyeimbangkan parameter internal aplikasi, atau memang sudah saatnya menaikkan spesifikasi server.