Belajar System Engineer - Performance & Tuning

#Pendahuluan

Sejauh ini kita membangun, mengotomasi, memantau, dan mengamankan sistem. Ada satu pertanyaan yang selalu muncul saat sistem sudah berjalan: "kenapa lambat?" Episode 16 ini menjawabnya dengan benar — bukan lewat tebakan, melainkan lewat profiling berbasis data.

Mengapa episode ini penting? Karena "sistem lambat" adalah masalah paling sering yang ditangani System Engineer, dan hampir selalu disalahpahami. Orang cenderung langsung membeli hardware baru atau menambah instance. Padahal solusi sejati lahir dari mengukur: apa bottleneck-nya? CPU, memory, disk I/O, atau jaringan? Episode ini mengajarkan metodologi tuning: ukur dulu, hipotesis, ubah satu variabel, ukur lagi.

#Metodologi: Ukur Sebelum Tuning

#Urutan Profiling yang Benar

Pendekatan USE (Utilization, Saturation, Errors) oleh Brendan Gregg adalah kerangka yang paling praktis untuk server:

1. Utilization — seberapa sibuk resource (CPU 90% = sibuk).
2. Saturation — seberapa banyak antrean menunggu (run queue, IO wait).
3. Errors — ada error/retry?

Terapkan ke CPU, memory, disk, dan jaringan. Seringnya bottleneck tidak terlihat dari satu metrik saja.

#Toolkit Profiling Dasar

uptime                # load average (1/5/15 menit)
vmstat 1 5            # proses, memori, swap, IO, cpu tiap detik
iostat -x 2 3         # perangkat disk: util, await, queue
sar -q 2 5            # run queue & load
free -h               # memori + cache
ss -s                 # ringkasan socket

#Profiling CPU

#Identifikasi Proses Terberat

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10
pidstat -u 2 5        # penggunaan CPU per proses per interval

#Flamegraph untuk Deep Dive

Untuk mencari di mana CPU dibakar (fungsi apa), gunakan perf untuk menghasilkan flamegraph:

sudo perf record -F 99 -p <pid> -g -- sleep 30
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg

Jika beban CPU tinggi tapi berasal dari interrupt atau kernel (bukan user space), kemungkinan besar ini masalah network/driver — bukan aplikasi.

#Profiling Memory

#Kekurangan Memori dan Swap

free -h
vmstat 1 5 | grep -E "si|so"     # swap in/out aktif = tekanan memori
ps aux --sort=-%mem | head -10

si/so yang terus bergerak berarti sistem aktif swap — memori kurang. Solusi yang benar tidak selalu menambah RAM: bisa jadi aplikasi bocor memori, atau tuning vm.swappiness (episode 3) bisa membantu.

#OOM Killer

Saat memori benar-benar habis, kernel membunuh proses terbesar via OOM killer. Jejaknya di dmesg:

dmesg -T | grep -i "out of memory" | tail
journalctl -k | grep -i oom | tail

OOM yang sering muncul adalah sinyal serius: bisa jadi limits container salah (episode 15), leak, atau kapasitas memang kurang.

#Profiling Disk I/O

#Metrik yang Harus Dibaca

iostat -x 2 3

Fokus pada tiga kolom:

Pola umum: %util tinggi + await tinggi = disk benar-benar jenuh. %util rendah tapi await tinggi = antrean di belakang disk (misal satu disk yang dipakai banyak VM).

#IOPS dan Latensi

Untuk database, yang penting bukan throughput tapi latency per request. Gunakan fio untuk mengukur kemampuan disk yang sebenarnya:

sudo fio --name=test --rw=randread --bs=4k --size=1G --numjobs=1 \
  --iodepth=1 --runtime=30 --time_based

Perhatikan lat (usec) avg — untuk SSD NVMe, single-thread latency di bawah 200 us adalah wajar; jika jauh di atas itu, ada masalah (busy VM, RAID, atau QoS).

#Tuning Kernel dan Aplikasi

#Tuning Kernel

Parameter umum yang sering diubah (cara permanen di sysctl.d, seperti episode 3):

# Kurangi swap pada server aplikasi
vm.swappiness=10
# File descriptor & port range untuk layanan sibuk
fs.file-max=2097152
net.ipv4.ip_local_port_range=1024 65535
# Backlog koneksi lebih besar
net.core.somaxconn=4096

#Tuning Aplikasi

Sebelum menyentuh kernel, periksa lapisan aplikasi:

Aturan kunci: satu perubahan, satu pengukuran. Ubah max_connections saja, ukur, bandingkan baseline — jangan ubah lima parameter sekaligus.

#Praktik: Tuning Sistem

Skenario: aplikasi web di server melambat di jam sibuk.

# 1. Baseline
uptime; vmstat 1 5; iostat -x 2 3
 
# 2. Cek bottleneck (misal: CPU saturation, r=8 pada 4 core)
top -b -n1 | head -15
 
# 3. Ubah SATU variabel, misal: naikkan worker nginx dari 4 ke 8
sudo sed -i 's/worker_processes 4;/worker_processes 8;/' /etc/nginx/nginx.conf
sudo nginx -t && sudo systemctl reload nginx
 
# 4. Ukur ulang setelah stabil
vmstat 1 5
# 5. Bandingkan: r menurun? throughput naik? Dokumentasikan hasilnya

#Kesalahan Umum

1. Tuning tanpa pengukuran baseline — tidak bisa tahu apakah perubahan membantu.
2. Ubah banyak parameter sekaligus — tidak tahu mana yang bekerja.
3. Menambah RAM/hardware duluan — tanpa profiling, boros biaya.
4. Mengabaikan swap aktivitas — memori kurang sudah jelas tapi diabaikan.
5. Menyalin tuning config dari artikel tanpa konteks — parameter harus disesuaikan workload.

#Penutup

Inti yang harus dibawa pulang:

• Gunakan kerangka USE: Utilization, Saturation, Errors untuk CPU/mem/disk/jaringan.
• Toolkit: vmstat (saturation CPU & swap), iostat (latency disk), perf (flamegraph), dmesg (OOM).
• Metodologi: baseline → hipotesis → ubah satu variabel → ukur ulang → dokumentasikan.
• Kernel tuning via sysctl.d; aplikasi/web/database sering jadi sumber asli bottleneck.

Di episode 17 selanjutnya kita menjaga sistem tetap aman dari ancaman yang berkembang: patch & vulnerability management — siklus hidup patch, pelacakan CVE, dan maintenance windows. Sampai jumpa di episode 17!