Linux : Praktikum Diagnosa Server Lambat dengan htop, PSI, dan Netdata

Keluhan "server lambat" bukan satu penyakit. Di dalamnya ada empat tersangka yang gejalanya mirip tapi obatnya berbeda: CPU habis, memori tertekan, disk menunggu, dan satu proses rakus yang menyedot salah satunya. Artikel ini bukan pengulangan cara membaca htop, tapi latihan menutup kemungkinan satu per satu, dengan bukti yang bisa ditunjukkan ke orang lain.

Kalau kamu belum paham beda potret sesaat dan riwayat, baca dulu Linux : Monitoring Server Dasar (htop, netdata). Di sini kita langsung masuk ke meja kerja: menyuntik beban terkendali, mencatat angka, lalu menulis kesimpulan yang tidak bisa dibantah.

🎯 Tujuan

Setelah menyelesaikan lab ini, kamu bisa:

membedakan empat penyebab umum server lambat dari gejalanya, bukan dari tebakan;
menyuntik beban terkendali di VM latihan dan mengukur dampaknya dengan vmstat, free, PSI, dan pidstat;
membaca PSI dengan benar, termasuk tahu kenapa baris full di CPU selalu nol;
menunjuk proses penyebab dengan angka, bukan dengan perasaan;
mengisi lembar bukti lima baris yang bisa dipakai saat melapor ke guru atau atasan;
mengukur ulang setelah perbaikan dan membuktikan bahwa masalahnya benar-benar turun.

📍 Konteks nyata

Sebuah warnet dengan 24 PC mengeluh lag setiap malam sekitar pukul 20.00. Teknisi membuka htop: CPU 30 persen, memori masih lega. Kesimpulan cepat: "server sehat, pasti internetnya." Router diganti, kabel ditata ulang, lag tetap datang tiap malam.

🔥 Kasus nyata: setelah dipasang pencatat, ternyata pukul 20.00 sebuah skrip menjalankan mysqldump untuk data billing dan menulis berkas hampir 900 MB ke HDD lama. vmstat menunjukkan kolom wa di atas 50 persen, dan PSI io baris full naik sampai 30 persen — artinya hampir sepertiga waktu, semua tugas yang tidak menganggur sedang tertahan menunggu disk. CPU memang tidak salah: dia hanya bukan tersangkanya. Solusinya tiga baris: dump dijadwalkan pukul 02.00, dibungkus ionice -c3, dan diarahkan ke disk kedua.

Analogi yang enak dipakai: keluhan "lambat" itu seperti pasien datang dengan keluhan "badan tidak enak". Dokter yang baik tidak langsung memberi obat, tapi mengecek suhu, tekanan darah, dan hasil lab satu per satu. Lab ini melatih kebiasaan itu.

🧠 Konsep singkat

🔹 Empat tersangka, satu keluhan

Sebelum menyentuh perintah apa pun, tentukan dulu tersangka mana yang masuk akal. Tabel berikut adalah peta awal, bukan vonis.

Tersangka	Tanda khas	Alat pembukti
CPU habis	`us` tinggi, `id` mendekati nol, load di atas jumlah core	`vmstat`, PSI `cpu`
Memori tertekan	`si`/`so` bergerak, swap terpakai naik, PSI `memory` naik	`free -m`, PSI
Disk menunggu	`wa` tinggi, kolom `b` berisi, PSI `io` naik	`vmstat`, `iostat`
Proses rakus	satu PID menyedot CPU, RAM, atau tulis disk	`pidstat`, `/proc/PID/io`

Perhatikan bahwa tiga tersangka pertama bisa muncul bersamaan. Justru itu gunanya aturan satu variabel.

🔹 Bukti yang tidak bisa dibantah

Ada tiga tingkat bukti, dari paling lemah ke paling kuat:

Kesan — "tadi kayaknya lambat". Tidak bisa dipakai mengambil keputusan.
Angka sesaat — satu baris vmstat atau satu layar htop. Lebih baik, tapi masih bisa kebetulan.
Angka bersyarat — angka yang diambil sebelum, selama, dan sesudah beban yang kamu kontrol sendiri. Ini yang disebut bukti.

Lab ini selalu memakai tingkat ketiga. Kamu yang menyalakan beban, kamu yang mencatat, kamu yang mematikan. Jadi kalau ada yang bertanya "kok tahu?", jawabannya bukan "pokoknya", tapi "ini berkasnya".

🔹 Aturan satu variabel

Kalau dua hal diubah bersamaan, kamu tidak akan pernah tahu mana yang berpengaruh. Karena itu:

satu uji, satu beban, satu jenis sumber daya;
catat waktu mulai dan selesai setiap uji;
kembalikan kondisi ke baseline sebelum uji berikutnya;
kalau hasilnya aneh, ulangi uji itu — jangan langsung menambah uji baru.

⚠️ Hati-hati: menjalankan empat uji sekaligus terlihat hemat waktu, tapi hasilnya cuma satu kesimpulan: "ada yang berat". Itu bukan diagnosis.

📊 Angka penting: PSI menyimpan tiga jendela rata-rata (10, 60, dan 300 detik) plus total dalam mikrodetik. Jendela pendek menangkap lonjakan, jendela panjang menunjukkan apakah tekanan itu kronis. Kernel hanya menerima jendela pemicu antara 500 ms dan 10 detik.

🧩 Istilah penting

PSI (Pressure Stall Information) — angka dari kernel yang mengukur berapa lama tugas benar-benar tertahan karena sumber daya penuh.
Stall — kondisi tugas siap jalan tapi tidak dapat giliran, misalnya menunggu data dari disk.
some — persentase waktu saat minimal satu tugas tertahan.
full — persentase waktu saat semua tugas tidak menganggur tertahan sekaligus. Ini tanda thrashing.
Thrashing — kondisi saling tunggu yang membuat mesin sibuk tapi nyaris tidak menghasilkan apa pun.
iowait (wa) — waktu CPU menganggur karena menunggu I/O selesai.
Uninterruptable (status D) — proses yang tidak bisa diganggu, biasanya sedang menunggu disk.
Swap in/out (si/so) — laju memori dipindah dari disk ke RAM dan sebaliknya, dalam KiB per detik.
buff/cache — memori yang dipakai kernel untuk cache; bisa diambil kembali saat aplikasi butuh.
available — perkiraan memori yang bisa dipakai memulai aplikasi baru tanpa swap.
Runqueue — antrean proses yang siap dijalankan; panjangnya mendekati arti load average.
Steal (st) — waktu CPU yang "dicuri" hypervisor; penting di VM yang CPU-nya berbagi.

🔧 Praktik: laboratorium empat tersangka

Semua langkah dijalankan di VM latihan, bukan server produksi. Ambil snapshot dulu, dan pastikan kamu punya akses console kalau VM sampai tidak bisa di-SSH.

🔹 Langkah 0: siapkan lab dan alat ukur

Pasang dua paket yang dipakai sepanjang lab. Keduanya hanya alat ukur dan pembuat beban, bukan layanan permanen.

sudo apt-get update
sudo apt-get install -y stress-ng sysstat
stress-ng --version
pidstat -V

Cek juga apakah PSI tersedia di kernel kamu:

ls /proc/pressure/
cat /proc/pressure/io

Kalau folder itu tidak ada, kernel lebih lama dari 4.20. Lab tetap bisa jalan dengan vmstat, hanya bagian PSI yang dilewati.

💡 Tips: di Ubuntu, pengumpulan sar otomatis kadang belum menyala setelah paket dipasang. Cek dengan systemctl list-timers --all lalu cari baris sysstat. Untuk lab ini sar tidak wajib, jadi jangan berhenti hanya karena timer belum aktif.

