Buku Panduan SRE Linux: Penyelesaian Masalah Pembunuhan OOM dalam Pengeluaran

Senario

Aplikasi kritikal pada pelayan Linux pengeluaran sering ditamatkan oleh Out-Of-Memory (OOM) Killer, menyebabkan gangguan perkhidmatan.

Gejala

• Aplikasi ranap; permintaan pelanggan gagal
• Log sistem menunjukkan mesej OOM Killer: dmesg | grep -i oom output mengandungi Killed process
• Penggunaan memori meningkat secara beransur-ansur; free -m menunjukkan memori tersedia menurun
• top atau htop menunjukkan satu atau lebih proses menggunakan memori yang besar

Diagnosis

1. Sahkan kejadian OOM killer: dmesg -T | grep -i 'oom-killer' atau journalctl -k | grep -i oom
2. Lihat penggunaan memori semasa: free -h, cat /proc/meminfo, vmstat -s
3. Kenal pasti pemboros memori: ps aux --sort=-%mem | head atau top -o %MEM
4. Analisis mendalam pemetaan memori proses: pmap -x <PID> | sort -n -k2 | tail atau smem -t -p -k | sort -n
5. Periksa had memori cgroup (jika menggunakan kontena): cat /sys/fs/cgroup/memory/memory.usage_in_bytes
6. Periksa konfigurasi memori sistem: sysctl vm.overcommit_memory, sysctl vm.panic_on_oom

Arahan

# Lihat kejadian OOM terkini
dmesg -T | grep -i 'oom-killer'

# Semak jumlah dan memori terpakai
free -h

# Senarai proses diisih mengikut penggunaan memori
ps aux --sort=-%mem | head -20

# Peta memori terperinci bagi satu proses (contoh PID 12345)
pmap -x 12345 | sort -n -k2 | tail -10

# Guna smem untuk melihat USS/PSS
smem -t -p -k -c "pid username command pss uss"

# Pelarasan sementara tingkah laku OOM
echo 2 > /proc/sys/vm/overcommit_memory  # lumpuhkan overcommit
echo 0 > /proc/sys/vm/panic_on_oom      # biasanya 0, 1 menyebabkan kernel panic

# Mulakan semula perkhidmatan bermasalah (contoh: nginx)
systemctl restart nginx

Kawalan Risiko

• Sebelum membunuh proses, sahkan ia selamat ditamatkan (contoh: systemctl status untuk semak sama ada ia perkhidmatan teras).
• Gunakan renice +10 -p <PID> untuk merendahkan keutamaan proses bermasalah, mungkin mengelakkan OOM segera.
• Menetapkan vm.overcommit_memory=2 mengurangkan overcommit, tetapi boleh menyebabkan kegagalan peruntukan memori; lakukan ketika trafik rendah.
• Jika proses adalah perniagaan yang sah, pertimbangkan menambah memori fizikal atau had cgroup.

Rollback

• Jika proses salah dibunuh, mulakan semula perkhidmatan menggunakan perintah: systemctl start <service> atau jalankan skrip secara manual.
• Jika perubahan sysctl menyebabkan masalah, pulihkan ke lalai: bash sysctl -w vm.overcommit_memory=0 sysctl -w vm.panic_on_oom=0 atau pulihkan dari sandaran /etc/sysctl.conf.

Pengesahan

• Pantau MemAvailable dalam /proc/meminfo untuk kestabilan.
• Periksa dmesg tiada mesej OOM killer baru.
• Titik akhir pemeriksaan kesihatan aplikasi mengembalikan HTTP 200.
• Ujian beban dengan trafik normal mengesahkan tiada kebocoran memori.

Bila Menghantar Tiket OpsGlobal

• Punca utama masih tidak jelas selepas mengikuti langkah di atas.
• Penalaan parameter kernel memerlukan perubahan global pengeluaran.
• Disyaki pepijat kernel atau perlu persediaan pemantauan profesional (cth: Prometheus + Grafana).
• Perlu jurutera OpsGlobal membantu mencipta skrip pemulihan automatik atau runbook tersuai.