Buku Panduan SRE Linux: Menangani Beban Tinggi pada Pelayan Pengeluaran

Buku Panduan SRE Linux: Menangani Beban Tinggi pada Pelayan Pengeluaran

Senario

Jam 2 pagi dan pager anda berbunyi. Sebuah pelayan aplikasi kritikal menunjukkan purata beban 30 pada mesin 16 teras. Permintaan pelanggan mula tamat. Buku panduan ini adalah panduan anda untuk mendiagnosis dan menyelesaikan isu sedemikian secara sistematik tanpa melarikan insiden.

Gejala

• Purata beban secara konsisten melebihi bilangan teras CPU (semak dengan nproc).
• Sesi SSH terasa lembap; arahan mengambil masa beberapa saat untuk kembali.
• Latensi aplikasi melonjak, dan pemeriksaan kesihatan mula gagal.
• uptime menunjukkan purata 1, 5, dan 15 minit yang tinggi.

Langkah Diagnosis

1. Snapshot Pantas
   Jalankan uptime dan cat /proc/loadavg untuk mengesahkan beban. Juga catat bilangan teras CPU (nproc). Ini menetapkan garis asas.

2. Cari Proses Paling Panas
   Gunakan top -b -n 1 | head -30 untuk snapshot. Atau htop interaktif jika dipasang. Untuk senarai yang lebih jelas, gunakan: bash ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head Cari proses yang menggunakan CPU paling banyak. Jika tiada yang jelas, periksa I/O dan memori seterusnya.

3. CPU vs I/O Bound
   Jalankan vmstat 1 5. Lajur us (pengguna), sy (sistem), dan wa (tunggu I/O) adalah kunci. Jika wa konsisten tinggi (mis., >30%), isu adalah I/O cakera. Jika us/sy mendominasi, ia adalah CPU-bound.

4. Selidik I/O Cakera
   Untuk sistem yang I/O-bound, gunakan iostat -x 1 untuk melihat penggunaan peranti dan panjang giliran. iotop (jika tersedia) menunjukkan I/O per proses. Cari proses seperti daemon log, titik semak pangkalan data, atau backup yang membebankan cakera.

5. Periksa Tekanan Memori
   Gunakan free -m dan periksa penggunaan swap. Sistem yang bertukar dengan banyak boleh kelihatan seperti beban tinggi. Lihat dmesg untuk mesej oom-killer. Tekanan memori tinggi juga boleh menyebabkan thrashing pada peringkat OS.

6. Semak Log Sistem
   Tiba-tiba, periksa ralat dalam beberapa minit terakhir: bash journalctl -p err -n 100 --since "10 min ago" Cari ralat cakera, kegagalan perkhidmatan systemd, atau kerosakan berulang.

7. Jejak Proses
   Jika proses tertentu terperangkap dalam gelung, lampirkan strace dengan berhati-hati. Contohnya, jejak panggilan sistem selama 10 saat dan ringkaskan: bash timeout 10 strace -c -p $PID Ini boleh mendedahkan panggilan futex yang tidak berkesudahan (pertikaian kunci) atau I/O fail. Untuk profil kernel yang lebih dalam, perf top (sebagai root) mungkin menunjukkan fungsi panas.

Kawalan Risiko

• Jangan bunuh proses secara membuta tuli. Sentiasa semak dengan ps -o user,pid,cmd -p $PID untuk melihat apa dan siapa pemiliknya.
• Gunakan kill -TERM (lembut) sebelum kill -KILL.
• Jika proses tidak kritikal, kurangkan keutamaannya: renice +20 -p $PID.
• Untuk proses I/O berat, gunakan ionice -c3 -p $PID untuk menetapkan kelas idle.
• Jangan sekali-kali mengubah fail konfigurasi tanpa menyalinnya terlebih dahulu. Gunakan cp fail fail.bak.
• Uji sebarang perubahan unit systemd dengan systemd-analyze verify /path/to/perkhidmatan.

Pelan Gulung Balik

• Jika anda mengubah konfigurasi perkhidmatan, sahkan dahulu dan kemudian mulakan semula: systemctl restart my-service.
• Jika anda membuang kerja cron yang disyaki, pulihkan crontab dari sandaran.
• Jika anda memasang pakej jejak sementara, nyahpasang selepas insiden.
• Sentiasa dokumentasikan apa yang anda ubah dan bila, supaya anda boleh mengembalikannya jika perlu.

Pengesahan

• Jalankan semula uptime dan sahkan purata beban turun ke julat yang sihat (mis., <= 1.5x bilangan CPU untuk beban kerja anda).
• Uji perkhidmatan dengan beberapa permintaan: curl -w "@curl-format.txt" -o /dev/null -s https://your-api/health untuk mengukur latensi.
• Pantau vmstat dan iostat selama 5-10 minit untuk pastikan sistem stabil.
• Periksa log untuk ralat baru: journalctl -p err --since "5 min ago".

Bila Perlu Menghantar Tiket OpsGlobal

OpsGlobal menyediakan sokongan SRE jauh 24/7. Hantar tiket apabila: - Beban masih tinggi selepas anda menangani isu proses atau I/O yang jelas. - Anda mengesyaki bug kernel, isu pemacu, atau kerosakan sistem fail yang memerlukan kepakaran mendalam. - Punca tidak jelas, dan perniagaan kehilangan wang semasa anda mencari. - Anda memerlukan pendapat kedua dalam konfigurasi kompleks atau tugas penalaan prestasi.

SRE kami boleh menganalisis dump kemalangan kernel, menggunakan alat jejak lanjutan, dan membantu anda membina pembaikan jangka panjang. Anda juga akan mendapat laporan selepas insiden untuk menambah baik pemantauan.

Ingat, pendekatan sistematik menjimatkan masa. Jangan panik, ikuti buku panduan ini, dan tahu bila untuk meminta bantuan.