🔹 Langkah 1: potret baseline bertanda waktu

Baseline adalah kondisi "sehat" versi mesin kamu. Tanpa ini, semua angka nanti tidak punya pembanding.

mkdir -p ~/lab-lambat
{
  date -Is
  nproc
  free -m
  vmstat 1 3
  cat /proc/pressure/cpu
  cat /proc/pressure/memory
  cat /proc/pressure/io
} > ~/lab-lambat/baseline-$(date +%F-%H%M).txt
cat ~/lab-lambat/baseline-*.txt

Perhatikan baris pertama keluaran vmstat. Itu bukan sampel satu detik, tapi rata-rata sejak mesin menyala.

📊 Angka penting: manpage vmstat(8) menyebut laporan pertama berisi rata-rata sejak reboot, sedangkan laporan berikutnya memakai periode delay. Jadi kalau kamu mengambil kesimpulan dari baris pertama, kamu sedang membaca sejarah, bukan kondisi sekarang.

🔹 Langkah 2: Uji A, CPU habis

Nyalakan beban CPU sebanyak jumlah core selama dua menit. Di terminal kedua, ukur dampaknya.

stress-ng --cpu "$(nproc)" --timeout 120s --metrics-brief

uptime
vmstat 1 5
cat /proc/pressure/cpu

Yang harus kamu lihat:

load average naik mendekati jumlah core, lalu bertahan;
kolom us tinggi dan id mendekati nol;
PSI some avg10 naik jelas, sementara full tetap nol.

🧪 Uji cepat: baris full pada /proc/pressure/cpu selalu nol di level sistem. Dokumentasi kernel menyebut CPU full memang tidak terdefinisi, dan dilaporkan sejak 5.13 hanya demi kompatibilitas. Jadi jangan menunggu angka itu naik — untuk CPU, pakai some.

🔹 Langkah 3: Uji B, memori tertekan dan swap

Sekarang beban yang berbeda: dua pekerja menulis memori terus-menerus, masing-masing 60 persen RAM.

free -m
stress-ng --vm 2 --vm-bytes 60% --vm-keep --timeout 120s

Di terminal lain, lihat pergerakan swap dan tekanannya:

free -m
vmstat 1 5
cat /proc/pressure/memory

Yang perlu dibaca:

kolom available mengecil, bukan kolom free;
si dan so bergerak naik-turun;
PSI memory baris full mulai terisi — inilah tanda thrashing.

⚠️ Hati-hati: manpage stress-ng(1) memperingatkan bahwa stressor --vm bisa memicu OOM killer kalau memori fisik dan swap tidak cukup. Jangan pernah memakai --vm-bytes 100% di server yang masih melayani orang.

📊 Angka penting: bawaan --vm-bytes adalah 256 MB per pekerja, dan bawaan --hdd-bytes 1 GB per pekerja. Kalau tidak disebut, kamu bisa mengisi disk tanpa sadar.

🔹 Langkah 4: Uji C, disk menunggu

Beban tulis dengan sinkronisasi paksa. Ini meniru aplikasi yang menulis data penting dan menunggu disk benar-benar selesai.

dd if=/dev/zero of=/tmp/lab-io.bin bs=1M count=1024 oflag=dsync

Sambil perintah itu jalan, ukur dari terminal lain:

vmstat 1 5
iostat -x 1 3
cat /proc/pressure/io

Yang harus terlihat:

kolom b berisi proses yang tertahan menunggu I/O;
kolom wa naik, kadang di atas 30 persen;
%util di iostat mendekati 100 persen;
PSI io baris full ikut naik.

Inilah pola yang paling sering salah dibaca sebagai "CPU tidak masalah, berarti server sehat".

🔹 Langkah 5: menunjuk proses, bukan menuduh

Setelah tahu sumber dayanya, baru cari pelakunya. Jalankan uji beban lagi di satu terminal, lalu periksa dari terminal lain.

