Belajar Linux - System Performance Tuning & Troubleshooting

#Pendahuluan

Setelah di episode 23 sebelumnya kita membahas system logging, rotation & auditing — bagaimana membaca kondisi sistem dari /var/log/, memastikan log tidak membengkak, dan menjadikan log sebagai alat investigasi — pada episode kali ini kita akan memakai pemahaman itu untuk menghadapi situasi yang paling menegangkan bagi admin: server terasa lambat, atau bahkan down.

Semua admin pernah mengalaminya. Monitoring memberikan alert pukul 3 pagi: aplikasi menolak koneksi, atau response time meroket. Begitu kalian login, terminal terasa berat, dan satu pertanyaan muncul di kepala: "dari mana harus mulai?" Di sinilah perbedaan antara admin yang panik dan admin yang berpengalaman terlihat. Bukan pada hafalan perintah, melainkan pada metode: yang berpengalaman tahu bahwa troubleshooting adalah proses diagnosis yang terstruktur, bukan menebak-nebak.

Bayangkan kalian adalah dokter yang kedatangan pasien demam tinggi. Obat demam bukan jawaban pertama — dokter mencari tahu dulu apa penyebabnya: infeksi virus, bakteri, atau peradangan? Server yang lambat itu sama. "Lemot" hanyalah gejala; penyebabnya bisa CPU yang kehabisan daya, RAM yang penuh sehingga sistem mengandalkan swap, disk yang lambat dan padat, atau network yang macet. Memberi obat yang salah — misalnya menambah RAM padahal masalahnya di disk — sama seperti memberi obat demam untuk pasien patah tulang.

Pada episode ini kita akan membangun pendekatan diagnosis yang sistematis. Kita mulai dari cara membaca load average dengan benar, lalu menganalisis CPU, memori, dan disk I/O dengan top, vmstat, dan iostat. Kita bahas OOM killer yang menyerang diam-diam, pengelolaan swap sebagai "ruang nafas" RAM, dan menutup dengan studi kasus diagnosa CPU spike langkah demi langkah beserta kesalahan umum.

#Pembahasan Utama

#Pendekatan Troubleshooting: Temukan Bottleneck, Bukan Gejalanya

Prinsip pertama yang harus dipegang: ukur sebelum memperbaiki. Jangan pernah "memperbaiki" sesuatu yang belum terbukti sebagai penyebab. Metode sederhana yang bisa kalian ulangi setiap kali:

1. Ukur — kumpulkan data dari semua komponen (CPU, memori, disk, network) dalam periode waktu yang sama.
2. Identifikasi bottleneck — komponen mana yang paling mendekati batasnya (100% utilization atau antrian panjang)?
3. Hipotesis — sebutkan secara eksplisit apa yang kalian yakini sebagai penyebab.
4. Uji — lakukan satu perubahan, ukur ulang, dan bandingkan.
5. Dokumentasikan — catat apa yang dilakukan dan hasilnya, supaya bisa dipakai lagi di insiden berikutnya.

Ada metafora yang sangat tepat: antrean di kasir supermarket. Sistem yang sehat itu seperti toko dengan kasir yang cukup — antrean pendek, semua bergerak. Sistem yang overloaded itu seperti toko di hari libur dengan satu kasir: orang mengantre panjang, dan kasir bekerja sekuat tenaga (CPU 100%) tapi tetap tidak sanggup melayani. Pertanyaan yang harus kalian jawab bukan "kenapa orang mengantre?", melainkan "komponen mana yang menjadi kasir tunggal itu?" — itulah bottleneck.

#Load Average & CPU: Membaca uptime dengan Benar

Perintah pertama yang biasanya dijalankan adalah uptime, dan ini juga yang paling sering disalahbaca:

 09:41:02 up 12 days,  3:22,  1 user,  load average: 3.52, 2.90, 2.61

Tiga angka di akhir adalah load average untuk 1, 5, dan 15 menit terakhir. Angka ini mewakili jumlah proses yang sedang berjalan ditambah yang sedang menunggu giliran CPU (runnable + uninterruptible) — bukan persentase penggunaan CPU. Satu hal yang wajib dipahami: load average tidak bisa diinterpretasikan tanpa mengetahui jumlah core CPU.

Kesalahan paling umum di sini: melihat load average: 3.52 lalu panik menganggap CPU overloaded. Padahal jika server punya 8 core, load 3.52 berarti sistem baru memakai kurang dari setengah kapasitasnya. Aturan praktisnya: bagi load average dengan jumlah core. Di bawah 1.0 per core = masih sehat; di sekitar 1.0 per core = penuh tapi normal; jauh di atas 1.0 per core dan bertahan = antrean menumpuk, CPU menjadi bottleneck.

nproc
uptime

