Buku Panduan SRE Linux: Penyelesaian Masalah CPU Tinggi Secara Sistematik

Senario

Dalam persekitaran pengeluaran, penggunaan CPU yang tinggi adalah isu biasa yang kritikal yang boleh menyebabkan kelewatan aplikasi dan kemerosotan perkhidmatan. Sebagai SRE, anda memerlukan pendekatan berstruktur untuk mendiagnosis dan mengurangkan puncak CPU tanpa menyebabkan gangguan lanjut. Buku panduan ini merangkumi langkah-langkah penting untuk menyelesaikan masalah CPU tinggi pada pelayan Linux.

Gejala

• Amaran pemantauan: Penggunaan CPU melebihi ambang (cth., >90% selama 5 minit).
• Aduan pengguna: Masa tindak balas aplikasi meningkat; pengguna mengalami tamat masa.
• Metrik sistem: Dalam top atau htop, %idle sangat rendah, purata beban melebihi bilangan teras CPU, dan senarai proses menunjukkan penggunaan CPU yang tinggi.

Diagnosis

1. Kenal pasti proses yang menggunakan CPU paling tinggi: Jalankan ps aux --sort=-%cpu | head -20 untuk menyenaraikan proses mengikut penggunaan CPU. Catat PID, %CPU, dan perintah.
2. Periksa pecahan CPU seluruh sistem: Gunakan mpstat -P ALL 1 3 untuk melihat penggunaan setiap teras dan kenal pasti jika satu teras digunakan sepenuhnya (cth., disebabkan oleh kernel atau pengendalian gangguan).
3. Bezakan masa pengguna vs kernel: vmstat 1 5 menunjukkan lajur us (pengguna) dan sy (sistem). sy tinggi menunjukkan aktiviti peringkat kernel (panggilan sistem, gangguan).
4. Periksa I/O menunggu: wa tinggi dalam vmstat atau iostat -x 1 menunjukkan CPU menunggu I/O. Ini boleh menyamar sebagai ketepuan CPU.
5. Lihat butiran peringkat benang: Untuk PID tertentu, top -H -p <PID> atau ps -Lp <PID> -o pid,tid,%cpu,comm mendedahkan benang yang menyebabkan masalah.
6. Jejak panggilan sistem (lanjutan): Gunakan strace -c -p <PID> untuk melihat kiraan panggilan sistem, tetapi hanya jika anda mempunyai kebenaran dan impak adalah minimum. Lebih baik gunakan perf top -p <PID> untuk pensampelan.

Perintah (dengan nota keselamatan)

# Selamat: senaraikan proses paling tinggi CPU tanpa mengubahsuai keadaan
ps aux --sort=-%cpu | head -20

# Pemantauan berkala selamat (kurang invasif)
top -b -d 5 -n 10

# Pecahan CPU setiap teras (selamat)
mpstat -P ALL 1 3

# Periksa letusan penciptaan proses (gunakan execsnoop dari perf-tools jika ada)
execsnoop -T

# Untuk mengurangkan kesan CPU proses tertentu (guna dengan berhati-hati):
# Rendahkan keutamaan:
renice +10 -p <PID>
# Nota: renice mungkin tidak memberi kesan ketara pada proses yang banyak menggunakan CPU jika ia intensif pengiraan.

# Bunuh proses hanya jika disahkan tidak kritikal dan selepas kelulusan:
# kill -9 <PID>   # Elakkan kecuali perlu sangat

# Jika anda mengesyaki gelung tak terhingga dalam Java/Python, hasilkan dump benang:
# kill -3 <PID>   # hantar SIGQUIT ke JVM

Kawalan Risiko

• Sahkan sebelum membunuh: Gunakan systemctl status <service> atau rujuk papan pemantauan untuk memahami peranan proses.
• Dokumen tindakan: Catat setiap perintah dan pemerhatian untuk analisis selepas kejadian.
• Elakkan strace/perf dalam pengeluaran melainkan pasukan mempunyai kelulusan jelas dan alat beban rendah (cth., perf record -F 99 -p <PID> -g -- sleep 10 selamat untuk jangka pendek).
• Sediakan amaran untuk CPU untuk menangani corak secara proaktif.

Pengembalian

• Jika anda membunuh proses kritikal, mulakan semula dengan segera: systemctl start <service>.
• Jika anda menukar nice kepada nilai, kembalikan kepada asal: renice 0 -p <PID>.
• Jika anda menggunakan perubahan konfigurasi sementara, kembalikan perubahan tersebut.

Pengesahan

• Selepas mitigasi, pantau penggunaan CPU selama 5-10 minit menggunakan top atau alat pilihan.
• Periksa titik akhir kesihatan aplikasi (cth., /healthz).
• Pastikan purata beban turun di bawah bilangan teras CPU.
• Sahkan metrik lain (memori, I/O cakera) tidak terjejas.

Bila Perlu Serahkan Tiket OpsGlobal

• Jika CPU masih tinggi selepas mitigasi asas (renice, mulakan semula).
• Jika punca tidak jelas (cth., pepijat kernel, ribut gangguan perkakasan).
• Jika isu memerlukan profil kod atau perubahan pada logik aplikasi.
• Jika anda memerlukan SRE dengan pengetahuan kernel Linux yang lebih mendalam atau sokongan vendor.

OpsGlobal menyediakan bantuan SRE jauh 24/7 untuk mendiagnosis dan menyelesaikan isu pengeluaran kompleks, membantu pasukan anda mengekalkan ketersediaan tinggi.