Sebab Pelayan Linux Anda Lambat: Aliran Kerja Diagnostik Sysadmin

Jadi pelayan anda berjalan lebih perlahan daripada binaan Docker pada sambungan dail. Sebelum anda menyalahkan kernel, pembekal awan atau rakan sekerja anda yang "baru menjalankan skrip pantas", mari kita lihat aliran kerja diagnostik yang betul. Apabila kami selesai, anda akan kelihatan seperti seorang wira — atau sekurang-kurangnya seperti seseorang yang tahu perkara yang sebenarnya dilakukan oleh `top`.

Langkah 1: Purata Muatan — Pembohongan Tiga Kali

Apabila anda menjalankan `uptime` atau `top` dan melihat sesuatu seperti `muatan purata: 8.47, 5.32, 3.18`, tindak balas sentak lutut ialah "8 proses menunggu? Mesti CPU." Tetapi purata beban mengira kedua-dua proses terikat CPU dan I/O-tunggu. Pelayan dengan cakera goreng boleh menunjukkan beban 15 semasa duduk pada 2% CPU. Tiga nombor (1m, 5m, 15m) bercerita — jika 1m melonjak tetapi 15m sejuk, ada sesuatu yang pergi ke tepi. Semak dengan `mpstat -P ALL 1 5` untuk memisahkan beban CPU daripada I/O wait (lajur `%iowait`). Jika iowait melebihi 5%, cakera anda adalah kesesakan, bukan CPU anda.

Langkah 2: Memori — Percuma lwn. Tersedia (The Classic Trap)

Jika anda masih menjalankan `percuma -h` dan panik kerana ia menunjukkan "digunakan: 47G" pada pelayan 64GB, tahniah — anda telah jatuh untuk helah tertua dalam buku Linux. Linux suka menggunakan RAM percuma untuk cache cakera. Lajur `buff/cache` itu? Itu bukan memori yang sia-sia — pelayan anda yang bijak. Nombor sebenar ialah `tersedia`, yang memberitahu anda jumlah memori yang sebenarnya percuma untuk aplikasi baharu. Gunakan `free -h` dan lihat baris dua (`-/+ buffer/cache` pada sistem lama), atau jalankan sahaja `htop` dan lihat pada bar memori hijau/kuning dengan betul. Semak juga penggunaan swap — jika `swapon --show` menunjukkan pertukaran sedang digunakan semasa RAM tersedia, `vm.swappiness` anda ditetapkan terlalu agresif (lalai 60 — cuba 10 untuk pelayan).

Langkah 3: Cakera I/O — Pembunuh Senyap

Tiada apa-apa yang memusnahkan prestasi pelayan lebih cepat daripada cakera yang menjerit meminta belas kasihan. Jalankan `iostat -x 1 3` dan lihat `%util`. Inilah kelainannya: `%util` boleh mencecah 100% pada pemacu NVMe moden dan ia masih baik — metrik telah direka untuk karat berputar. Sebaliknya, tonton `menunggu` (purata masa tindak balas I/O). Jika menunggu > 20ms pada SSD atau > 100ms pada HDD, storan anda tercekik. Pesalah sebenar? Selalunya ia pembalakan. Semak sama ada rsyslog atau log aplikasi anda berada pada cakera yang sama dengan pangkalan data. Petua pro: `fatrace` menunjukkan kepada anda proses yang paling banyak menjana aktiviti cakera dalam masa nyata.

Langkah 4: Proses Zombi & Kanak-kanak Lari

Kadangkala masalahnya bukan beban — ia adalah proses yang enggan mati. Proses zombi (keadaan `Z` dalam `ps aux`) ialah proses mati menunggu ibu bapa mereka membaca status keluar mereka. Beberapa zombi adalah perkara biasa; beratus-ratus bermakna sesuatu telah rosak di hulu. Gunakan `ps aux | grep 'Z'` untuk melihat mereka. Lebih teruk ialah kanak-kanak yang melarikan diri — skrip yang mengebom pelayan anda kerana ralat logik. Tetapkan `ulimit -u` (proses pengguna maks) dalam `/etc/security/limits.conf` untuk menghalang satu Apple yang buruk daripada menumbangkan seluruh kebun.

Kesimpulan

Lain kali pelayan anda berasa lembap, jangan mulakan semula perkhidmatan secara rawak atau `bunuh -9` semua yang kelihatan. Ikuti aliran kerja: CPU → Memori → Cakera → Proses. Setiap lapisan memberitahu anda sesuatu yang orang lain tidak boleh. Sysadmin pintar tidak meneka — mereka mengukur. Dan jika semuanya gagal, ingat: `mulakan semula` bukanlah alat diagnostik, tetapi ia adalah alat yang sangat berkesan.

Infografik: Aliran Kerja Diagnostik Pelayan