CPR Pelayan Linux: Triage Prestasi Apabila Kena Kipas

Dah pukul 3 pagi. Pager anda padam. Pelayan pengeluaran terbakar — purata muat pada 80, respons SSH mengambil masa 15 saat, dan pengguna sudah mengadu tentang Slack. Anda mungkin mempunyai lima minit sebelum pihak pengurusan mula bertanya soalan. Apa yang anda semak dahulu?

Setiap sysadmin telah berada di sini. Mari kita bincangkan tentang laluan terpantas daripada "semuanya rosak" kepada "okay, saya tahu apa yang salah" — tanpa panik dan tanpa but semula buta.

Pemeriksaan Kesihatan 60 Saat

Sebelum anda mula mengubah suai parameter kernel, skop kerosakan. Nyalakan ketiga-tiga arahan ini dalam urutan — ia akan memberitahu anda 80% daripada perkara yang perlu anda ketahui:

Jika ketiga-tiganya kelihatan munasabah tetapi pelayan masih tercungap-cungap, semak `dmesg | ekor -20` untuk mesej pembunuh OOM atau ralat I/O cakera. Sembilan kali daripada sepuluh, salah satu daripada empat perkara ini adalah penyebabnya.

Penyebab CPU

Jalankan `atas` atau `htop`, tekan `P` (isih mengikut CPU) dan cari kitaran makan proses. Pesalah biasa:

• Kerja cron lari — seseorang menjadualkan sandaran pada waktu puncak. Klasik.
• Pertanyaan pangkalan data menjadi penyangak — `PILIH * DARI urus niaga DI MANA 1=1` tanpa HAD. Kami semua pernah ke sana.
• Cryptominers — jika anda melihat proses bernama `httpd` atau `sysupdate` menggunakan 400% CPU dan anda tidak menggunakannya, tahniah, anda telah dijack crypto.

Pembetulan pantas: `bunuh -9` pesalah, kemudian tentukan siapa yang meletakkannya di sana. Untuk isu berulang, sediakan had CPU setiap proses dengan kepingan `systemd` atau `cpulimit`.

Apabila Ingatan Mengkhianati Anda

Isu ingatan lebih licik daripada CPU — ia terkumpul perlahan-lahan sehingga swap thrashes dan pembunuh OOM mula bermain rolet Rusia dengan proses anda.

`free -h` menunjukkan memori yang tersedia, tetapi cerita sebenar adalah dalam penggunaan swap. Jika `swapon --show` melaporkan apa-apa yang melebihi 0% selepas pelayan berjalan seketika, anda terlalu komited.

Selam dalam /proc/meminfo:

```
grep -E "^(MemTotal|MemAvailable|SwapTotal|SwapFree|Kotor|Writeback)" /proc/meminfo
```

Jika `Dirty` + `Writeback` melebihi 10% daripada RAM, cakera anda tidak dapat mengikuti penulisan. Anda menghadapi masalah I/O yang menyamar sebagai masalah ingatan.

Pembetulan pantas: Mulakan semula perkhidmatan yang paling lapar dahulu (biasanya apl atau pangkalan data Java). Jika ia kronik, tambahkan fail swap atau — lebih baik lagi — tambahkan RAM. Dan tolong, demi cinta kepada semua yang suci, berhenti menjalankan Chrome pada pelayan pengeluaran.

I/O: Pembunuh Senyap

Penantian I/O ialah pembunuh prestasi yang paling kurang didiagnosis di Linux. `iostat -x 1` akan menunjukkan kepada anda `%util` setiap cakera. Jika secara konsisten melebihi 80%, cakera anda adalah halangan.

Babi I/O teratas untuk diburu:

• Putaran log tersilap — logrotate yang terlalu bersemangat cuba memampatkan 50GB log nginx. Semak `/var/log/` penggunaan cakera.
• Pusat pemeriksaan pangkalan data mengepam — PostgreSQL atau MySQL menulis penimbal kotor. Tala `sasaranpenyelesaiantitiksemak` (PostgreSQL) atau `kapasitiio_innodb` (MySQL).
• Pekerjaan sandaran berjalan semasa waktu perniagaan — rsync direktori 200GB apabila pengguna aktif. Jadualkan ini untuk 2 PG, bukan 2 PTG.

Pembetulan pantas: `ionice -c 3 -p ` untuk mengasingkan proses tidak kritikal kepada kelas I/O melahu. Kemudian alihkan tugas cron sandaran itu ke 2 PG di tempat yang sepatutnya.

Kesimpulan

Triaj prestasi bukan tentang mengetahui setiap parameter kernel tunggal — ia mengenai proses yang boleh diulang. Masa aktif → percuma → df → atas → iostat. Lima arahan, enam puluh saat, dan anda telah beralih daripada "pelayan rosak" kepada "inilah yang salah dan inilah yang perlu dilakukan mengenainya."

Simpan profil selam dalam untuk siang hari. Pada pukul 3 pagi, anda hanya perlukan jawapan. Dan kopi. Semestinya kopi. ☕

Infografik: Triage Prestasi Pelayan Linux

Mendapat cerita perang daripada penyelamat pelayan 3 AM anda sendiri? Letakkannya dalam ulasan — kesengsaraan suka syarikat.