Panduan Lengkap Linux Troubleshooting: 10 Perintah Esensial untuk SysAdmin Indonesia

Sejak pertama kali saya memegang tanggung jawab sebagai sysadmin di sebuah startup e-commerce lokal pada tahun 2018, saya langsung sadar: buku teks Linux tidak pernah cukup untuk menghadapi server production yang sedang bermasalah. Saya ingat betul malam Minggu itu — server tiba-tiba hanging, ssh lambat, dan semua anggota tim developer panik karena deploy gagal. Saya cuma punya terminal dan secangkir kopi hitam.

Dari pengalaman pahit itulah saya belajar bahwa Linux troubleshooting bukan sekadar hafal perintah, tapi memahami kapan dan bagaimana menggunakannya di situasi nyata. Artikel ini akan membahas 10 perintah esensial yang wajib dikuasai setiap sysadmin Indonesia, lengkap dengan contoh kasus yang pernah saya alami.

1. top dan htop — Mata-mata Real-time Resource Server

Ketika server mulai lelet, top adalah senjata pertama yang saya gunakan. Perintah ini menampilkan proses yang berjalan, penggunaan CPU, memory, dan load average secara real-time.

top -bn1 | head -20

Output yang saya dapat biasanya seperti ini:

top - 14:23:45 up 12 days,  3:21,  1 user,  load average: 4.50, 3.20, 2.10
Tasks: 245 total,   1 running, 244 sleeping,   0 stopped,   0 zombie
%Cpu(s): 85.2 us, 10.3 sy,  0.0 ni,  4.0 id,  0.5 wa,  0.0 hi,  0.0 si
MiB Mem :   7856.2 total,   1234.5 free,   4567.8 used,   2053.9 buff/cache
MiB Swap:   2048.0 total,    102.3 free,   1945.7 used.   2045.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 5678 www-data  20   0  456.7m 234.5m  12.3m R  45.6   3.0   12:34.56 php-fpm
 1234 mysql     20   0  1.2g 567.8m  45.6m S  30.2   7.2   45:12.34 mysqld

Kasus nyata: Suatu ketika load average mencapai 12.0 di server 4 core. Setelah saya jalankan top, langsung kelihatan bahwa php-fpm memakan CPU 200% (karena 2 proses). Saya langsung cek konfigurasi pm.max_children di www.conf dan ternyata terlalu besar. Setelah saya turunkan dari 50 ke 20, server kembali stabil dalam 2 menit.

Untuk pengalaman yang lebih visual, saya sarankan install htop:

sudo apt install htop   # Debian/Ubuntu
sudo yum install htop   # RHEL/CentOS

Tips: Gunakan top -u www-data untuk melihat proses user tertentu, atau top -p 1234,5678 untuk memonitor PID spesifik. Ini sangat membantu ketika Anda hanya ingin fokus pada proses aplikasi tertentu.

2. df dan du — Detektif Ruang Disk

"Pak, server error nih — storage full!" Wah, kalau sudah dapat chat begitu, df adalah perintah pertama yang saya ketik.

df -h

Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        98G   85G   13G  87% /
/dev/sdb1       500G  498G  2.0G  99% /data
tmpfs           3.9G  2.1G  1.8G  54% /run

Begitu tahu partisi mana yang penuh, saya gunakan du untuk mencari direktori paling boros:

du -sh /* 2>/dev/null | sort -rh | head -10

Atau lebih spesifik:

du -sh /data/* 2>/dev/null | sort -rh | head -10

Output yang sering saya temui:

200G	/data/logs
150G	/data/backups
 50G	/data/uploads
 30G	/data/database

Pengalaman personal: Tahun lalu saya menangani server aplikasi learning management system (LMS) untuk sebuah universitas di Jawa Timur. df -h menunjukkan /var/log sudah 100%. Saya jalankan du -sh /var/log/* | sort -rh dan ternyata file syslog membengkak sampai 80GB! Setelah saya grep isinya, ternyata ada service microservice yang looping error terus-menerus. Saya matikan service itu, logrotate saya konfigurasi ulang, dan masalah selesai dalam 10 menit.

Perintah tambahan: Cari file lebih dari 1GB dengan:

find / -type f -size +1G -exec ls -lh {} \; 2>/dev/null

3. netstat dan ss — Mengawasi Lalu Lintas Koneksi

Dulu saya selalu mengandalkan netstat, tapi sekarang ss lebih cepat dan direkomendasikan. Keduanya berguna untuk melihat port yang terbuka, koneksi aktif, dan mendeteksi hanging connections.

ss -tulpn

Output:

State   Recv-Q  Send-Q    Local Address:Port   Peer Address:Port  Process
LISTEN  0       128       0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=1234,fd=6))
LISTEN  0       128       0.0.0.0:3306        0.0.0.0:*          users:(("mysqld",pid=5678,fd=21))
LISTEN  0       128       127.0.0.1:6379      0.0.0.0:*          users:(("redis-server",pid=9012,fd=4))
ESTAB   0       0         10.0.0.5:42710      203.0.113.50:443   users:(("nginx",pid=1234,fd=24))

Studi kasus: Suatu hari aplikasi web terasa lambat. Saya jalankan ss -tan | grep :80 | wc -l dan ternyata ada 2.345 koneksi concurrent. Dari situ saya tahu nginx butuh tuning worker_connections. Saya naikkan dari 1024 ke 4096 di file /etc/nginx/nginx.conf, lalu systemctl reload nginx. Hasilnya? Response time turun dari 4 detik menjadi 1,2 detik.

Untuk melihat koneksi yang hanging atau TIME_WAIT dalam jumlah besar:

ss -tan | grep TIME_WAIT | wc -l

Jika jumlahnya di atas 10.000, Anda perlu memeriksa konfigurasi net.ipv4.tcp_fin_timeout dan net.ipv4.tcp_tw_reuse di /etc/sysctl.conf.

4. ps — Membaca Proses dengan Detail

Ketika proses aplikasi tiba-tiba mati atau zombie, ps adalah alat investigasi utama.

ps auxf

Output:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3 101432  6784 ?        Ss   Mar12   0:12 /sbin/init
root       456  0.0  0.1  28164  2136 ?        S    Mar12   0:00  \_ /usr/sbin/cron
mysql      789  0.0  7.2 1589744 567890 ?      Ssl  Mar12  45:12  \_ /usr/sbin/mysqld
www-data  1234  1.2  3.0 456789 234567 ?       S    14:10   0:15  \_ nginx: worker process

Saya sering menggunakan kombinasi ps aux dengan grep untuk mencari proses tertentu:

ps aux | grep php-fpm | grep -v grep

Tips advanced: Untuk melihat thread dalam suatu proses:

ps -T -p <PID>

Atau mencari proses yang menggunakan memory paling besar:

ps aux --sort=-%mem | head -15

Ini sangat berguna ketika aplikasi Java atau PHP Anda mengalami memory leak. Saya pernah mendapati satu proses java memakan 12GB RAM — lebih dari separuh memory server! Setelah saya kill dan restart dengan -Xmx yang benar, masalah selesai.

5. journalctl — Log Sistem yang Terstruktur

Di era systemd, journalctl adalah pengganti tail -f /var/log/syslog yang jauh lebih powerful.

journalctl -u nginx.service --since "1 hour ago" --no-pager

Output:

Mar 15 14:20:01 server01 nginx[1234]: [error] 5678#5678: *789 open() "/var/www/html/index.html" failed (13: Permission denied), client: 10.0.0.1
Mar 15 14:25:30 server01 nginx[1234]: [error] 5678#5678: *790 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.1

Pengalaman nyata: Suatu malam aplikasi POS sebuah restoran besar di Jakarta error 502 terus. Saya jalankan:

journalctl -u php8.1-fpm.service -f

Dari situ saya lihat error pm: children exhausted. Saya segera naikkan pm.max_children dari 10 menjadi 25 dan restart service. Aplikasi kembali normal dalam 30 detik. Bayangkan jika saya harus buka file log satu per satu — bisa 15 menit!

Perintah lanjutan: Filter berdasarkan prioritas error:

journalctl -p err -b

Atau lihat log kernel:

journalctl -k

Tips: Untuk memudahkan analisis, saya selalu mengatur journald.conf dengan SystemMaxUse=2G agar log tidak memenuhi disk. Setelah itu, restart service dengan systemctl restart systemd-journald.

6. strace — Melihat ke Dalam System Call

strace adalah alat debugging paling ampuh yang saya tahu. Ia menangkap system calls dan signals yang dibuat oleh proses.

strace -p 1234 -e trace=network -s 1024 -t

Output:

14:30:01 connect(5, {sa_family=AF_INET, sin_port=htons(3306), sin_addr=inet_addr("10.0.0.10")}, 16) = 0
14:30:01 sendto(5, "...query..."..., 100, 0, NULL, 0) = 100
14:30:05 recvfrom(5, 0x7fff..., 4096, 0, NULL, NULL) = -1 ETIMEDOUT (Connection timed out)

Kasus klasik: Aplikasi PHP lemot setelah migrasi database. Saya strace proses PHP:

strace -o /tmp/trace.log -p $(pgrep -x php-fpm | head -1) -s 4096 -t

Dari file /tmp/trace.log, saya lihat ada ratusan connect ke MySQL yang timeout setelah 5 detik. Ternyata IP database di .env salah — menunjuk ke server mati! Setelah diperbaiki, aplikasi kembali normal.

Catatan: Hati-hati menggunakan strace di production — ia bisa memperlambat proses hingga 10-100x. Saya biasanya hanya gunakan di staging atau jika benar-benar darurat.

7. lsof — Daftar File yang Sedang Dibuka

Pernah dapat error "too many open files"? Itu saatnya lsof beraksi.

lsof -p 1234 | wc -l

Atau lihat file descriptor yang terbuka oleh suatu proses:

lsof -p 1234

Output:

COMMAND   PID     USER   FD   TYPE             DEVICE SIZE/OFF       NODE NAME
nginx    1234 www-data  cwd    DIR                8,1     4096          2 /
nginx    1234 www-data  rtd    DIR                8,1     4096          2 /
nginx    1234 www-data  txt    REG                8,1   987654    1234567 /usr/sbin/nginx
nginx    1234 www-data  mem    REG                8,1    65432    2345678 /usr/lib/x86_64-linux-gnu/libc.so.6
nginx    1234 www-data    6u   IPv4         123456789      0t0        TCP *:80 (LISTEN)

Pengalaman: Suatu hari redis-server crash dengan error "Can't open: Too many open files". Saya cek limit sistem:

ulimit -n

Ternyata hanya 1024. Saya naikkan menjadi 65535 di /etc/security/limits.conf:

root soft nofile 65535
root hard nofile 65535
redis soft nofile 65535
redis hard nofile 65535

Restart Redis, dan voila, crash tidak pernah terjadi lagi.

Tips lanjutan: Cari file yang dihapus tapi masih terbuka (makan disk space):

lsof +L1 | head -10

8. vmstat — Statistik Memory Virtual

vmstat memberikan gambaran ringkas tentang memory, swap, I/O, dan CPU dalam satu layar.

vmstat 2 10

Output:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  1 1945723 123456 78901 234567 1234 5678  901  234  567 890 45 12 30 13  0
 5  2 1945723 119876 78905 234589 1345 5789  923  245  589 912 50 15 20 15  0

Kolom yang penting:

• r (run queue): Jika > jumlah core, menandakan CPU overload. Server 4 core dengan r > 8 artinya ada bottleneck.
• b (blocked): Proses yang menunggu I/O. Angka tinggi ( > 2 ) biasanya indikasi disk lambat.
• si/so (swap in/out): Jika tidak nol, RAM tidak cukup. Sebaiknya ditambah atau optimasi memory.
• wa (wait I/O): Persentase CPU yang menganggur sambil menunggu I/O. > 20% sudah perlu waspada.

Analisis saya: Di server database MySQL dengan 8 core, saya melihat wa konsisten 25-30% dan b selalu di atas 5. Saya sarankan upgrade dari HDD ke SSD. Setelah migrasi, wa turun menjadi 2% dan query yang tadinya 3 detik menjadi 200 ms saja.

9. iostat — Performa Disk secara Detail

Kalau vmstat memberi gambaran umum, iostat memberikan detail perangkat disk.

iostat -x 2 5

Output:

Device            r/s     w/s    rkB/s    wkB/s  await  svctm  %util
sda              45.2    89.3  1234.5  5678.9   12.3   4.5   45.6
sdb              12.1    34.5   456.7  1234.5   45.6   8.9   78.9

Parameter penting:

• %util: Persentase waktu disk sibuk. > 80% berarti disk menjadi bottleneck.
• await: Rata-rata waktu I/O request (ms). Untuk HDD, normal < 20ms; untuk SSD, ideal < 2ms.
• svctm: Waktu layanan rata-rata. Lebih kecil lebih baik.

Kasus di lapangan: Sebuah server file sharing di perusahaan logistik mengalami keluhan akses lambat setiap jam 10 pagi. Saya pasang iostat -x 1 60 dan melihat %util mencapai 100% pada perangkat /dev/sdb. Setelah investigasi, ternyata ada cron job backup yang berjalan jam 10 pagi dan memonopoli I/O. Saya pindahkan jadwal backup ke jam 2 pagi, dan keluhan selesai.

10. sar — Laporan Historis Sistem

Ini perintah favorit saya untuk post-mortem. sar menyimpan data historis sistem sehingga Anda bisa melihat apa yang terjadi semalam atau seminggu lalu.

sar -u -s 00:00:00 -e 23:59:59

Output:

Linux 5.10.0-0.bpo.3-amd64 (server01) 	03/14/2025 	_x86_64_	(4 CPU)

00:00:01     CPU     %user     %nice   %system   %iowait    %steal     %idle
00:10:01     all     12.34      0.00      5.67      2.10      0.00     80.10
00:20:01     all     55.67      0.00     23.45      8.90      0.00     12.34
00:30:01     all     10.12      0.00      4.56      1.23      0.00     84.56

Tepat di jam 00:20, CPU usage melonjak. Saya cek sar -p -s 00:20:01 untuk proses apa yang jalan. Ternyata cron job certbot renew yang berjalan setiap malam dan memakan CPU.

Penggunaan lain: Cek penggunaan memory historis:

sar -r -s 00:00:00 -e 23:59:59

Atau network traffic:

sar -n DEV 1 5

Tips: Pastikan sysstat sudah diinstall dan service berjalan:

sudo apt install sysstat
sudo systemctl enable sysstat
sudo systemctl start sysstat

Data historis disimpan di /var/log/sysstat/ — biasanya untuk 7 hari terakhir. Anda bisa mengubah masa retensi di /etc/sysstat/sysstat dengan parameter HISTORY=30.

Kesimpulan: Membangun Muscle Memory Troubleshooting

Sepuluh perintah di atas hanyalah permukaan. Yang membuat perbedaan antara sysadmin biasa dan sysadmin andal adalah kebiasaan menggunakannya dalam tekanan. Saya sendiri menghabiskan ratusan jam di terminal — termasuk malam Lebaran tahun 2022 ketika server pembayaran Qris tumbang dan saya harus journalctl + strace dalam 5 menit untuk menemukan bahwa koneksi ke API bank timeout karena MTU bermasalah.

Beberapa rekomendasi saya untuk Anda yang ingin serius di Linux administration:

1. Biasakan membaca man — Tidak ada yang lebih otoritatif dari manual resmi. Coba man strace atau man sar hari ini.
2. Dokumentasikan setiap troubleshooting — Saya selalu catat tanggal, gejala, perintah yang digunakan, dan solusi di jurnal pribadi. Ini sangat membantu ketika masalah serupa muncul lagi.
3. Latihan di lab — Gunakan VirtualBox atau Linux di cloud untuk simulasi. Matikan service, buat disk penuh, lalu coba selesaikan dengan perintah di atas.
4. Ikuti perkembangan tools baru — Alternatif modern seperti btm (bottom), duf (disk usage), bandwhich (network) bisa menjadi pelengkap. Tapi kuasai dulu yang klasik sebelum beralih.

Terakhir, optimasi server bukanlah proyek sekali jadi, melainkan siklus monitor → diagnose → fix → monitor lagi. Dengan 10 perintah di atas, Anda sudah punya fondasi yang kokoh. Selamat troubleshooting, dan jangan lupa backup sebelum bertindak!

Artikel ini pertama kali diterbitkan di Tool Kuy (toolkuy.com) untuk sysadmin Indonesia. Jika Anda punya pengalaman menarik atau pertanyaan, diskusikan di kolom komentar.