Analisis Log OOM Kill di Hardware Node — Dampak ke VPS &

Pernah nggak kamu lagi santai kerja, tiba-tiba client WA bilang “server kok mati?” Terus kamu cek monitoring, semua normal-normal aja. Tapi pas baca log hardware node, ada baris-baris aneh yang bikin jantung dag-dig-dug — ada “Out-Of-Memory” dan “killed” di mana-mana. Ibarat kamu lagi masak di dapur, tiba-tiba listrik padam. Kompor mati, nasi setengah matang, sayurnya belum mateng — tapi kamu nggak tahu penyebabnya apa: korslet, PLN mati, atau MCB turun?

Kasus seperti ini sering banget saya temui pas handle dedicated server yang jadi host buat puluhan VPS. Log-nya keliatan simpel, cuma beberapa baris grep output. Tapi di balik baris-baris itu, ada cerita besar tentang bagaimana resource RAM habis dan OS nekat “bunuh” proses untuk menjaga stabilitas sistem. Artikel ini akan bongkar habis apa yang sebenarnya terjadi dari log OOM kill yang kamu dapatkan dari hardware node, dan yang lebih penting — apa dampaknya ke VPS-VPS yang hosted di atasnya.

Log Asli: Apa Sebenarnya yang Terjadi?

Oke, kita mulai dari log yang kamu dapatkan. Ini output dari command grep di hardware node:

Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309738 (request 6) killed by signal 15: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/debugfs.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309758 (request 9) killed by signal 15: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/apps.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309775 (request 12) killed by signal 15: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/systemd-journal.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309807 (request 17) killed by signal 15: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/network-viewer.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 4189230 (request 8497) killed by signal 15: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/tc-qos-helper.sh 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309753 (request 8) killed by signal 9: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/go.d.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309781 (request 13) killed by signal 9: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/ebpf.plugin 1"
Jul 25 03:06:24 vm-server-32 spawn-plugins[2308522]: SPAWN SERVER: child with pid 2309725 (request 4) killed by signal 9: /bin/sh -c "exec /opt/netdata/usr/libexec/netdata/plugins.d/journal-viewer-plugin 1"
Jul 25 03:06:55 vm-tvi-32 netdata[104923]: Out-Of-Memory (OOM) score is already set to the wanted value 0
Jul 25 03:06:56 vm-tvi-32 netdata[104923]: DBENGINE memory protection enabled. Netdata will limit DBENGINE memory usage to help keep at least 5GiB of system RAM available when possible and reduce OOM risk. System memory total: 219.78GiB, currently available: 42.19GiB, use all RAM for caches: disabled

Nah, kita bedah baris per baris ya biar jelas.

Baris 1-5: Signal 15 (SIGTERM) — graceful kill

Lima proses Netdata plugin di-kill pakai signal 15 (SIGTERM). Ini adalah “cara sopan” OS minta proses untuk berhenti. Signal 15 itu kayak kamu ngetok pintu rumah orang — “Permisi, tolong keluar ya.” Proses masih diberi waktu buat cleanup sebelum mati.

Plugin yang kena signal 15:

• debugfs.plugin — debugging filesystem
• apps.plugin — monitoring per-application resource usage
• systemd-journal.plugin — log collection dari systemd journal
• network-viewer.plugin — monitoring koneksi jaringan
• tc-qos-helper.sh — traffic control & QoS management

Baris 6-8: Signal 9 (SIGKILL) — forced kill

Tiga proses lainnya di-kill pakai signal 9 (SIGKILL). Ini versi “kasar” — langsung dibunuh tanpa ampun. Sama kayak kamu dobrak pintu rumah orang. Proses nggak bisa cleanup, langsung dihentikan paksa. Signal 9 ini biasanya muncul kalau proses nggak mau mati meskipun sudah dikasih SIGTERM.

Plugin yang kena signal 9:

• go.d.plugin — Go-based data collection module
• ebpf.plugin — eBPF-based kernel monitoring
• journal-viewer-plugin — log viewer