pidstat -d 1 3
pidstat -r 1 3
ps -eo pid,ppid,stat,pcpu,pmem,wchan:20,comm --sort=-pcpu | head -n 8

Tiga hal yang perlu kamu pahami:

pidstat -d menampilkan kB_rd/s dan kB_wr/s per proses, plus iodelay yang menghitung jeda menunggu I/O blok dan swap-in;
kolom stat berisi D menandakan proses tidak bisa diganggu, biasanya menunggu disk;
/proc/PID/io memberi angka kumulatif read_bytes dan write_bytes untuk proses tertentu.

cat /proc/$(pgrep -n stress-ng)/io

💡 Tips: kalau htop terasa terlalu ramai, tekan F4 dan tulis stress. Daftar langsung menyusut ke tersangka, dan kamu bisa membaca angka tanpa terganggu 200 baris lain.

🔹 Langkah 6: menulis lembar bukti

Sekarang ubah catatan menjadi satu tabel yang bisa dibaca orang lain. Ini bagian yang paling sering dilewatkan, padahal paling berguna saat melapor.

Waktu	Metrik dan nilai	Tersangka	Arti
20.02	`wa` 52 persen, `b` 3	Disk	Tiga proses tertahan menunggu disk
20.03	PSI io `full` 31 persen	Disk	Sepertiga waktu semua tugas tertahan
20.04	`pidstat -d`: mysqld 78 MB/dtk	Proses	Penulis terbesar adalah proses database
20.06	CPU `us` 12 persen	Bukan CPU	CPU justru banyak menganggur

Isi tabel dengan angka yang kamu lihat sendiri, bukan angka contoh di atas. Aturan mainnya satu: setiap baris harus punya waktu, angka, dan arti.

🔹 Langkah 7: menjawab "sejak kapan" di Netdata

Angka di lembar bukti menjawab "apa", bukan "sejak kapan". Buka dashboard Netdata lewat terowongan SSH, lalu bandingkan rentang waktu.

ssh -L 19999:localhost:19999 server@192.168.100.240

Lalu di browser, buka http://localhost:19999 dan periksa berurutan:

system.cpu — apakah lonjakan teratur atau acak;
system.ram — kapan available mulai menyusut;
disk.io — apakah tulis disk naik di jam yang sama;
system.io — apakah tekanan I/O mengikuti pola harian.

Cari titik perubahan, bukan nilai tertinggi. Kurva yang naik tepat pukul 20.00 setiap hari hampir pasti bukan kebetulan, melainkan jadwal.

⚠️ Hati-hati: jangan menyimpulkan dari satu grafik. Tekanan memori bisa menyebabkan tulis disk, sehingga grafik disk ikut naik padahal penyebabnya memori. Urutkan bukti sesuai waktu kejadian, bukan sesuai grafik yang paling dramatis.

🔹 Langkah 8: korelasikan dengan jadwal kerja

Sekarang cocokkan titik perubahan dengan hal-hal yang memang dijadwalkan mesin.

crontab -l
sudo ls -l /etc/cron.d/
systemctl list-timers --all
journalctl --since today --no-pager | grep -iE 'cron|timer|backup' | tail -n 20

Yang kamu cari bukan pesan error, tapi jam. Backup, rotasi log, pembaruan paket, dan laporan mingguan adalah empat kegiatan yang paling sering bertabrakan dengan jam sibuk.

🔥 Kasus nyata: di sebuah kantor distributor, aplikasi terasa lambat setiap Senin pagi selama sekitar 40 menit. PSI memory menunjukkan full tinggi, padahal RAM baru ditambah. Ternyata skrip backup mingguan memakai rsync --checksum atas 300 GB foto produk: seluruh isi disk dibaca ulang, cache terdorong keluar, dan aplikasi harus mengambil datanya lagi dari disk. Setelah jadwal digeser ke Minggu malam dan lajunya dibatasi, keluhan Senin hilang tanpa membeli perangkat apa pun.

