Wawancara Linux: Bagaimana Anda mendiagnosis iowait yang tinggi?

Petunjuk dan konteks

Sebuah host Linux melaporkan %iowait naik dari 3% menjadi 38%, sementara latensi p99 aplikasi meningkat dua kali lipat dan utilisasi CPU total tetap 30%. Jelaskan bagaimana Anda membedakan local block device, NFS atau remote store lainnya, memory reclaim, hypervisor steal, dan ketidakcocokan antara pengukuran host dan layanan.

Mulailah dengan arti dan batasan iowait pada /proc/stat. Kemudian bangun bukti dengan vmstat, iostat, pidstat, PSI, task state, metrik cgroup, dan log kernel. Angka-angka tersebut adalah data latihan fiktif, bukan ambang batas peringatan universal.

Apa yang sedang diuji oleh pewawancara

Batas akuntansi (Accounting boundary)

Kandidat harus mengetahui bahwa iowait adalah bidang akuntansi CPU, bukan utilisasi perangkat atau total waktu yang dihabiskan semua tugas untuk menunggu. Penjadwalan multicore membuat atribusi menjadi tidak sempurna.

Lapisan bukti

Jawaban yang kuat bergerak dari rata-rata host ke bukti per-CPU, thread, cgroup, perangkat, dan latensi ekor bisnis (business tail latency), serta menjelaskan apa yang diubah oleh setiap observasi.

Jalur tunggu (Wait paths)

Jawaban harus memisahkan I/O blok lokal, NFS/FUSE, RPC database, memory reclaim, dan hypervisor steal. Setiap jalur memiliki bukti dan mitigasi yang berbeda.

Penutupan yang aman

Kandidat mempertahankan bukti, memilih mitigasi berisiko rendah yang terkait dengan hipotesis, dan memverifikasi pemulihan alih-alih me-restart atau meningkatkan konkurensi secara default.

Pertanyaan untuk diklarifikasi terlebih dahulu

• Apakah iowait berasal dari host atau kontainer? /proc/stat host dan metrik cgroup layanan mungkin mencakup populasi yang berbeda.
• Apakah setiap CPU tinggi, atau hanya satu? Nilai rata-rata menyembunyikan afinitas, NUMA, dan saturasi lokal akibat kuota.
• Apakah permintaan sedang menunggu file, block device, atau RPC jaringan? Waktu tunggu NFS, database, dan HTTP memiliki bukti yang berbeda.
• Apakah sinyal p99 dan I/O berbagi jendela waktu yang persis sama? Selaraskan sampling, deployment, backup, dan perubahan lalu lintas.
• Apakah swap, major fault, PSI memori, atau steal time meningkat?
• Bisakah Anda membaca thread stack dan file cgroup? Gunakan prinsip hak istimewa terendah (least privilege) selama investigasi produksi.

Jawaban 30 detik

"Tiga puluh delapan persen iowait adalah petunjuk, bukan bukti kegagalan disk. Saya akan menyelaraskan jendela waktu host, layanan, dan p99, lalu memeriksa mpstat per-CPU, vmstat r/b, PSI CPU/IO/memori, kuota cgroup, dan steal time.

Jika antrean perangkat, latensi, baca/tulis proses, dan error kernel abnormal secara bersamaan, saya akan menginvestigasi block storage. Jika thread menunggu di jalur NFS atau filesystem sementara perangkat lokal sehat, saya akan memeriksa mount, jaringan, dan server. Jika PSI memori, swapping, dan major fault meningkat, saya akan menginvestigasi working set; jika steal meningkat, saya akan menginvestigasi hypervisor. Saya akan memverifikasi tail latency bisnis, antrean tugas yang menunggu, PSI, dan sumber daya setelah mitigasi."

Jawaban mendalam langkah demi langkah

Langkah 1: Tentukan batas iowait

iowait /proc/stat adalah akuntansi waktu CPU yang terkait dengan menunggu penyelesaian I/O. Tugas lain dapat berjalan saat satu tugas menunggu, dan akuntansi multicore tidak selalu dapat mengatribusikan waktu tunggu secara tepat. iowait yang rendah tidak mengesampingkan penyimpanan jarak jauh atau tunggu di kernel; iowait yang tinggi tidak membuktikan kegagalan disk.

Langkah 2: Periksa data per-CPU dan antrean

mpstat -P ALL 1 10
vmstat 1 10
cat /proc/loadavg

r yang berkelanjutan dengan CPU yang sibuk mendukung adanya antrean CPU; b yang berkelanjutan menunjukkan uninterruptible wait. Data per-CPU, afinitas, kuota cgroup, dan throttling dapat mengungkap kondisi "30% secara keseluruhan, tetapi jenuh secara lokal."

Langkah 3: Ukur waktu macet dengan PSI

for r in cpu io memory; do echo "[$r]"; cat /proc/pressure/$r; done

PSI some mengukur waktu ketika setidaknya beberapa pekerjaan terhenti (stalled); full mengukur waktu ketika semua pekerjaan non-idle terhenti. avg10/60/300 menunjukkan tren. Baca file tekanan dari cgroup target untuk memisahkan tekanan layanan dari kebisingan host.

Langkah 4: Temukan thread dan titik tunggu

ps -eLo state,pid,tid,wchan:32,comm --sort=state
pidstat -d -p ALL 1 10

Kelompokkan berdasarkan status R/D, perintah, cgroup, dan wchan. Jika diizinkan, periksa /proc/PID/stack untuk thread yang representatif. wchan hanyalah lokasi tidur saat ini; memerlukan korelasi temporal, PSI, dan latensi bisnis sebelum menyimpulkannya sebagai penyebab.