Baris 9-10: Netdata OOM Protection

Ini bagian paling penting. Netdata mendeteksi bahwa OOM score-nya sudah diatur ke 0 (artinya Netdata dilindungi dari OOM killer). Tapi yang lebih krusial adalah baris terakhir:

Dengan RAM available yang segitu, dan Netdata mengaktifkan DBENGINE memory protection untuk menjaga minimal 5GiB RAM tersedia, situasi ini menunjukkan bahwa hardware node sedang dalam kondisi RAM usage yang tinggi. Dan ketika RAM makin sempit, OOM killer diaktifkan untuk membunuh proses yang dianggap “boros” RAM.

Kenapa Netdata Plugin yang Jadi Korban?

Pertanyaan bagus. Kenapa proses Netdata yang di-kill, bukan proses VPS atau application lain?

Jadi begini — Netdata itu jalan di level host (hardware node), bukan di dalam VPS. Netdata mengumpulkan data monitoring dari seluruh sistem, termasuk VPS-VPS yang hosted di atasnya. Proses-proses Netdata plugin itu seperti “pekerja” yang bertugas mengumpulkan data dari berbagai sumber.

Ketika RAM mulai menipis, Linux OOM killer bekerja dengan cara memberikan score ke setiap proses. Proses dengan OOM score tertinggi akan jadi korban pertama. Beberapa plugin Netdata memang menggunakan RAM yang cukup signifikan — terutama go.d.plugin dan ebpf.plugin yang berjalan di memory-intensive mode.

Dampak ke VPS yang Berada di Hardware Node Tersebut

Ini yang paling kritis. Ketika OOM killer aktif di hardware node, dampaknya ke VPS bisa sangat beragam tergantung situasi:

1. Monitoring VPS Hilang Sementara

Karena Netdata plugin yang di-kill, data monitoring untuk beberapa menit (sampai Netdata restart plugin-nya) tidak tersedia. Kamu nggak akan bisa lihat CPU usage, memory usage, disk I/O, dan network traffic VPS kamu di dashboard Netdata selama periode ini.

2. VPS Tidak Langsung Terdampak (Untungnya)

Dalam kasus ini, yang di-kill adalah proses Netdata di level host, bukan proses di dalam VPS. Jadi VPS-VPS yang berjalan di hardware node tersebut tidak langsung mati atau crash. Mereka tetap berjalan normal. Ini berbeda dengan skenario di mana OOM killer membunuh proses VPS itu sendiri.

3. Risiko di Masa Depan

Kondisi ini adalah early warning. Jika RAM usage di hardware node terus naik dan nggak ditangani, skenario berikutnya bisa lebih parah: OOM killer mulai membunuh proses VPS, yang artinya service di VPS bisa mati mendadak — website down, database crash, application error.

4. Performa VPS Bisa Menurun

Ketika RAM host menipis, sistem operasi mulai melakukan memory swapping — memindahkan data dari RAM ke disk (swap space). Swap di disk jauh lebih lambat dibanding RAM, sehingga seluruh sistem (termasuk VPS) bisa mengalami penurunan performa yang signifikan.

Troubleshooting: Commands yang Perlu Dijalankan

Setelah menemukan log OOM kill di hardware node, berikut langkah-langkah yang perlu kamu lakukan:

free -h

ps aux --sort=-%mem | head -20

dmesg | grep -i oom

cat /var/log/messages | grep -i "out of memory"

slabtop -s c

vmstat 1 10

cat /proc/meminfo | grep -E "MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree"

cat /proc/vmstat | grep oom

Step 1: Cek dmesg untuk Detail OOM Kill

dmesg | grep -i oom

Output-nya akan memberikan detail lebih lengkap tentang proses mana yang di-kill, berapa banyak RAM yang dibutuhkan vs tersedia, dan score OOM dari setiap proses.

2. Identifikasi Proses Boros RAM

ps aux --sort=-%mem | head -20