Perhatikan juga tren ketiga angka tersebut, bukan nilai tunggalnya. 1.5, 3.0, 4.5 berarti beban meningkat — masalah sedang memburuk. Sebaliknya 4.5, 3.0, 1.5 berarti beban sedang menurun — sistem mungkin sudah melewati puncaknya. Angka 15 menit adalah "cuplikan sejarah", bukan kondisi sekarang.

Untuk melihat proses mana yang memakan CPU, top adalah alat wajib:

top -o %CPU

Kolom %CPU menunjukkan persentase dari satu core. Proses yang menunjukkan 100 berarti menghabiskan satu core penuh; pada server dengan 4 core, 400 berarti memakai seluruh CPU. Dari sini kalian bisa melihat dengan cepat siapa "biang kerok"-nya — database query yang liar, worker aplikasi yang tidak terkontrol, atau script yang berjalan tak terkendali.

#Memori: RAM, Swap, dan OOM Killer

Setelah CPU, komponen kedua adalah memori. Perintah yang paling cepat adalah free -h:

              total        used        free      shared  buff/cache   available
Mem:           15Gi       7.1Gi       1.2Gi       456Mi       6.7Gi       7.3Gi
Swap:         2.0Gi       300Mi       1.7Gi

Dua angka yang harus diperhatikan: available (bukan free!) dan kolom Swap. Kolom free menyesatkan karena Linux memakai memori kosong untuk page cache — itu justru sehat. Kolom available memperkirakan memori yang benar-benar bisa dipakai aplikasi tanpa memicu swap. Jika available menipis (misal di bawah 10% dari total) sementara swap terpakai, sistem sedang kekurangan memori.

Ketika RAM habis, Linux melakukan dua hal. Pertama, menggunakan swap — memindahkan halaman memori yang jarang dipakai ke disk. Swap itu seperti ruang penyimpanan tambahan di gudang: jauh lebih lambat dari meja kerja (RAM), tapi mencegah sistem langsung roboh. Kedua, ketika swap pun habis, kernel memanggil OOM killer — penjaga yang "memilih" proses untuk dimatikan demi menyelamatkan sistem.

OOM killer adalah penyebab kegagalan yang paling sering membuat aplikasi hilang tanpa jejak: satu menit berjalan normal, menit berikutnya proses hilang, dan journalctl baru menceritakan kebenarannya:

sudo dmesg -T | grep -iE "out of memory|killed process"
journalctl -k -b | grep -i "oom"

Baris seperti Out of memory: Killed process 1234 (mysqld) adalah bukti tak terbantahkan: memori habis, dan kernel mengambil keputusan menyedihkan. Jika kalian melihat pola ini, jawabannya bukan menambah swap secara membabi buta, melainkan menemukan penyebab kebocoran memori atau menambah RAM — yang akan kita bahas di bagian swap.

#Disk I/O: iostat dan Kisah iowait

Komponen ketiga yang paling sering terlupakan adalah disk I/O. Server bisa memiliki CPU dan RAM yang melimpah, tapi tetap lambat jika disk menjadi kemacetan. Untuk melihatnya, gunakan iostat dari package sysstat:

iostat -xz 1

Interpretasi opsi di atas — -x untuk statistik extended, -z hanya menampilkan device yang aktif, dan 1 untuk interval 1 detik. Dua kolom yang paling penting:

• %util — persentase waktu device sibuk melayani permintaan. Di atas 60–70% secara konsisten menandakan disk sedang overloaded; mendekati 100% berarti antrean I/O menumpuk.
• await — rata-rata waktu (dalam milidetik) yang dibutuhkan sebuah permintaan untuk selesai. Angka kecil berarti cepat; angka yang membengkak berarti disk lambat atau antrean panjang.

Hubungan keduanya penting: jika %util tinggi dan await tinggi, disk benar-benar sibuk — solusinya bisa pemindahan workload atau upgrade disk. Tapi jika %util tinggi sementara await rendah, berarti banyak permintaan kecil dilayani dengan cepat — masalahnya mungkin terlalu banyak thread I/O, bukan disk yang lambat.

Kalian juga akan sering melihat istilah iowait pada output top atau uptime — persentase waktu CPU menunggu operasi I/O selesai. iowait yang tinggi berarti CPU rela menganggur karena menunggu disk — dan ini petunjuk kuat bahwa disk adalah bottleneck, bukan CPU. Sering kali disk HDD tua di server "seolah sehat" padahal menjadi sumber kelambatan yang tak pernah disadari, karena semua metrik CPU tampak normal.

#Network: Komponen Keempat yang Jangan Dilupakan

Ketika CPU, memori, dan disk semuanya tampak sehat tapi aplikasi tetap lambat, periksa network. Skenario yang umum: bandwidth LAN penuh karena backup atau sync data yang tidak terkendali, atau koneksi TCP yang menumpuk tanpa selesai (timeout) sehingga kolam koneksi aplikasi habis.

