OOM Killer #

Dalam sistem operasi berbasis Linux, Out Of Memory (OOM) adalah kondisi kritis ketika sistem kehabisan memori (RAM) dan swap sehingga tidak mampu lagi memenuhi alokasi memori baru. Untuk mencegah sistem hang total, kernel Linux memiliki mekanisme darurat bernama OOM Killer.

OOM Killer bukan bug, melainkan last-resort protection mechanism. Namun dalam konteks production system, cloud, container, dan microservices, OOM Killer sering menjadi penyebab service tiba-tiba mati tanpa graceful shutdown.

Artikel ini membahas:

Apa itu OOM Killer
Bagaimana OOM Killer bekerja
Dampak OOM di sistem modern
OOM di container & Kubernetes
Best practice mencegah dan menangani OOM

Apa Itu OOM Killer? #

OOM Killer adalah bagian dari kernel Linux yang secara otomatis memilih dan membunuh satu atau lebih process ketika:

RAM habis
Swap habis atau tidak cukup cepat
Sistem berpotensi deadlock

Tujuannya satu: menyelamatkan sistem secara keseluruhan meskipun harus mengorbankan process tertentu.

Tanpa OOM Killer, sistem bisa freeze total dan tidak bisa diakses sama sekali.

Kapan OOM Terjadi? #

OOM tidak hanya terjadi karena RAM kecil, tetapi kombinasi faktor:

Memory leak di aplikasi
Traffic spike (request meledak)
Query database besar tanpa limit
Cache tak terkendali
Fork process berlebihan
Container tanpa memory limit

Diagram sederhana:

Request ↑ → Memory allocation ↑ → RAM penuh → Swap penuh
                                       ↓
                                  OOM Killer aktif

Cara Kerja OOM Killer #

Ketika OOM terjadi, kernel akan:

Menganalisis semua process aktif
Menghitung OOM score tiap process
Memilih process dengan skor tertinggi
Mengirim SIGKILL (tidak bisa ditangkap)

Faktor Penilaian OOM Score #

Besar memory yang digunakan
Apakah process root
Apakah process system critical
Nilai oom_score_adj

Contoh:

cat /proc/<pid>/oom_score
cat /proc/<pid>/oom_score_adj

Nilai oom_score_adj:

-1000 → hampir tidak akan dibunuh
0 → default
+1000 → prioritas tinggi untuk dibunuh

Dampak OOM di Production System #

OOM Killer sangat berbahaya jika tidak dipahami:

1. Service Mati Mendadak #

Tidak ada graceful shutdown
Open connection terputus
Data in-memory hilang

2. Data Corruption #

Buffer belum flush
Transaksi setengah jalan
File sementara rusak

3. Cascade Failure #

Service A mati
Retry ke service B
B overload → OOM

4. False Root Cause #

Log aplikasi tidak sempat ditulis
Sulit tracing penyebab

OOM Killer di Container (Docker) #

Dalam container environment:

OOM bisa terjadi di level container
Bisa juga di host node

Container Tanpa Memory Limit #

docker run my-app

➡️ Container bisa menghabiskan RAM host → host OOM → semua container terdampak.

Container Dengan Memory Limit #

docker run --memory=512m my-app

➡️ Jika melebihi limit:

Container langsung OOM-killed
Exit code biasanya 137

OOM di Kubernetes #

Di Kubernetes, OOM sangat umum dan sering salah dipahami.

Resource Request vs Limit #

resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "512Mi"

Melebihi limit → container OOMKilled
Node penuh → node-level OOM Killer

Status Pod:

OOMKilled

QoS Class dan OOM Priority #

Guaranteed → paling terakhir dibunuh
Burstable → tengah
BestEffort → pertama dibunuh

OOM vs Memory Leak #

Penting dibedakan:

OOM	Memory Leak
Event	Root cause
Terjadi mendadak	Bertahap
Sistem response	Bug aplikasi

OOM bukan masalah utama, tapi gejala.

Best Practice Mencegah OOM #

1. Pasang Memory Limit (WAJIB) #

Docker
Kubernetes
Systemd service

MemoryMax=512M

2. Observability Memory #

Monitor:

RSS
Heap usage
GC behavior
Page fault

Tools:

Prometheus + Grafana
cAdvisor
pprof

3. Defensive Coding #

Batasi ukuran payload
Streaming besar (chunked)
Pagination query
Hindari load all ke memory

Anti-pattern:

SELECT * FROM orders;

4. Circuit Breaker & Backpressure #

Batasi concurrency
Tolak request sebelum overload
Queue dengan limit

OOM sering terjadi terlambat menolak request.

5. Tune Garbage Collector #

Untuk language managed:

Java: heap limit & GC policy
Go: GOMEMLIMIT
Node.js: --max-old-space-size

GC salah konfigurasi = OOM tersembunyi.

6. Atur oom_score_adj #

Lindungi process kritikal:

echo -500 > /proc/self/oom_score_adj

Gunakan hati-hati.

7. Graceful Degradation #

Cache drop saat memory tinggi
Feature disable otomatis
Load shedding

Lebih baik service degrade daripada mati.

Best Practice Saat OOM Terjadi #

Checklist:

Cek kernel log:

dmesg | grep -i oom

Identifikasi PID terbunuh
Analisis memory trend
Cari leak atau spike
Tambah limit atau optimasi

Mental Model Penting #

OOM Killer bukan musuh, tapi alarm terakhir.

Jika OOM Killer aktif di production:

Sistem sudah gagal lebih dulu
Aplikasi tidak siap menghadapi tekanan

Ringkasan Singkat #

OOM Killer = mekanisme penyelamat kernel
OOM sering fatal di production
Container & Kubernetes memperbesar risiko
Prevention jauh lebih penting daripada cure