Temuduga Linux: Mengapakah Load Average Tinggi Apabila Penggunaan CPU Rendah, dan Bagaimanakah Anda Mendiagnosisnya?

Gesaan dan Peranan yang Sesuai

Pelayan Linux dengan 16 CPU logikal telah menjadi perlahan. uptime melaporkan purata beban 48 / 36 / 18, manakala mpstat masih melaporkan 72% agregat CPU idle. Tentukan sama ada ini membuktikan lebihan beban CPU dan terangkan cara mengenal pasti sumber yang sebenarnya sedang ditunggu oleh tugasan.

Jawapan mestilah menerangkan tugasan boleh laksana (runnable) dan tidak boleh diganggu (uninterruptible) dalam perakaunan beban Linux, mentafsir nilai 1, 5, dan 15 minit dengan betul, dan kemudian menggunakan keadaan tugasan, Pressure Stall Information (PSI), serta metrik subsistem untuk membezakan kes-kes ini:

• baris gilir larian (run queue) CPU benar-benar sesak;
• storan tempatan, sistem fail rangkaian, pemacu (driver), atau penantian kernel lain mengekalkan tugasan dalam keadaan D;
• penambatan semula memori (memory reclaim) atau swapping mencipta penantian tidak langsung;
• metrik peringkat hos dan metrik peringkat kontena atau perkhidmatan merangkumi skop yang berbeza.

Soalan ini sesuai untuk temuduga SRE, DevOps, infrastruktur, sistem, dan bahagian belakang (backend). Nilai 16, 48, 36, 18, dan 72% ialah input latihan rekaan, bukan ambang amaran universal. Senario ini mengandaikan bahawa metrik datang daripada hos dan tetingkap masa yang sama. Jika pengumpul atau cgroup yang berbeza menghasilkannya, selaraskan skop sebelum mentafsirkannya.

Perkara yang Diuji oleh Penemuduga

Pertama, calon mesti tahu bahawa purata beban (load average) bukanlah penggunaan CPU (CPU utilization). Beban global Linux ialah purata susut secara eksponen (exponentially decaying average) bagi tugasan boleh laksana ditambah tugasan dalam tidur tidak boleh diganggu (uninterruptible sleep). Hanya kumpulan pertama yang menyatakan permintaan CPU secara langsung; kumpulan kedua boleh meningkatkan beban sementara CPU kekal melahu (idle).

Kedua, ketiga-tiga nombor tersebut memerlukan tafsiran yang tepat. Ia bukanlah purata aritmetik mudah bagi sampel dalam 1, 5, dan 15 minit yang lalu. Ia adalah nilai yang susut secara eksponen dengan pemalar masa tersebut. 48 > 36 > 18 menyokong kesimpulan berarah bahawa beban telah meningkat baru-baru ini, tetapi ia tidak dapat membina semula panjang baris gilir yang tepat pada minit yang lalu atau membuktikan punca punca masalah.

Ketiga, diagnosis yang kukuh beralih daripada jumlah keseluruhan kepada komposisinya dan tapak penantian. Ia membandingkan medan vmstat iaitu r dan b, mengira bebenang dalam R dan D, dan kemudian menggunakan wchan, tindanan kernel (kernel stacks), PSI, serta metrik storan atau sistem fail rangkaian untuk mengenal pasti sumber. Sekadar menyenaraikan top dan iostat tidak menerangkan bagaimana bukti mengubah kesimpulan.

Keempat, calon harus mengendalikan contoh sebaliknya (counterexamples). Alat sering melabelkan D sebagai tidur cakera (disk sleep), tetapi penantian tidak boleh diganggu tidak terhad kepada cakera tempatan. NFS, sistem fail, pemacu peranti, dan beberapa penantian sumber kernel juga boleh muncul. %iowait ialah perakaunan masa CPU, jadi iowait yang rendah tidak menolak kemungkinan tugasan disekat (blocked tasks).