Untuk memeriksa port yang terbuka dan status koneksi, ss adalah alat modern pengganti netstat:

ss -tunap

Jika kalian melihat ribuan koneksi SYN_SENT atau TIME_WAIT yang menggunung, itu indikasi masalah di sisi network — bukan di aplikasi. Untuk melihat throughput jaringan per interface, sar -n DEV (dari package sysstat yang sama dengan iostat) memberi ringkasan historis:

sar -n DEV

Prinsipnya tetap sama dengan komponen lain: cari komponen yang paling mendekati batasnya. Jaringan yang 100% utilized jelas menjadi bottleneck — sebelum menuduh aplikasi lambat, pastikan bandwidth tidak sedang "dimakan" proses lain.

#Manajemen Swap: Menambah Ruang Nafas tanpa Menambah RAM

Ketika RAM terbatas dan proses terus meminta memori, salah satu solusi jangka pendek yang sah adalah menambah swap. Swap memberi sistem ruang bernapas: proses yang jarang dipakai bisa "diparkir" di swap sehingga RAM kosong untuk proses yang aktif. Ingat, swap adalah penyelamat darurat, bukan pengganti RAM — tetapi menambahkan file swap bisa menyelamatkan server dari OOM dalam hitungan menit, tanpa menunggu penambahan hardware.

Langkah-langkahnya sederhana. Pertama, cek kondisi swap saat ini dengan swapon --show dan free -h:

swapon --show
free -h

Kedua, buat file swap berukuran 2 GiB, format sebagai area swap, lalu aktifkan:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Perhatikan chmod 600: file swap berisi data memori yang bisa saja sensitif, jadi jangan sampai bisa dibaca user lain. Setelah swapon, verifikasi dengan swapon --show — file swap muncul sebagai device aktif.

fallocate bekerja baik pada filesystem modern seperti ext4 dan XFS. Pada filesystem yang tidak mendukungnya (atau jika kalian ragu), gunakan dd sebagai alternatif:

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

Ketiga, agar swap tetap ada setelah reboot, tambahkan entri ke /etc/fstab:

/swapfile none swap sw 0 0

Terakhir, atur vm.swappiness — seberapa agresif kernel menggunakan swap. Nilai default di banyak distro adalah 60, yang artinya kernel mulai memindahkan halaman ke swap relatif cepat. Untuk server dengan RAM cukup, nilai 10 jauh lebih baik — kernel lebih sabar memakai RAM dulu sebelum menyentuh swap:

sysctl vm.swappiness
# Ubah sementara (hilang saat reboot)
sudo sysctl -w vm.swappiness=10
# Persisten: tulis ke /etc/sysctl.d/99-swap.conf
echo "vm.swappiness = 10" | sudo tee /etc/sysctl.d/99-swap.conf

Dua baris yang ditandai -- menunjukkan pendekatan yang hanya berlaku sementara — perubahan dengan sysctl -w akan hilang saat reboot. Dua baris yang ditandai ++ adalah cara yang benar: menulis ke /etc/sysctl.d/ membuat parameter persist. Pola file di /etc/sysctl.d/ ini sudah kita kenal dari episode 16 — file bernomor dieksekusi secara berurutan.

#Praktik: Diagnosa Skenario CPU Spike Langkah demi Langkah

Saatnya menggabungkan semua alat menjadi satu alur diagnosa. Ambil skenario: monitoring memberi alert, "CPU utilization 100% sejak 10 menit lalu, aplikasi merespons sangat lambat."

Langkah 1 — Ambil gambaran umum. Login dan langsung jalankan uptime serta nproc:

uptime
nproc

Anggaplah hasilnya load average: 15.20, 12.80, 9.10 di mesin 4 core. Bagi dengan core: 15.2 / 4 ≈ 3.8 per core — jauh di atas 1.0, dan angkanya naik dari 9.1 → 12.8 → 15.2. Kesimpulan awal: beban meningkat tajam dan CPU menjadi bottleneck. Hipotesis yang masuk akal: ada proses yang mengonsumsi CPU sangat banyak.

Langkah 2 — Temukan pelakunya. Jalankan top -o %CPU dan lihat lima baris teratas:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 mysql     20   0 2.402g 1.1g  100m S  380.0  7.3  182:32.91 mysqld
 1010 www-data  20   0  312m  34m   18m S    2.0  0.2    2:10.11 php-fpm
  899 www-data  20   0  312m  32m   18m S    1.0  0.2    1:55.77 php-fpm

mysqld dengan %CPU 380 pada mesin 4 core berarti database memakai hampir seluruh CPU. Waktu 182:32 yang besar menunjukkan ini bukan kondisi baru — mesin SQL menghabiskan CPU secara terus-menerus.

Langkah 3 — Cek apakah ini masalah memori atau I/O tersembunyi. Jalankan vmstat 1 selama beberapa detik:

vmstat 1 5

Jika kolom si/so aktif besar, sistem sedang thrashing memori — masalah utamanya sebenarnya RAM, bukan CPU. Jika tidak, lanjutkan ke langkah berikutnya.

Langkah 4 — Verifikasi dengan iostat. Cek apakah disk ikut terbebani (sering kali penyebab CPU database tinggi adalah query yang memaksa disk bekerja keras):

iostat -xz 1

Jika %util rendah dan await wajar, disk bukan penyebab. Kesimpulan mengerucut: database-nya sendiri yang memakan CPU.

Langkah 5 — Cari penyebab di sisi aplikasi. Login ke MySQL dan lihat proses yang berjalan:

SHOW FULL PROCESSLIST;

Hasilnya menunjukkan banyak query SELECT ... FROM orders WHERE ... dengan Time besar yang tidak ada indeks. Akar masalahnya teridentifikasi: query tanpa indeks yang membuat database memindai tabel penuh berulang kali. Solusinya di sisi database (menambahkan indeks, menambah cache query), bukan upgrade hardware.

Pola lima langkah ini — gambaran umum, temukan pelaku, cek memori, cek disk, lalu masuk ke aplikasi — adalah resep yang bisa kalian pakai berulang kali. Urutannya penting: dari yang paling cepat dan murah (uptime) menuju yang paling spesifik (query database), sehingga kalian tidak pernah membuang waktu di tempat yang salah.

#Kesalahan Umum (Common Pitfalls)

1. Salah membaca load average pada multicore. Anggap load 3 di mesin 2 core sama dengan load 3 di mesin 8 core. Ingat: selalu bagi dengan nproc. Ini kesalahan interpretasi paling mahal di dunia tuning.

2. Swap di disk yang lambat. Meletakkan swap di HDD tua atau disk yang sama dengan workload intensif membuat sistem "berdarah" pelan-pelan. Periksa dengan iostat — jika si/so aktif dan %util swap tinggi, pertimbangkan memindahkan swap atau menambah RAM.

3. Mengabaikan iowait. Melihat CPU "idle" di top (misal 80% idle) lalu menyimpulkan sistem sehat, padahal iowait 40% menandakan CPU menunggu disk. Idle bukan berarti sehat jika disk sedang menjadi kemacetan.

4. Menganggap OOM killer adalah bug aplikasi. Proses yang hilang tiba-tiba sering disalahkan pada aplikasi, padahal penyebabnya dmesg yang menyebut "Out of memory: Killed process". Selalu cek dmesg/journal sebelum menyalahkan kode.

5. Panic upgrade tanpa data. Menambah RAM atau CPU hanya berdasarkan firasat, bukan pengukuran. Ukur dulu komponen mana yang benar-benar bottleneck — paling sering jawabannya justru konfigurasi (query, cache, indeks) yang bisa diperbaiki gratis.

#Penutup

Pada episode 24 ini, kalian telah membangun pendekatan sistematis untuk menangani server yang lambat atau down. Kita mulai dari prinsip ukur sebelum memperbaiki dan identifikasi bottleneck, lalu membedah setiap komponen: load average yang harus selalu dibaca dengan jumlah core, memori dengan free -h dan kolom available, OOM killer yang bersembunyi di dmesg, disk I/O dengan iostat -xz 1 dan kisah %util/await/iowait, serta network dengan ss. Kita juga belajar mengelola swap dengan fallocate, mkswap, swapon, dan mengatur vm.swappiness, lalu menutup dengan studi kasus diagnosa CPU spike lima langkah.

Poin kunci yang perlu kalian bawa:

• Troubleshooting adalah proses diagnosis terstruktur, bukan tebak-tebakan: ukur, identifikasi bottleneck, hipotesis, uji, dokumentasikan.
• Load average harus selalu dibandingkan dengan jumlah core (nproc); tren tiga angka lebih penting dari satu nilai.
• Baca kolom available di free -h, bukan free — dan selalu cek dmesg untuk jejak OOM killer.
• iostat -xz 1 adalah jendela ke disk: %util tinggi + await tinggi = disk sibuk; iowait tinggi = CPU menunggu disk.
• Swap adalah penyelamat darurat, bukan pengganti RAM; letakkan di disk terpisah dan kendalikan dengan vm.swappiness.

Sekarang kalian tahu cara membuat server tetap hidup dan cepat. Di episode 25 selanjutnya, kita akan membalik fokus dari membuatnya berjalan ke menjaganya dari penyerang: Linux Hardening & Security Best Practices Production — prinsip memperkecil permukaan serangan, fail2ban untuk melindungi SSH, pengenalan SELinux dan AppArmor, audit keamanan dengan Lynis, serta checklist hardening untuk server Ubuntu baru. Pastikan tetap semangat!