🔹 Langkah 9: perbaiki satu hal, ukur ulang

Perbaikan tanpa pengukuran ulang hanya memindahkan harapan. Ubah satu hal, lalu ulangi uji yang sama persis.

stress-ng --hdd 2 --hdd-bytes 512m --timeout 60s --times

Bandingkan tiga hal sebelum dan sesudah perbaikan:

nilai wa pada uji yang sama;
PSI io baris full;
waktu yang dibutuhkan satu perintah nyata, misalnya membuka halaman aplikasi.

Kalau angkanya tidak berubah, jangan menambah perbaikan kedua. Kembali ke Langkah 6 dan periksa apakah tersangkanya memang benar.

🔹 Langkah 10: bersih-bersih dan pastikan lab mati

Tinggalkan mesin dalam keadaan seperti sebelum lab. Ini kebiasaan yang membedakan teknisi dari penguji yang berbahaya.

pgrep -a stress-ng
pgrep -a dd
rm -f /tmp/lab-io.bin
df -h /tmp
free -m
cat /proc/pressure/io

Pastikan tidak ada proses uji yang tertinggal. Manpage stress-ng(1) mengingatkan bahwa proses yang sedang menunggu I/O atau sedang membersihkan ratusan berkas bisa butuh waktu untuk benar-benar berhenti, meski batas waktu sudah lewat.

🏭 Dipakai di dunia kerja

Sekolah dan lab komputer: server ujian dipakai 60 siswa serentak; tanpa baseline, satu keluhan "lambat" bisa berakhir pembelian RAM yang tidak menyelesaikan apa pun.
Kantor dan UMKM: aplikasi kasir melambat saat backup jalan; menjadwalkan ulang lebih murah daripada menambah server.
Hosting dan VPS: pelanggan mengeluh lambat, padahal tetangga satu host sedang menyedot disk; angka st dan PSI membantu membedakan salah sendiri atau salah penyedia.
Industri dan manufaktur: mesin PLC mencatat data ke server; jeda tulis disk bisa berarti data produksi hilang, jadi tekanan I/O harus dipantau, bukan hanya CPU.
ISP dan NOC: tiket "jaringan lambat" sering berakhir di server monitoring yang disknya penuh karena retensi tidak dihitung.
Freelancer dan pekerja remote: satu VPS dipakai untuk banyak klien; bukti berupa grafik dan lembar catatan adalah cara menjelaskan kenaikan paket tanpa terkesan mengada-ada.

✅ Verifikasi

Jalankan tabel ini setelah lab selesai. Kalau satu baris tidak sesuai, perbaiki dulu sebelum lanjut.

Pemeriksaan	Perintah	Hasil yang diharapkan
Alat terpasang	`stress-ng --version`	Menampilkan versi, bukan "command not found"
Baseline ada	`ls ~/lab-lambat/`	Minimal satu berkas bertanda waktu
PSI terbaca	`cat /proc/pressure/io`	Ada baris `some` dan `full`
Uji CPU terukur	`vmstat 1 5` saat Uji A	`us` tinggi, `id` rendah
Swap terpantau	`free -m` saat Uji B	Kolom `available` menyusut
I/O terpantau	`iostat -x 1 3` saat Uji C	`%util` mendekati 100 persen
Proses tertunjuk	`pidstat -d 1 3`	Ada PID dengan tulis disk besar
Lembar bukti terisi	Buka berkas catatanmu	Semua baris punya waktu dan angka
Lab bersih	`pgrep -a stress-ng`	Tidak ada keluaran

⚠️ Kesalahan umum & troubleshooting