Akhir sekali, respons memerlukan mitigasi yang selamat dan gelung pengesahan. Menambah CPU, memulakan semula (restarting), mematikan proses, atau menaik taraf storan hanya sesuai untuk bukti tertentu. Selepas pembaikan, bilangan tugasan R/D, PSI, kependaman subsistem, dan kependaman ekor (tail latency) perniagaan harus pulih bersama-sama. Menunggu nilai purata beban menyusut sahaja adalah tidak mencukupi.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah metrik merangkumi skop yang sama? Purata beban biasanya adalah untuk seluruh hos, manakala CPU aplikasi mungkin menerangkan hanya satu kontena atau proses. Bandingkan metrik hos, cgroup, dan perkhidmatan terlebih dahulu; jika tidak, "beban tinggi, CPU rendah" mungkin merupakan ketidaksepadanan skop.
• Adakah CPU idle nilai agregat atau nilai per-CPU? Satu CPU, nod NUMA, atau beban kerja yang dikekang oleh afiniti mungkin beratur sementara CPU yang lain melahu. Periksa mpstat -P ALL, afiniti, dan kuota CPU cgroup.
• Permintaan manakah yang menjadi perlahan, dan bila? Selaraskan simptom dengan penggunaan (deployments), trafik, sandaran (backups), kependaman storan, perubahan lekap (mount changes), dan penambatan semula memori supaya isyarat hos boleh dikaitkan dengan impak pengguna.
• Adakah tugasan R atau D yang mendominasi? Banyak tugasan R dengan CPU yang sibuk menyokong persaingan CPU. Banyak tugasan D dengan CPU yang melahu menyokong penantian tidak boleh diganggu. Kedua-duanya boleh wujud bersama, jadi kelompokkan mengikut bebenang dan beban kerja.
• Laluan storan apakah yang terlibat? NVMe tempatan, storan blok awan, FUSE, NFS, dan pangkalan data jarak jauh memerlukan bukti yang berbeza. iostat tidak dapat melihat RPC rangkaian biasa, dan NFS memerlukan metrik pelekap dan sistem fail rangkaian.
• Adakah terdapat tekanan memori atau virtualisasi? Swap-in/out, penambatan langsung (direct reclaim), ralat utama (major faults), masa curi hipervisor (hypervisor steal time), dan had cgroup mengubah susunan penyiasatan.
• Bolehkah tindanan tugasan dibaca dengan selamat? /proc/12345/stack, beberapa nilai wchan, dan data I/O proses mungkin memerlukan kebenaran tambahan. Mulakan dengan persampelan overhed rendah dan gunakan hanya keistimewaan pengeluaran minimum yang diperlukan.

Rangka Kerja Jawapan 30 Saat

"Purata beban bukanlah peratusan CPU. Linux mengira tugasan boleh laksana dan tugasan dalam tidur tidak boleh diganggu, kemudian mengira purata susut secara eksponen dengan pemalar masa 1, 5, dan 15 minit. Beban 48 pada 16 CPU logikal bermakna banyak tugasan sedang aktif atau menunggu tanpa boleh diganggu. Dengan 72% CPU idle, saya tidak boleh menyimpulkan bahawa CPU tepu.

Saya akan menyelaraskan skop metrik terlebih dahulu dan memeriksa penggunaan per-CPU. Kemudian saya akan menggunakan vmstat untuk membandingkan tugasan boleh laksana dalam r dengan tugasan yang disekat dalam b, dan mengira bebenang dalam R dan D. Banyak tugasan R, PSI CPU yang tinggi, dan CPU yang sibuk menunjukkan baris gilir CPU. Banyak tugasan D dengan PSI I/O yang tinggi membawa saya ke wchan, tindanan tugasan, pidstat, iostat, metrik NFS, dan log kernel. Jika PSI memori, pertukaran (swapping), dan ralat utama meningkat bersama-sama, saya menyiasat tekanan memori. Selepas pembaikan, saya mengesahkan p99 perniagaan, bilangan R/D, PSI, dan kependaman subsistem dan bukannya hanya menunggu angka beban menurun."

Panduan Terperinci Langkah Demi Langkah

Langkah 1: Pisahkan Purata Beban kepada Dua Sumbernya

Input teras kepada perakaunan beban global Linux boleh diringkaskan sebagai:

nr_running + nr_uninterruptible

nr_running merangkumi tugasan yang sedang dilaksanakan pada CPU dan tugasan yang boleh dilaksanakan tetapi sedang menunggu untuk dijadualkan. nr_uninterruptible mewakili tugasan dalam tidur tidak boleh diganggu. Tiga medan pertama /proc/loadavg ialah nilai beban 1, 5, dan 15 minit untuk populasi tugasan aktif ini. Medan keempat kelihatan seperti 7/1280: nombor pertama ialah entiti penjadualan yang boleh dilaksanakan pada masa ini, dan nombor kedua ialah semua entiti penjadualan yang ada pada masa ini. Medan kelima ialah PID yang paling baru dicipta.

