Proses, Sinyal & Sumber Daya — Belajar Linux & Shell

Melihat Proses

ps aux                    # semua proses, format BSD
ps -ef                    # format System V
ps aux --sort=-%mem | head -10    # pemakan memori terbesar
ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head

pstree -p                 # pohon proses dengan PID
top                       # interaktif
htop                      # jauh lebih nyaman bila tersedia

Sinyal

Sinyal	Nomor	Arti	Bisa ditangkap?
`SIGTERM`	15	Tolong berhenti dengan rapi	Ya
`SIGKILL`	9	Mati sekarang juga	Tidak
`SIGINT`	2	Ctrl+C	Ya
`SIGHUP`	1	Terminal tertutup; sering dipakai untuk muat ulang konfigurasi	Ya
`SIGSTOP`	19	Bekukan proses	Tidak

kill 1234                 # SIGTERM (bawaan)
kill -9 1234              # SIGKILL — pilihan terakhir
kill -HUP $(pidof nginx)  # muat ulang konfigurasi nginx
pkill -f "python manage.py"
killall -u budi

🚫 kill -9 sebagai kebiasaan itu merusak

SIGKILL tidak bisa ditangkap program. Proses mati seketika tanpa sempat menutup berkas, menyelesaikan transaksi database, melepas kunci, atau menuliskan buffer ke disk. Akibatnya bisa berupa berkas rusak, kunci yang menggantung, atau data yang hilang separuh.

Selalu coba SIGTERM lebih dulu dan beri waktu beberapa detik. Gunakan -9 hanya bila proses benar-benar tidak merespons. Inilah juga alasan Kubernetes mengirim SIGTERM lalu menunggu grace period sebelum SIGKILL.

Membaca Load Average

uptime
# 10:15:32 up 42 days,  load average: 2.15, 1.87, 1.42
#                                     1mnt  5mnt  15mnt

nproc                     # jumlah inti CPU

💡 Load average bukan persentase CPU

Angkanya adalah rata-rata jumlah proses yang siap berjalan atau menunggu I/O. Bandingkan dengan jumlah inti:

Load 2.0 pada mesin 4 inti — santai.
Load 2.0 pada mesin 2 inti — tepat penuh.
Load 8.0 pada mesin 2 inti — ada antrean panjang.

Yang khas Linux: proses yang menunggu I/O disk ikut dihitung. Jadi load tinggi dengan CPU menganggur biasanya berarti disk yang menjadi hambatan, bukan prosesor.

Memori

free -h
#               total   used   free   shared  buff/cache   available
# Mem:           16Gi   4Gi    1Gi    200Mi        11Gi        11Gi

⚠️ Kolom "free" yang kecil itu normal

Linux memakai memori yang menganggur untuk cache disk, karena RAM kosong adalah RAM yang terbuang. Kolom yang benar-benar penting adalah available — itulah yang bisa dipakai aplikasi baru, karena cache akan dilepas otomatis bila dibutuhkan.

Panik karena "free tinggal 1 GB" padahal available 11 GB adalah kesalahan membaca yang sangat umum.

OOM Killer

# Memeriksa apakah proses dibunuh karena kehabisan memori
dmesg -T | grep -i "killed process"
journalctl -k | grep -i oom
grep -i oom /var/log/syslog

🚫 Ketika memori habis, kernel memilih korban

Linux mengizinkan alokasi memori melebihi yang tersedia (overcommit). Ketika benar-benar habis, kernel memilih satu proses untuk dibunuh berdasarkan skor — dan yang dipilih sering justru proses terbesar, yaitu basis data atau aplikasi utama Anda.

Gejalanya membingungkan: aplikasi "mati sendiri" tanpa error di lognya sendiri. Bukti kejadiannya hanya ada di log kernel. Di kontainer, ini muncul sebagai exit code 137.

Melihat I/O dan Jaringan per Proses

iostat -x 2               # statistik disk, perhatikan kolom %util dan await
iotop                     # proses mana yang menulis paling banyak
ss -tulpn                 # port yang didengarkan beserta prosesnya
lsof -i :8080             # siapa yang memakai port 8080
lsof -p 1234              # berkas apa saja yang dibuka proses ini

📌 ss -tulpn menjawab "port ini dipakai apa"

Error "address already in use" adalah salah satu yang paling sering ditemui. Perintah ini langsung memberi tahu proses mana yang sedang memegang port tersebut, lengkap dengan PID-nya. Perintah netstat yang lebih lama sudah digantikan ss di sebagian besar distribusi.