Dari sini kamu bisa lihat proses mana yang paling banyak makan RAM. Kalau ada VPS tertentu yang RAM usage-nya abnormal tinggi, itu perlu ditindaklanjuti.

3. Cek Apakah Ada Memory Leak

# Monitor selama 5 menit
vmstat 1 300 | tee /tmp/vmstat-monitor.txt

Perhatikan kolom si (swap in) dan so (swap out). Kalau angkanya terus-terusan tinggi, ada masalah memory yang serius.

Root Cause: Kenapa RAM Bisa Habis?

Berdasarkan log yang kita analisis, ada beberapa kemungkinan root cause:

Solusi & Pencegahan

1. Optimasi Netdata Memory Usage

Netdata sudah mengaktifkan DBENGINE memory protection, tapi kita bisa lebih agresif lagi:

# Edit konfigurasi Netdata
cat /etc/netdata/netdata.conf | grep -A 10 "[db]"

Pastikan setting berikut ada:

[db]
    mode = dbengine
    storage tier = 3
    page cache size = 32M
    dbengine disk space = 1G
    dbengine multihost disk space = 2G
    memory mode = dbengine
    OOM score = 0

2. Set OOM Score Adjustment untuk Proses Kritis

# Set OOM score Netdata ke -500 (sangat diproteksi)
echo -500 > /proc/$(pgrep netdata)/oom_score_adj

# Cek OOM score saat ini
cat /proc/$(pgrep netdata)/oom_score_adj

3. Monitor RAM Usage Secara Proaktif

Buat script monitoring sederhana:

#!/bin/bash
# Script: ram-monitor.sh
THRESHOLD=85
AVAILABLE=$(free -m | awk '/^Mem:/{print $7}')
TOTAL=$(free -m | awk '/^Mem:/{print $2}')
USAGE=$((100 - (AVAILABLE * 100 / TOTAL)))

if [ $USAGE -gt $THRESHOLD ]; then
    echo "WARNING: RAM usage at ${USAGE}%" | mail -s "RAM Alert" admin@domain.com
    # Log ke syslog
    logger -p warning "RAM usage critical: ${USAGE}% available: ${AVAILABLE}MB"
fi

Jalankan script ini via cron setiap 5 menit:

*/5 * * * * /root/scripts/ram-monitor.sh

4. Batasi RAM per VPS

Pastikan total RAM allocation untuk semua VPS tidak melebihi 80% dari RAM fisik host. Misalnya, host punya 220GiB RAM, maka total alokasi VPS sebaiknya tidak lebih dari ~176GiB.

5. Identifikasi & Handle VPS yang Overcommit

# List semua VPS dan RAM usage-nya (Proxmox example)
qm list

# Detail RAM usage per VM
for vm in $(qm list | awk 'NR>1{print $1}'); do
    echo "VM $vm: $(qm status $vm 2>/dev/null)"
done

Pro Tips dari Pengalaman

FAQ

Kesimpulan

Log OOM kill di hardware node itu bukan hal yang bisa diabaikan. Ibarat lampu check engine di mobil — mungkin masih bisa jalan, tapi kamu harus segera bawa ke bengkel sebelum mogok di tengah jalan.

Dari analisis log di atas, kita bisa simpulkan bahwa hardware node dengan 220GiB RAM sedang mengalami tekanan memory. Netdata plugin di-kill sebagai bentuk perlindungan, dan situasi ini harus segera ditangani sebelum dampaknya merambat ke VPS-VPS yang hosted di atasnya.

Langkah pertama yang harus kamu lakukan sekarang: cek free -h dan ps aux --sort=-%mem | head -20 di hardware node untuk mengetahui siapa yang paling banyak makan RAM. Dari situ, kamu bisa tentukan langkah selanjutnya — apakah perlu migrasi VPS, optimasi aplikasi, atau upgrade RAM host.

Jangan tunggu sampai client kamu WA lagi bilang “server mati.” Cegah sekarang, sebelum terlambat.

Butuh bantuan analisis log hardware node atau optimasi resource VPS? Hubungi tim NOC kami untuk konsultasi gratis.