Oleh itu, "beban 48" tidak bermaksud "penggunaan CPU 300%," dan ia tidak bermaksud tepat 48 proses sedang beratur pada saat ini. Ia adalah isyarat bilangan tugasan yang telah diratakan (smoothed). Membahagikan beban dengan bilangan CPU logikal hanyalah petunjuk ketepuan kasar untuk beban kerja yang terikat dengan CPU. Sebaik sahaja tugasan keadaan D menyumbang secara ketara, nisbah itu tidak lagi menggambarkan baris gilir CPU.

Kernel mengemas kini purata susut secara eksponen pada selang masa yang tetap. Sampel baharu mempunyai berat yang lebih, manakala sampel yang lebih lama menyusut. Justeru 48 / 36 / 18 menunjukkan lebih banyak tugasan aktif baru-baru ini berbanding sebelumnya. Nilai 15 minit boleh kekal tinggi selepas punca hilang, jadi keputusan pemulihan harus mengutamakan keadaan tugasan semasa, PSI, dan metrik yang dihadapi pengguna.

Langkah 2: Selaraskan Skop, Penggunaan Per-CPU, dan Baris Gilir Semasa

Mulakan dengan pemerhatian bercop masa dan beroverhed rendah:

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

Laporan vmstat pertama secara amnya merupakan purata sejak but, jadi gunakan sampel terkemudian untuk insiden semasa. Medan penting termasuk:

• r: tugasan boleh laksana; nilai berterusan yang jauh melebihi CPU yang tersedia bersama-sama dengan CPU yang sibuk menyokong kesesakan baris gilir CPU;
• b: tugasan dalam tidur tidak boleh diganggu; peningkatan berterusan menghalakan penyiasatan ke arah sumber yang ditunggu;
• us, sy, id, wa, dan st: masa pengguna, sistem, melahu, menunggu I/O, dan masa curi hipervisor;
• si dan so: aktiviti swap-in dan swap-out, untuk ditafsirkan bersama PSI memori dan ralat halaman.

Tujuh puluh dua peratus agregat idle masih boleh menyembunyikan CPU yang panas (hot CPU). Beban bebenang bersiri yang dipinkan pada CPU 3 boleh menjenuhkan CPU tersebut sementara 15 yang lain kebanyakannya melahu. Penggunaan per-CPU, afiniti tugasan, kuota CPU kontena, dan pendikit (throttling) membezakan perkara ini daripada keperluan untuk lebih banyak CPU merentas seluruh hos.

Langkah 3: Kira R dan D Mengikut Bebenang dan Cari Tapak Penantian

Pelbagai bebenang dalam satu proses menyumbang kepada beban, jadi gunakan paparan peringkat bebenang:

ps -eLo state,pid,tid,ppid,wchan:32,comm --sort=state
ps -eLo state= | sort | uniq -c

R bermaksud berjalan (running) atau boleh laksana (runnable). D bermaksud tidur tidak boleh diganggu (uninterruptible sleep). Isyarat biasanya tidak boleh berkuat kuasa sehingga tugasan meninggalkan penantian itu, jadi mengeluarkan kill -9 berulang kali tidak melepaskan sumber kernel dengan segera mahupun memelihara bukti yang berguna.

Untuk kelompok bebenang berkeadaan D, kumpulkan mengikut perintah, proses induk, cgroup, dan wchan. wchan menunjukkan tempat bebenang sedang tidur dalam kernel dan boleh mempersempit carian kepada I/O blok, NFS, sistem fail, atau laluan pemacu. Apabila kebenaran membenarkan, periksa tindanan kernel tugasan wakil:

cat /proc/12345/stack
cat /proc/12345/wchan

Satu nama fungsi bukan punca punca. Banyak tugasan yang berkelompok di tapak penantian yang sama, diselaraskan mengikut masa dengan kependaman subsistem dan impak pengguna, membentuk bukti yang lebih kukuh. Keadaan D juga tidak membuktikan bahawa aplikasi secara sengaja menjana I/O yang berlebihan. Peranti yang gagal, pelekap jarak jauh yang tidak dapat dicapai, atau laluan kernel yang tersekat boleh mengumpul banyak bebenang yang menunggu daripada kadar permintaan yang kecil.

Langkah 4: Gunakan PSI untuk Mengenal Pasti Sumber Mana yang Menghentikan Kemajuan

