Temu duga Linux: Bagaimanakah anda mendiagnosis iowait yang tinggi?

Gesaan dan konteks

Sebuah hos Linux melaporkan %iowait meningkat daripada 3% kepada 38%, manakala kependaman p99 aplikasi meningkat dua kali ganda dan jumlah penggunaan CPU kekal pada 30%. Terangkan cara anda membezakan peranti blok tempatan, NFS atau storan jauh yang lain, penambakan memori (memory reclaim), curian hipervisor (hypervisor steal), dan ketidakpadanan antara pengukuran hos dan perkhidmatan.

Mulakan dengan maksud dan had iowait dalam /proc/stat. Kemudian bina bukti dengan vmstat, iostat, pidstat, PSI, keadaan tugas, metrik cgroup dan log kernel. Nombor-nombor ini ialah data latihan rekaan, bukan ambang amaran universal.

Perkara yang diuji oleh penemu duga

Batas perakaunan (Accounting boundary)

Calon perlu mengetahui bahawa iowait ialah medan perakaunan CPU, bukan penggunaan peranti atau jumlah masa yang dihabiskan oleh semua tugas untuk menunggu. Penjadualan berbilang teras menjadikan atribusi tidak sempurna.

Lapisan bukti

Jawapan yang kukuh beralih daripada purata hos kepada bukti per-CPU, bebenang (thread), cgroup, peranti dan kependaman ekor perniagaan (business tail latency), serta menerangkan perkara yang diubah oleh setiap pemerhatian.

Laluan menunggu (Wait paths)

Jawapan harus memisahkan I/O blok tempatan, NFS/FUSE, RPC pangkalan data, penambakan memori dan hypervisor steal. Setiap laluan mempunyai bukti dan mitigasi yang berbeza.

Penutupan yang selamat

Calon mengekalkan bukti, memilih mitigasi berisiko rendah yang terikat dengan hipotesis, dan mengesahkan pemulihan berbanding memulakan semula atau meningkatkan keserentakan (concurrency) secara lalai.

Soalan untuk dijelaskan terlebih dahulu

• Adakah iowait daripada hos atau kontena? /proc/stat hos dan metrik cgroup perkhidmatan mungkin meliputi populasi yang berbeza.
• Adakah setiap CPU tinggi, atau hanya satu? Purata menyembunyikan keafinan (affinity), NUMA, dan ketepuan setempat akibat kuota.
• Adakah permintaan sedang menunggu fail, peranti blok atau RPC rangkaian? Menunggu NFS, pangkalan data dan HTTP mempunyai bukti yang berbeza.
• Adakah isyarat p99 dan I/O berkongsi tetingkap masa yang sama persis? Selaraskan persampelan, penggunaan (deployment), sandaran dan perubahan trafik.
• Adakah swap, kegagalan utama (major faults), PSI memori, atau masa steal semakin meningkat?
• Bolehkah anda membaca timbunan bebenang (thread stacks) dan fail cgroup? Gunakan keistimewaan paling rendah (least privilege) semasa penyiasatan pengeluaran.

Jawapan 30 saat

"Tiga puluh lapan peratus iowait adalah petunjuk, bukan bukti kegagalan cakera. Saya akan menyelaraskan tetingkap hos, perkhidmatan dan p99, kemudian memeriksa mpstat setiap CPU, vmstat r/b, PSI CPU/IO/memori, kuota cgroup dan masa steal.

Jika giliran ganti peranti, kependaman, bacaan/tulisan proses dan ralat kernel tidak normal bersama-sama, saya akan menyiasat storan blok. Jika bebenang menunggu dalam laluan NFS atau sistem fail semasa peranti tempatan sihat, saya akan memeriksa lekapan (mounts), rangkaian dan pelayan. Jika PSI memori, swapping dan major faults meningkat, saya akan menyiasat set kerja; jika steal meningkat, saya akan menyiasat hipervisor. Saya akan mengesahkan kependaman ekor perniagaan, senarai menunggu, PSI dan sumber selepas mitigasi."

Jawapan mendalam langkah demi langkah

Langkah 1: Tentukan batas iowait

iowait /proc/stat ialah perakaunan masa CPU yang dikaitkan dengan menunggu penyelesaian I/O. Tugas lain boleh berjalan semasa satu tugas menunggu, dan perakaunan berbilang teras tidak selalunya dapat mengaitkan penantian dengan tepat. iowait yang rendah tidak menolak storan jauh atau penantian kernel; iowait yang tinggi tidak membuktikan kegagalan cakera.

Langkah 2: Semak data setiap CPU dan giliran ganti

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

r yang berterusan dengan CPU yang sibuk menyokong penggiliran CPU; b yang berterusan menunjukkan penantian yang tidak boleh diganggu (uninterruptible waits). Data setiap CPU, keafinan, kuota cgroup dan pendikit (throttling) boleh mendedahkan "30% keseluruhan, tepu secara setempat."

Langkah 3: Ukur masa pegun dengan PSI

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

PSI some mengukur masa apabila sekurang-kurangnya sesetengah kerja terhenti; full mengukur masa apabila semua kerja bukan melahu terhenti. avg10/60/300 menunjukkan trend. Baca fail tekanan cgroup sasaran untuk memisahkan tekanan perkhidmatan daripada hingar hos.

Langkah 4: Cari bebenang dan titik menunggu

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

Kumpulkan mengikut status R/D, arahan, cgroup dan wchan. Jika dibenarkan, periksa /proc/PID/stack untuk bebenang yang mewakili. wchan hanyalah lokasi tidur semasa; perlukan korelasi temporal, PSI dan kependaman perniagaan sebelum menganggapnya sebagai punca.

