Belajar System Administrator - Performance Tuning

#Pendahuluan

Server yang aman (episode 18) dan diawasi (episode 19) masih bisa lambat. Episode 21 membahas performance tuning — seni menjadikan server melayani lebih banyak dengan sumber daya yang sama, berdasarkan data, bukan berdasarkan firasat.

Aturan pertama tuning: jangan men-tune tanpa pengukuran. Kebanyakan "optimasi" yang tidak berdasar data justru membuat sistem lebih buruk. Kalian akan belajar mengukur, menemukan bottleneck, lalu mengubah hal yang tepat — dan memverifikasi bahwa perubahannya benar-benar membantu.

#Ukur Dulu: Metodologi Tuning

Alur tuning yang benar (berlaku untuk semua masalah performa):

100%

Poin kritisnya: satu perubahan pada satu waktu, dan setiap perubahan diukur. Kalau tidak, kalian tidak akan pernah tahu perubahan mana yang membuat perbedaan — atau merusak.

#Tool Pengukuran Inti

Tool	Metrik	Pertanyaan yang Dijawab
`top`/`htop`	CPU, memori per proses	Proses mana yang makan sumber daya?
`free -h`	Memori & swap	RAM cukup atau sedang swap?
`iostat -x 1`	I/O disk	Disk menjadi bottleneck?
`vmstat 1`	Sistem secara keseluruhan	CPU/IO wait, swapping
`ss -s`	Network	Koneksi menumpuk?

Cuplikan diagnostik singkat

vmstat 1 5
iostat -x 1 3
ss -s

Interpretasi cepat: wa (I/O wait) tinggi = disk lambat; si/so (swap in/out) aktif = RAM kurang; Load average jauh di atas core count = CPU jenuh.

#Parameter Kernel (sysctl)

Kernel Linux punya ratusan parameter yang bisa disetel via sysctl — file /etc/sysctl.conf atau file di /etc/sysctl.d/.

#Network Tuning yang Sering Dipakai

/etc/sysctl.d/99-tuning.conf

# Tingkatkan antrean koneksi untuk server dengan banyak sesi
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
 
# Kurangi TIME_WAIT: daur ulang soket lebih cepat
net.ipv4.tcp_tw_reuse = 1
 
# Limit pemakaian file descriptor per proses
fs.file-max = 2097152

Terapkan dan verifikasi

sudo sysctl --system
sudo sysctl net.core.somaxconn

Warning

Jangan menyalin parameter kernel dari blog secara membabi buta. Setiap parameter punya trade-off — misalnya tcp_tw_reuse menghemat port tetapi bisa bermasalah dengan NAT (Common knowledge bagi sysadmin jaringan). Selalu pahami dulu apa yang diubah, dan uji di lab sebelum menyentuh produksi.

#Memory dan Overcommit

/etc/sysctl.d/99-tuning.conf (tambahan)

# Nonaktifkan swap agresif (0-10; default 60) untuk server aplikasi
vm.swappiness = 10
# Cegah OOM pada workload besar (cenderung menunda kill)
vm.overcommit_memory = 1

#Resource Limits (ulimit / cgroups)

Tanpa limit, satu proses bisa melahap seluruh sumber daya dan menjatuhkan yang lain. ulimit membatasi resource per proses/user; systemd + cgroups (di episode 3) membatasi per service.

#ulimit

Lihat dan set ulimit

ulimit -n          # file descriptor
ulimit -u          # jumlah proses
sudo nano /etc/security/limits.conf

/etc/security/limits.conf (potongan)

# nofile= file descriptor, nproc= proses
nginx   soft    nofile  65535
nginx   hard    nofile  65535

#Limit per Service (systemd)

/etc/systemd/system/my-app.service.d/limits.conf

[Service]
LimitNOFILE=65535
MemoryMax=2G
CPUQuota=200%

Ini adalah resource governance: setiap layanan tahu batasnya, sehingga satu layanan nakal tidak memadamkan yang lain. Reload: sudo systemctl daemon-reload && sudo systemctl restart my-app.

#Tuning I/O

Disk sering menjadi bottleneck tak terlihat. Dua pendekatan:

Pendekatan	Contoh	Kapan
Filesystem tuning	`noatime`, `deadline`/`none` scheduler	Server I/O umum
Database/penyimpanan	Tuning PostgreSQL/MySQL (episode 17)	Workload intensif disk

Scheduler & mount options

cat /sys/block/sda/queue/scheduler
echo deadline | sudo tee /sys/block/sda/queue/scheduler   # sementara

Mount dengan noatime

# /etc/fstab
/dev/vgdata/lvdata /data ext4 defaults,noatime 0 2

noatime menghentikan update timestamp akses pada setiap pembacaan file — penghematan I/O kecil namun nyata untuk server file dan web.

#Profiling: Menemukan yang Sulit Terlihat

Ketika alat biasa tidak cukup, profil proses — lihat ke dalam. Tool yang paling berguna untuk sysadmin:

Tool	Fungsi
`perf top`	Profil CPU secara real-time
`strace -p PID`	Lihat system calls yang dilakukan proses
`pidstat -d`	I/O per proses
`lsof`	File yang dibuka proses

Profil proses

pidstat -d 1
perf top
lsof -p $(pgrep -x mysqld) | head -20

Tip

Sebelum men-tune apa pun, tanyakan: apakah ini memang masalah performa, atau masalah desain? Server database lambat karena tuning-nya salah — atau karena aplikasi menulis query yang boros? Tuning yang benar dimulai dengan mengukur, dan jujur pada lokasi masalahnya.

#Praktik: Optimasi Server

Latihan terpadu dengan metode yang benar:

Siklus tuning berbasis data

# 1. Baseline
uptime; free -h; vmstat 1 5
# 2. Buat beban sintetis & identifikasi bottleneck
# 3. Ubah satu variabel (mis. sysctl / ulimit / mount option)
# 4. Ukur ulang dan bandingkan
uptime; free -h; vmstat 1 5
# 5. Pertahankan yang membaik, batalkan yang tidak

Catatan penting: kalian baru saja mengalami siklus measure → change → measure. Kebiasaan ini lebih berharga daripada parameter tuning mana pun — karena ia bisa diterapkan ke masalah apa pun, di sistem mana pun.

#Penutup

Inti yang harus dibawa pulang dari episode 21:

Tuning harus berbasis data: ukur, ubah satu variabel, ukur ulang.
Tool: vmstat, iostat, top, ss untuk menemukan bottleneck.
sysctl untuk network/memory; pahami trade-off sebelum mengubah.
Resource limits (ulimit/cgroups) menjaga satu proses tidak menjatuhkan yang lain.
Tuning I/O: noatime, scheduler, dan profiling (perf, strace) untuk kasus sulit.

Di episode 22 selanjutnya kita akan membahas High Availability & Failover — clustering, load balancing, dan failover otomatis, dengan praktik setup HA sederhana di lab. Server yang cepat tapi mati saat dibutuhkan sama saja dengan tidak ada!