PSI mengukur masa yang hilang disebabkan oleh persaingan CPU, memori, atau I/O:

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

some ialah bahagian masa apabila sekurang-kurangnya beberapa tugasan terhenti (stalled) pada sesuatu sumber. full ialah bahagian apabila semua tugasan bukan melahu terhenti serentak. full CPU peringkat sistem dikekalkan sebagai sifar dan tidak boleh digunakan untuk membuat inferens ketepuan CPU. avg10, avg60, dan avg300 menerangkan trend 10, 60, dan 300 saat terkini; total ialah masa henti kumulatif dalam mikrosaat.

PSI dan purata beban menjawab soalan yang berbeza. Purata beban menerangkan bilangan tugasan yang aktif atau menunggu tanpa boleh diganggu. PSI menerangkan berapa banyak masa beban kerja tidak dapat membuat kemajuan. Menggabungkan kedua-duanya mengelakkan refleks untuk "menambah CPU kerana beban tinggi." Dengan cgroup v2, baca juga cpu.pressure, io.pressure, dan memory.pressure dalam cgroup sasaran untuk memisahkan tekanan perkhidmatan daripada hingaran hos.

Gunakan matriks ini untuk menyusun bukti:

Matriks ini ialah titik permulaan, bukan pengesan punca automatik. Tekanan CPU, memori, dan I/O boleh membentuk gelung maklum balas. Penambatan semula memori boleh mencetuskan bacaan fail, contohnya, yang kemudiannya boleh meletakkan bebenang ke dalam keadaan D.

Langkah 5: Masuki Subsistem yang Berkaitan daripada Memanggil Setiap Penantian sebagai "Cakera Perlahan"

Jika bukti menghala ke peranti blok, periksa daya pemprosesan (throughput), kependaman, baris gilir, dan ralat:

pidstat -d -p ALL 1 10
iostat -xz 1 10
dmesg -T | tail -200

pidstat membantu mengenal pasti proses yang mengeluarkan I/O, manakala iostat melaporkan aktiviti peranti dan sekatan. Tafsirkan setiap medan terhadap jenis peranti dan garis dasarnya (baseline). Nilai %util, contohnya, tidak mempunyai satu ambang ketepuan sejagat merentas seni bina storan. Tamat masa (timeouts), set semula (resets), ralat sistem fail, atau peranti yang tertanggal dalam log kernel adalah lebih dekat dengan punca kegagalan berbanding kedalaman baris gilir sahaja.

Jika wchan atau titik lekap menunjukkan NFS, FUSE, atau storan rangkaian, periksa keadaan lekap, nfsiostat, penghantaran semula klien, kependaman rangkaian, dan kesihatan pelayan. Penantian RPC HTTP atau pangkalan data biasa biasanya boleh diganggu dan mungkin tidak memasuki purata beban Linux, jadi jejak aplikasi, kolam sambungan, dan kependaman kebergantungan masih tergolong dalam garis masa yang sama.

Jika PSI memori, swapping, atau ralat utama meningkat, periksa peristiwa memori cgroup, set kerja tanpa nama dan fail, penambatan langsung, dan peranti swap. Storan yang lebih pantas boleh mengurangkan kos swapping tanpa membetulkan masalah set kerja yang melebihi bajet memori.

Langkah 6: Mitigasi daripada Bukti dan Sahkan Sebab-Akibat

Mitigasi harus sepadan dengan sumber penantian yang disahkan:

• persaingan baris gilir CPU: kurangkan kemasukan, rendahkan konkurensi atau keutamaan kelompok, alih keluar afiniti yang tidak betul, dan tambah CPU hanya berpandukan model kapasiti yang diukur;
• kegagalan storan atau NFS: hentikan penggandaan I/O, beralih ke replika atau laluan lekap yang sihat, dan baiki peranti, rangkaian, atau pelayan;
• tekanan memori: batasi set kerja dan konkurensi, hentikan beban kerja yang mengalami thrashing, dan tambah memori dalam sempadan kapasiti yang serasi;
• ketidaksepadanan skop: asingkan beban kerja yang bising atau betulkan kuota cgroup sebelum memutuskan sama ada perkhidmatan sasaran memerlukan penskalaan.