Langkah 5: Masuk ke subsistem yang berkaitan

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

Untuk peranti blok, periksa await, kedalaman giliran ganti, pemprosesan (throughput) dan ralat. Untuk NFS/FUSE, periksa lekapan, penghantaran semula (retransmits), rangkaian dan kesihatan pelayan. Untuk memori, hubung kaitkan PSI memori, swap dan major faults. Penantian RPC pangkalan data atau HTTP memerlukan pengesanan (tracing) dan metrik kolam (pool metrics); iostat tidak dapat melihatnya secara bersendirian.

Langkah 6: Mitigasi dan sahkan

Tangkap gambar bebenang, PSI, peranti dan log, kemudian hadkan kadar (rate-limit), jeda kerja kelompok, beralih ke replika yang sihat, atau baiki lekapan mengikut bukti. Jangan berulang kali kill -9 tugas keadaan D; tugas ini biasanya perlu meninggalkan penantian yang tidak boleh diganggu sebelum mengendalikan isyarat tersebut. Sahkan p99, ralat, kiraan R/D, PSI, kependaman sumber dan tunggakan (backlog) bersama-sama.

Jawapan model

"Tiga puluh lapan peratus iowait adalah petunjuk, bukan kesimpulan. Ia adalah perakaunan CPU yang dipengaruhi oleh penjadualan berbilang teras, jadi saya tidak akan menyebutnya sebagai kegagalan cakera serta-merta. Saya akan menyelaraskan skop dan tetingkap masa, kemudian memeriksa mpstat setiap CPU, vmstat r/b, PSI CPU/IO/memori, kuota cgroup dan masa steal.

Jika bebenang berkeadaan D dan PSI I/O meningkat, wchan menghala ke I/O blok, dan iostat menunjukkan kependaman dan giliran ganti yang lebih tinggi, saya akan memeriksa peranti, sistem fail dan ralat kernel. Jika peranti tempatan sihat tetapi bebenang berkumpul dalam penantian NFS, saya akan memeriksa lekapan, penghantaran semula, rangkaian dan pelayan. Jika PSI memori, swap atau major faults meningkat, saya akan mengawal set kerja; jika steal meningkat, saya akan menyiasat hipervisor.

Saya akan menjeda kerja kelompok yang menguatkan I/O, mengehadkan kadar, atau beralih kepada replika yang sihat sambil mengekalkan bukti. Pemulihan bermaksud p99 dan ralat perniagaan, penunggu R/D, PSI, kependaman sumber dan tunggakan kembali ke arah garis dasar, bukan sekadar penurunan iowait."

Kesilapan biasa

• Menganggap iowait sebagai penggunaan cakera; hubung kaitkan dengan iostat dan garis dasar peranti.
• Menambah CPU sebaik sahaja iowait meningkat; periksa data setiap CPU, keadaan R/D dan PSI terlebih dahulu.
• Menolak masalah I/O kerana iowait rendah; periksa keadaan D, storan jauh dan PSI I/O.
• Menganggap setiap keadaan D sebagai masalah cakera tempatan; NFS, sistem fail dan pemacu juga boleh menyekat.
• Hanya melihat metrik hos; cgroup perkhidmatan mungkin mempunyai had dan tekanan yang berbeza.
• Mengambil satu sampel sahaja; gunakan sampel berterusan bercop masa yang diselaraskan dengan keluk permintaan.
• Memulakan semula atau mematikan proses dengan serta-merta; kekalkan bukti dan nilai keselamatan data.
• Hanya menunggu iowait menurun; sahkan kependaman pengguna dan giliran ganti sumber.

Soalan susulan

Susulan 1: Mengapakah iowait boleh menjadi tinggi manakala penggunaan cakera (disk util) adalah rendah?

Penantian mungkin berada dalam NFS, FUSE, pangkalan data, atau RPC rangkaian, atau pemetaan peranti dan tetingkap masa mungkin berbeza. Ikuti titik menunggu bebenang, pengesanan, PSI I/O, lekapan dan isyarat rangkaian.

Susulan 2: Mengapakah iowait boleh menjadi rendah sedangkan permintaan tersekat?

Tugas mungkin menunggu kunci (locks), kolam (pools), kuota CPU, penambakan memori atau RPC jauh. Bandingkan keadaan R/D, timbunan, PSI CPU/memori dan kependaman kebergantungan; perakaunan CPU tidak mengklasifikasikan setiap penantian sebagai iowait.

Susulan 3: Bagaimanakah anda mengetahui sama ada kontena mempunyai tekanan I/O sendiri?

Baca io.pressure cgroup sasaran, statistik I/O dan peristiwa pendikit, kemudian bandingkannya dengan /proc/pressure/io hos dan p99 perkhidmatan. Tekanan hos yang tinggi dengan tekanan perkhidmatan yang rendah tidak bermakna penskalaan perkhidmatan akan membantu.

Susulan 4: Bolehkah anda mematikan (kill) bebenang berkeadaan D?

Anda boleh menghantar isyarat, tetapi isyarat itu biasanya tidak boleh dikendalikan sehingga penantian yang tidak boleh diganggu kembali. Tangkap timbunan dan titik menunggu, baiki peranti, lekapan atau pemacu, dan pertimbangkan pemulaan semula hanya selepas redundansi dan keselamatan data disahkan.

Susulan 5: Bagaimanakah anda menetapkan amaran pada iowait?

Elakkan peratusan universal. Gabungkan iowait dengan PSI I/O, kependaman storan tempatan atau jauh, kiraan keadaan D, SLO perniagaan dan tempoh, yang ditentukur mengikut garis dasar beban kerja.