Linux Tutorial (11): Performance Tuning dan Troubleshooting Production
CPU/memory/IO profiling dengan top/vmstat/iostat, strace/lsof, analisis bottleneck, dan playbook troubleshooting outage.
Saat server lambat atau down, sysadmin/SRE perlu diagnosis cepat dan tepat. Tutorial ini membahas tools profiling, interpretasi metrik, dan workflow troubleshooting yang dipakai di production.
Metodologi USE: Utilization, Saturation, Errors
Untuk setiap resource (CPU, memory, disk, network), tanyakan:
- Utilization: seberapa sibuk? (contoh: CPU 90%)
- Saturation: ada antrian/workload menunggu? (contoh: load average > core count)
- Errors: ada error counter? (contoh: NIC drops, disk I/O errors)
CPU Analysis
# Load average vs CPU cores
uptime
nproc
# Per-CPU usage
mpstat -P ALL 1 5
# Top CPU consumers
ps aux --sort=-%cpu | head -10
pidstat 1 5
# Context switches & interrupts
vmstat 1 5
# cs = context switches/sec, in = interrupts/secInterpretasi load average:
- Load 4.0 di 4-core = fully utilized
- Load 8.0 di 4-core = 2x oversubscribed (proses antri)
- Load tinggi + CPU idle tinggi = I/O wait, bukan CPU bottleneck
# I/O wait visible in top (%wa) or mpstat (%iowait)
top # lihat %wa
iostat -x 1 5 # await, %util per deviceMemory Analysis
free -h
cat /proc/meminfo | head -20
# Detail per proses
ps aux --sort=-%mem | head -10
pmap -x $(pidof nginx) | tail -1
# Slab & cache
slabtopLinux memory model, jangan panik melihat "used" tinggi:
total used free buff/cache available
↑ ↑
bukan masalah yang benar-benar bisa dipakaiavailable adalah metrik yang relevan. Linux menggunakan free RAM sebagai page cache, ini normal dan desirable.
# OOM killer log
dmesg | grep -i "out of memory"
journalctl -k | grep -i "oom"
grep -i "oom" /var/log/syslogDisk I/O Analysis
# Per-device stats
iostat -xmdz 1 5
# Kolom penting:
# %util → device busy (near 100% = saturated)
# await → avg wait time ms (high = slow disk or queue)
# r/s w/s → read/write ops per second
# rkB/s wkB/s → throughput
# Per-process I/O
sudo iotop -oP # hanya proses dengan I/O
# Identify heavy files being accessed
sudo lsof | awk '{print $9}' | sort | uniq -c | sort -rn | head -20Network Analysis
# Bandwidth per interface
sar -n DEV 1 5
ip -s link show eth0
# Connection stats
ss -s
ss -tn state time-wait | wc -l
# Packet drops/errors
netstat -i
ip -s link
# Capture traffic
sudo tcpdump -i eth0 port 443 -c 100
sudo tcpdump -i any host 10.0.0.5 -w capture.pcapstrace: System Call Tracer
# Trace system calls
strace -p $(pidof nginx) -f -e trace=network
# Debug startup hang
strace -f -o /tmp/trace.log ./slow-start-app
grep -E "EACCES|ENOENT|ECONNREFUSED" /tmp/trace.log
# Count syscalls
strace -c -p $(pidof mysql)lsof: List Open Files
# Semua open files proses
lsof -p 1234
# Port yang dibuka
lsof -i :8080
lsof -i TCP:443 -s TCP:LISTEN
# File deleted tapi masih held (space not freed!)
lsof +L1
# Fix deleted-but-open file:
# Restart proses, atau truncate via /proc/PID/fd/FDperf: Linux Profiler
sudo apt install linux-tools-common linux-tools-$(uname -r)
# CPU flamegraph data
sudo perf record -F 99 -p $(pidof app) -g -- sleep 30
sudo perf report
# Quick stat
sudo perf stat -p $(pidof app) sleep 10Troubleshooting Playbook
Scenario 1: Server Lambat
# Step 1: Quick health check (30 detik)
uptime && free -h && df -h && ss -s
# Step 2: Identify bottleneck
vmstat 1 5 # CPU vs I/O wait
iostat -x 1 5 # Disk saturation
sar -n DEV 1 5 # Network
# Step 3: Find culprit process
ps aux --sort=-%cpu | head -5
ps aux --sort=-%mem | head -5
sudo iotop -oP
# Step 4: Deep dive
strace -p CULPRIT_PID -c
lsof -p CULPRIT_PIDScenario 2: Disk Penuh
df -h
sudo du -xh /var --max-depth=2 | sort -rh | head -10
sudo lsof +L1 # deleted files still open
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500MScenario 3: Port Tidak Bisa Diakses
ss -tlnp | grep :8080 # listening?
sudo ufw status # firewall?
curl -v localhost:8080 # local works?
curl -v server-ip:8080 # remote works?
sudo tcpdump -i any port 8080 -c 10 # packets arriving?Scenario 4: Proses Hang/Zombie
ps aux | awk '$8 ~ /D/ {print}' # uninterruptible sleep (I/O)
ps aux | awk '$8 ~ /Z/ {print}' # zombie
cat /proc/PID/stack # kernel stack trace
strace -p PID # stuck on what syscall?Tuning Parameters
# /etc/sysctl.d/99-performance.conf
# Network tuning (high-traffic web server)
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
# Memory
vm.swappiness = 10 # prefer RAM over swap
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
# File descriptors
fs.file-max = 2097152# Per-service limits: /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=65535
LimitNPROC=65535# Per-user limits: /etc/security/limits.d/app.conf
appuser soft nofile 65535
appuser hard nofile 65535Monitoring Stack Overview
Metrics collection → Prometheus node_exporter / Telegraf
Visualization → Grafana
Alerting → Alertmanager / PagerDuty
Log aggregation → Loki / ELK Stack
Tracing → Jaeger / OpenTelemetry# Quick local monitoring
sudo apt install sysstat
sar -u 1 5 # CPU history
sar -r 1 5 # Memory history
sar -b 1 5 # I/O historyLatihan Praktis
- Generate CPU load:
stress --cpu 2 --timeout 30s, observe denganmpstatdantop - Generate I/O load:
stress --io 4 --timeout 30s, observe%iowaitdaniostat - Buat file 1GB, delete, tapi proses masih hold, recover space dengan
lsof +L1 - Practice full playbook: server "lambat" → identify bottleneck dalam 5 menit
Rangkuman
Performance troubleshooting = metodologi (USE) + tools yang tepat + interpretasi metrik yang benar. Load average tinggi bukan selalu CPU problem; memory "used" tinggi bukan selalu OOM. Kuasai workflow ini sebelum incident production pertama.