Beban disk: iostat dan iotop

Disk adalah penyebab paling umum dari “semuanya lambat tapi CPU menganggur”. Proses menunggu I/O, load average naik, tetapi htop menunjukkan CPU% hampir nol. Mari kita lihat bagaimana melihat ini dalam angka.

Apa yang Anda dapatkan

Disk pada node adalah NVMe, tetapi kecepatannya dibatasi oleh tier: tulis — 60 MB/s per core, tetapi tidak lebih rendah dari 60 dan tidak lebih tinggi dari 400 MB/s; baca dua kali kecepatan tulis. Di atas batas tersebut, burst tiga kali lebih tinggi diizinkan selama 30 detik — cukup untuk mengekstrak arsip atau membangun proyek, tetapi tidak untuk terus-menerus mengunggah satu terabyte.

Jika pengukuran Anda mencapai angka-angka ini secara persis, Anda telah mencapai batas — tidak ada yang rusak. Di luar itu, hanya naik tier yang membantu.

iostat: gambaran besar

apt install -y sysstat       # Debian, Ubuntu
dnf install -y sysstat       # AlmaLinux, CentOS Stream

iostat -xz 2

Perintah ini mencetak snapshot setiap dua detik. Output pertama adalah rata-rata sejak boot — lewati saja. Perhatikan baris vda atau sda:

• r/s, w/s — operasi baca dan tulis per detik.
• rkB/s, wkB/s — megabyte, bagi dengan 1024. Bandingkan dengan tabel di atas.
• await — rata-rata waktu tunggu per operasi dalam milidetik. Satu digit adalah normal; puluhan dan ratusan berarti ada antrean.
• %util — seberapa sibuk disk. Stabil di 90–100 % berarti Anda telah mencapai dinding.

vmstat 2 juga berguna: kolom wa (io wait) menunjukkan, sebagai persentase, berapa banyak waktu CPU yang hanya menunggu disk.

iotop: siapa sebenarnya yang menulis

apt install -y iotop && iotop -oPa

-o hanya menampilkan proses aktif, -P menampilkan proses bukan thread, -a menampilkan volume akumulatif sejak diluncurkan. Setelah mengamati selama satu menit Anda akan melihat pelaku sebenarnya: biasanya database, pengumpul log, atau backup.

Pemeriksaan sekali jalan tanpa UI interaktif:

iotop -boPan 3 | head -20

Apa yang harus dilakukan dengan temuan Anda

• Journal sedang menulis. Batasi ukurannya: journalctl --vacuum-size=200M dan SystemMaxUse=200M di /etc/systemd/journald.conf. Untuk lebih lanjut, lihat systemd journals.
• Database sedang menulis. Periksa apakah ada full table scan yang berjalan karena indeks yang hilang, dan apakah buffer diatur terlalu kecil, sehingga memaksa semuanya ke disk.
• Backup atau rsync selama jam kerja. Batasi kecepatannya: rsync --bwlimit=20M; untuk pengarsipan, gunakan ionice -c3 nice -n19 tar ... agar tugas tersebut mengalah.
• Swap. Jika disk sibuk dengan paging, masalahnya bukan disk melainkan memori — baca Memory and swap.

Kesalahan umum

Mengukur kecepatan dengan dd dan conv=fdatasync lalu menarik kesimpulan dari satu kali pengujian: detik-detik pertama berjalan pada burst dan memberikan hasil yang terlalu tinggi. Metodologi yang benar ada di Benchmarking disk and network speed.

Disk penuh juga terlihat seperti “semuanya lambat”: tidak ada ruang kosong, layanan tidak dapat menulis file sementara dan menggantung. Periksa df -h terlebih dahulu — hanya butuh satu detik.