Memulakan semula sistem boleh membersihkan tugasan yang terkumpul, tetapi ia juga boleh memadamkan tindanan dan log yang berguna. Jika sumber asas kekal tidak tersedia, proses baharu akan disekat semula. Sebelum bertindak, kekalkan PID wakil, keadaan tugasan, wchan, PSI, dan syot kilat subsistem, serta nyatakan perubahan metrik yang dijangkakan.

Penerimaan harus merangkumi p95/p99 perniagaan dan kadar ralat yang pulih, bilangan R/D kembali ke garis dasar, pengurangan tekanan dalam sumber PSI yang berkaitan, metrik peranti/NFS/memori/CPU yang pulih, dan tunggakan yang disalirkan dengan selamat. Oleh kerana purata beban menyusut secara beransur-ansur, ia adalah salah satu isyarat pemulihan dan bukannya satu-satunya pintu penutupan insiden.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan memanggil ini sebagai lebihan beban CPU hanya kerana beban adalah 48 pada 16 CPU. Purata beban Linux meratakan bilangan tugasan yang sedang berjalan atau menunggu CPU ditambah tugasan dalam tidur tidak boleh diganggu. Dengan 72% CPU idle, beban mungkin mengandungi banyak penantian keadaan D, atau agregat tersebut mungkin menyembunyikan masalah per-CPU, kuota, atau skop metrik.

48 / 36 / 18 ialah purata susut secara eksponen. Secara arah, ia memberitahu bahawa tugasan aktif meningkat baru-baru ini. Ia bukan purata aritmetik merentasi tiga tetingkap bebas dan tidak mengenal pasti punca. Saya akan memastikan beban, CPU, dan kependaman perniagaan datang dari hos dan tetingkap masa yang sama terlebih dahulu, kemudian memeriksa mpstat -P ALL untuk mencari CPU yang panas atau masa curi.

Seterusnya saya akan membandingkan r dan b dengan vmstat 1. r yang tinggi berterusan, CPU yang sibuk, dan PSI CPU yang tinggi akan membawa kepada profil CPU, afiniti, dan pendikit cgroup. b yang tinggi dan banyak bebenang keadaan D semasa CPU kekal melahu akan mendorong saya mengelompokkan bebenang mengikut perintah dan wchan, memeriksa /proc/12345/stack untuk tugasan wakil, dan menyelaraskan hasilnya dengan PSI I/O.

Katakan banyak bebenang menunggu dalam laluan berkaitan NFS, PSI I/O meningkat, dan iostat peranti blok tempatan kekal normal. Saya akan menyiasat pelekap, penghantaran semula klien, kependaman rangkaian, dan pelayan NFS dan bukannya menaik taraf cakera awan tempatan. Mitigasi mungkin melibatkan menghentikan kerja kelompok yang berkaitan, mengalihkan bacaan ke replika yang sihat, atau mengalih keluar nod yang terjejas. Mematikan proses keadaan D berulang kali biasanya tidak akan berkuat kuasa serta-merta.

Selepas pembaikan, saya akan mengesahkan kependaman ekor dan ralat perniagaan, bilangan bebenang R/D, PSI hos dan cgroup, kependaman NFS, dan tunggakan kerja. Nilai beban 1, 5, dan 15 minit menyusut dari semasa ke semasa, jadi nilai 15 minit yang masih tinggi tidak sepatutnya mencetuskan lebih banyak perubahan berisiko apabila penantian semasa dan hasil pengguna sudah stabil."

Kesilapan Lazim