Gejala atau pesan	Arti	Tindakan
`stress-ng: command not found`	Paket belum terpasang	`sudo apt-get install -y stress-ng`
`Cannot allocate memory`	`--vm-bytes` terlalu besar	Turunkan persentase, kecilkan jumlah pekerja
VM tidak bisa di-SSH	OOM killer membunuh layanan penting	Pakai console, kurangi beban, tambah swap
Load tinggi tapi CPU `id` juga tinggi	Ada proses menunggu disk	Periksa `wa`, `b`, dan PSI io
`si`/`so` nol tapi swap terpakai	Swap lama, tidak sedang aktif dipakai	Jangan panik, lihat lajunya bukan totalnya
`free` kecil tapi mesin sehat	Itu cache, bukan memori hilang	Baca kolom `available`
PSI cpu `full` selalu nol	Memang tidak terdefinisi untuk CPU	Pakai `some` untuk CPU
`pidstat: command not found`	Paket `sysstat` belum ada	`sudo apt-get install -y sysstat`
Proses uji masih hidup setelah batas waktu	Sedang menunggu I/O atau membersihkan berkas	Tunggu, lalu periksa dengan `pgrep -a`
Angka berubah-ubah tiap pengukuran	Beban lain ikut berjalan	Ulangi uji, satu variabel saja

⚠️ Hati-hati: kalau stress-ng dijalankan sebagai root, manpage-nya menyebut setelan out-of-memory akan disesuaikan sehingga stressor sulit dimatikan saat memori kritis. Untuk lab, jalankan sebagai user biasa.

🔐 Catatan keamanan & etika

Uji hanya di mesin sendiri. Menjalankan beban buatan di server sekolah atau kantor tanpa izin bisa memadamkan layanan orang lain, dan itu bukan latihan lagi.
Snapshot sebelum eksperimen. Uji memori bisa memicu OOM killer yang membunuh layanan, bukan hanya proses uji.
Jangan uji saat jam sibuk. Bahkan di VM, host yang dipakai bersama akan terasa dampaknya.
Grafik monitoring adalah peta infrastruktur. Hostname, alamat IP, nama layanan, dan pola jam kerja terlihat di sana; jangan dibagikan ke grup publik.
Data metric bisa menjadi data pribadi. Nama pengguna dan aktivitas per jam bisa muncul di collector aplikasi; perlakukan seperti log.
Hasil uji bukan alat menakut-nakuti. Sampaikan temuan beserta buktinya, tanpa melebih-lebihkan agar anggaran cepat keluar.

📌 Kesimpulan

Server lambat bukan satu diagnosis, tapi empat kemungkinan yang harus ditutup satu per satu. Kuncinya bukan hafal perintah, tapi disiplin: satu variabel, angka sebelum dan sesudah, dan catatan yang bisa dibaca orang lain.

Langkah berikutnya: ambil satu keluhan nyata di lab sekolahmu, isi lembar bukti lima baris, lalu cocokkan dengan jadwal cron dan timer. Biasanya jawabannya sudah ada di sana sebelum kamu sempat menambah RAM.

🔗 Materi terkait

Linux : Monitoring Server Dasar (htop, netdata) — konsep rantai lima lapis monitoring, pasangan artikel ini.
Linux : Perintah htop — dasar tombol dan tampilan yang dipakai di lab ini.
Linux : Perintah vmstat — arti tiap kolom yang jadi alat bukti utama.
Linux : Perintah iostat — membaca %util dan waktu tunggu perangkat.
Linux : Log dan journalctl untuk Troubleshooting — mencari kejadian pada jam yang sama di log.
Linux : Backup Otomatis dengan rsync, tar, dan cron — sumber beban terjadwal yang paling sering jadi tersangka.
Linux : Membuat Service Sendiri dengan systemd — kalau beban bermasalah berasal dari layanan buatan sendiri.

📚 Referensi

vmstat(8), free(1), pidstat(1) — manpages.debian.org, Debian bookworm.
stress-ng(1) — manpages.debian.org, Debian bookworm.
Linux Kernel Documentation, Pressure Stall Information — docs.kernel.org/accounting/psi.html.
Netdata Documentation, Configure Health Alerts dan Web Server Reference — learn.netdata.cloud.