Langkah 5: Masuk ke subsistem yang relevan

iostat -xz 1 10
dmesg -T | tail -200
cat /proc/meminfo | egrep 'Swap|Dirty|Major'

Untuk block device, periksa await, kedalaman antrean, throughput, dan error. Untuk NFS/FUSE, periksa mount, transmisi ulang (retransmits), jaringan, dan kesehatan server. Untuk memori, korelasikan PSI memori, swap, dan major fault. Waktu tunggu RPC database atau HTTP memerlukan tracing dan metrik pool; iostat tidak dapat melihatnya sendiri.

Langkah 6: Mitigasi dan verifikasi

Ambil snapshot thread, PSI, perangkat, dan log, lalu terapkan rate-limit, jeda pekerjaan batch, beralih ke replika yang sehat, atau perbaiki mount sesuai bukti. Jangan berulang kali melakukan kill -9 pada tugas berstatus D; mereka biasanya harus keluar dari uninterruptible wait sebelum menangani sinyal tersebut. Verifikasi p99, error, jumlah R/D, PSI, latensi sumber daya, dan backlog secara bersamaan.

Contoh jawaban model

"Tiga puluh delapan persen iowait adalah petunjuk, bukan kesimpulan. Ini adalah akuntansi CPU yang dipengaruhi oleh penjadwalan multicore, jadi saya tidak akan langsung menyebutnya sebagai kegagalan disk. Saya akan menyelaraskan cakupan dan jendela waktu, lalu memeriksa mpstat per-CPU, vmstat r/b, PSI CPU/IO/memori, kuota cgroup, dan steal time.

Jika thread berstatus D dan PSI I/O meningkat, wchan mengarah ke I/O blok, dan iostat menunjukkan latensi dan antrean yang lebih tinggi, saya akan memeriksa perangkat, filesystem, dan error kernel. Jika perangkat lokal sehat tetapi thread menumpuk di waktu tunggu NFS, saya akan memeriksa mount, transmisi ulang, jaringan, dan server. Jika PSI memori, swap, atau major fault meningkat, saya akan mengontrol working set; jika steal meningkat, saya akan menginvestigasi hypervisor.

Saya akan menjeda pekerjaan batch yang mengamplifikasi I/O, menerapkan rate-limit, atau beralih ke replika yang sehat sambil mempertahankan bukti. Pemulihan berarti p99 dan error bisnis, antrean tunggu R/D, PSI, latensi sumber daya, dan backlog kembali mendekati baseline, bukan sekadar iowait yang turun."

Kesalahan umum

• Memperlakukan iowait sebagai utilisasi disk; korelasikan dengan iostat dan baseline perangkat.
• Menambahkan CPU segera setelah iowait naik; periksa data per-CPU, status R/D, dan PSI terlebih dahulu.
• Mengesampingkan I/O karena iowait rendah; periksa status D, penyimpanan jarak jauh, dan PSI I/O.
• Menyebut setiap status D sebagai masalah disk lokal; NFS, filesystem, dan driver juga dapat memblokir.
• Hanya melihat metrik host; cgroup layanan mungkin memiliki batas dan tekanan yang berbeda.
• Mengambil satu sampel saja; gunakan sampel berkelanjutan dengan timestamp yang diselaraskan dengan kurva permintaan.
• Me-restart atau mematikan proses secara instan; pertahankan bukti dan nilai keamanan data.
• Hanya menunggu iowait turun; verifikasi latensi pengguna dan antrean sumber daya.

Pertanyaan lanjutan

Lanjutan 1: Mengapa iowait bisa tinggi sementara utilisasi disk rendah?

Tunggu mungkin terjadi di NFS, FUSE, database, atau RPC jaringan, atau pemetaan perangkat dan jendela waktu mungkin berbeda. Ikuti titik tunggu thread, tracing, PSI I/O, sinyal mount, dan jaringan.

Lanjutan 2: Mengapa iowait bisa rendah sementara permintaan macet?

Tugas mungkin menunggu lock, pool, kuota CPU, memory reclaim, atau RPC jarak jauh. Bandingkan status R/D, stack, PSI CPU/memori, dan latensi ketergantungan; akuntansi CPU tidak mengklasifikasikan setiap penantian sebagai iowait.

Lanjutan 3: Bagaimana Anda mengetahui apakah kontainer memiliki tekanan I/O sendiri?

Baca io.pressure cgroup target, statistik I/O, dan peristiwa throttling, lalu bandingkan dengan /proc/pressure/io host dan p99 layanan. Tekanan host yang tinggi dengan tekanan layanan yang rendah tidak berarti bahwa melakukan scaling pada layanan akan membantu.

Lanjutan 4: Bisakah Anda mematikan thread berstatus D?

Anda dapat mengirimkan sinyal, tetapi biasanya sinyal tersebut tidak dapat diproses sampai uninterruptible wait selesai. Ambil stack dan titik tunggu, perbaiki perangkat, mount, atau driver, dan pertimbangkan restart hanya setelah redundansi dan keamanan data dipastikan.

Lanjutan 5: Bagaimana Anda membuat peringatan (alert) untuk iowait?

Hindari penggunaan persentase universal. Gabungkan iowait dengan PSI I/O, latensi penyimpanan lokal atau jarak jauh, jumlah status D, SLO bisnis, dan durasi, yang dikalibrasi dengan baseline beban kerja.