• Menganggap purata beban sebagai penggunaan CPU → ia mengira tugasan dan merangkumi tidur tidak boleh diganggu → pisahkan r daripada b dan R daripada D sebelum mendiagnosis persaingan CPU.
• Mengisytiharkan lebihan beban setiap kali beban melebihi kiraan CPU → peraturan itu hanyalah petunjuk kasar untuk permintaan yang terikat dengan CPU → gabungkan CPU sibuk, PSI CPU, dan baris gilir boleh laksana.
• Menganggap 1, 5, dan 15 sebagai purata tetingkap mudah → Linux menggunakan susutan eksponen dan mengekalkan sampel yang lebih lama → gunakan tiga nilai tersebut untuk arah aliran dan sahkan masa kini dengan metrik semasa.
• Mengaitkan setiap tugasan D dengan cakera tempatan → NFS, sistem fail, pemacu, dan penantian kernel lain boleh menjadi tidak boleh diganggu → jejaki wchan, tindanan, dan subsistem yang sepadan.
• Menolak I/O kerana iowait rendah → iowait ialah perakaunan masa CPU, bukan kiraan tugasan yang disekat → periksa tugasan D, PSI I/O, peranti, dan kependaman storan jarak jauh.
• Hanya melihat pada purata CPU hos → CPU yang panas, afiniti, kuota, atau cgroup lain boleh disembunyikan oleh purata → bandingkan metrik per-CPU, hos, dan cgroup sasaran.
• Mengeluarkan kill -9 berulang kali kepada tugasan yang tersekat → isyarat menunggu operasi tidak boleh diganggu selesai dan bukti mungkin hilang → pelihara bukti dan baiki sumber yang ditunggu.
• Memanggil satu nilai wchan sebagai punca utama → ia hanya mengenal pasti tapak tidur kernel semasa → perlukan pengelompokan, korelasi masa, dan bukti subsistem.
• Menunggu purata beban mencapai sifar sebelum mengisytiharkan pemulihan → penyusutan mengambil masa dan sistem yang sihat tidak memerlukan beban sifar → terima pemulihan daripada hasil pengguna, tugasan semasa, PSI, dan metrik sumber.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapakah %iowait juga boleh menjadi rendah apabila CPU idle tinggi?

%iowait ialah pecahan masa CPU yang melahu sementara sistem memperakaunkan I/O yang belum selesai. Ia adalah perakaunan masa CPU. Tugasan boleh disekat dalam NFS, pemacu, atau penantian kernel tidak boleh diganggu yang lain sementara CPU menjalankan kerja lain atau kekal melahu seperti biasa. Pengagregatan merentas banyak CPU juga boleh mencairkan simptom tempatan. Gunakan kiraan keadaan D, PSI I/O, wchan, dan kependaman subsistem; iowait yang rendah sahaja tidak boleh mengecualikan I/O atau penantian kernel.

Susulan 2: Adakah purata beban yang diperhatikan di dalam kontena mewakili kontena tersebut?

Jangan mengandaikan ia mewakilinya. Beban yang kelihatan dan skop /proc bergantung pada hos, ruang nama PID, masa jalan (runtime), dan pelaksanaan pemantauan, manakala CPU aplikasi mungkin diskopkan mengikut cgroup. Baca CPU hos dan cgroup sasaran, I/O, dan PSI memori serta peristiwa kuota, dan atribusikan bebenang kepada cgroup. Jika beban hos tinggi tetapi cgroup sasaran tidak mempunyai tekanan, menskalakan perkhidmatan tersebut mungkin tidak membantu.

Susulan 3: Dengan beban 48 dan 72% CPU idle, adakah semestinya terdapat banyak tugasan keadaan D?

Tidak. Metrik mungkin tidak disegerakkan, agregat idle mungkin menyembunyikan CPU yang panas, tugasan mungkin dikekang oleh afiniti atau kuota cgroup, atau beban mungkin baru sahaja turun manakala purata eksponen masih mengekalkan nilai puncak. Periksa kiraan boleh laksana semasa dalam /proc/loadavg, vmstat r/b, penggunaan per-CPU, kiraan bebenang R/D, dan cop masa pengumpulan untuk menentukan komposisinya.

Susulan 4: Mengapakah proses keadaan D kadangkala terselamat daripada kill -9?

Tidur tidak boleh diganggu membolehkan beberapa operasi kernel melepasi fasa kritikal tanpa gangguan isyarat biasa. SIGKILL boleh kekal tergantung (pending), tetapi tugasan secara umumnya mesti kembali daripada penantian dan mencapai laluan yang boleh keluar sebelum proses hilang. Membaiki penantian peranti, lekap, rangkaian, atau pemacu selalunya lebih penting daripada mengulangi isyarat tersebut. Pemulaan semula hos, jika perlu, mesti dinilai terhadap integriti data dan redundansi perkhidmatan.

Susulan 5: Bagaimanakah amaran purata beban harus dikonfigurasikan?

Jangan menyalin ambang tetap "beban lebih besar daripada kiraan CPU". Untuk perkhidmatan yang terikat dengan CPU, gabungkan beban, baris gilir boleh laksana, PSI CPU, penggunaan, dan pendikit cgroup. Untuk perkhidmatan berat I/O, gabungkan PSI I/O, keadaan D, kependaman peranti atau storan jarak jauh, dan SLO perniagaan. Tetapkan ambang daripada garis dasar normal, tempoh, masa penskalaan, dan impak pengguna, serta labelkan skop setiap metrik.