Server yuki birdan oshdi: sababni topish uchun 5 ta tekshirish qadami

Kechagina tez ishlagan sayt bugun sekin ochilsa, panel uzoq yuklansa yoki monitoring xizmati «server javob bermayapti» deb ogohlantirsa, birinchi gumon server yukiga tushadi. Yuk keskin oshganda vahimaga tushib, tarifni darhol kattalashtirish yoki serverni qayta yuklash ko'pincha noto'g'ri qaror bo'ladi: sabab yo'qolmaydi va bir necha soatdan keyin muammo qaytadi. To'g'ri yo'l esa yukni nima yaratayotganini aniqlashdir. Quyidagi besh qadam VPS egalari uchun yozilgan, lekin ularning mantiqi oddiy hostingda ham ishlaydi: u yerda ba'zi ma'lumotlarni panel yoki texnik yordam orqali olasiz.

1-qadam: yuk haqiqatan ham yuqorimi

Avval raqamlarga qarang. uptime buyrug'i oxirgi 1, 5 va 15 daqiqadagi o'rtacha yukni (load average) ko'rsatadi. Bu son protsessor yadrolari soni bilan solishtirilganda ma'noga ega bo'ladi: 4 yadroli serverda 4 atrofidagi yuk to'la band degani, 20 esa jiddiy navbat borligini bildiradi. Yadrolar sonini nproc bilan bilib olasiz.

uptime
nproc
free -h
df -h

free -h xotira va swap holatini ko'rsatadi: agar bo'sh xotira deyarli qolmagan bo'lsa, tizim jarayonlarni majburan to'xtatishi mumkin. df -h esa diskni tekshiradi. To'lib qolgan disk loglar yozilishini, baza ishini va sessiyalarni to'xtatadi, natijada sayt ham og'irlashadi. Ba'zan «yuk» deb o'ylangan narsa aslida to'lgan disk bo'lib chiqadi.

2-qadam: qaysi jarayon resursni yeyapti

top yoki htop real vaqtda eng ko'p protsessor va xotira ishlatayotgan jarayonlarni ko'rsatadi. Bir martalik ro'yxat kerak bo'lsa, ps qulayroq:

ps aux --sort=-%cpu | head -15
ps aux --sort=-%mem | head -15

Natijada kim yuqorida turganiga qarang. Ko'p sonli php-fpm yoki httpd jarayonlari saytga trafik ko'p kelayotganini bildiradi. mysqld yuqorida bo'lsa, og'ir so'rovlar bor. Agar ro'yxatda siz tanimaydigan, g'alati nomli yoki /tmp papkasidan ishga tushgan jarayon protsessorni 100% band qilib turgan bo'lsa, bu kriptovalyuta mayneri bo'lishi mumkin. Bunday jarayonni darhol to'xtatish, keyin esa qanday paydo bo'lganini tekshirish kerak, chunki ular odatda cron orqali o'zini qayta tiklaydi.

Protsessor kam band bo'lsa-yu, yuk baribir yuqori bo'lsa, muammo diskda bo'lishi mumkin. top dagi wa (iowait) qiymati yuqori bo'lsa, jarayonlar disk javobini kutib turibdi. Bunday holatda iotop diskka eng ko'p yozayotgan jarayonni ko'rsatadi.

3-qadam: kimlar saytga kiryapti

Ko'p hollarda yuk oshishining sababi tashqarida bo'ladi: qidiruv botlari, AI kraulerlari, parol tanlovchi skriptlar yoki oddiy DDoS. Veb-server access logidan eng faol IP manzillar va so'ralgan sahifalarni chiqarish mumkin:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -10
grep -c "wp-login.php" access.log

Birinchi buyruq eng ko'p so'rov yuborgan IP manzillarni, ikkinchisi brauzer yoki bot nomlarini (User-Agent), uchinchisi esa login sahifasiga necha marta murojaat qilinganini ko'rsatadi. Masalan, Toshkentdagi onlayn do'kon saytida bir kechada yuk o'n barobar oshgan va logda bitta bot katalogning filtr sahifalarini minglab kombinatsiyada aylanib chiqayotgani aniqlangan. robots.txt da filtr manzillarini yopish va botni cheklash yukni bir necha daqiqada normal holatga qaytargan.

Agar bitta IP manzil daqiqasiga yuzlab so'rov yuborayotgan bo'lsa va u ma'lum qidiruv tizimiga tegishli bo'lmasa, uni vaqtincha bloklash mumkin. Apache 2.4 da buni .htaccess orqali quyidagicha qilish mumkin, VPS'da esa firewall darajasida bloklash samaraliroq:

<RequireAll>
    Require all granted
    Require not ip 203.0.113.50
</RequireAll>

4-qadam: cron va fon vazifalari

Agar yuk har kuni bir xil vaqtda, masalan tunda yoki soat boshida ko'tarilsa, sababi rejalashtirilgan vazifa bo'lishi ehtimoli katta: zaxira nusxa olish, import, saytni indekslash yoki xabarlar jo'natish. Joriy foydalanuvchining cron ro'yxatini ko'ring:

crontab -l
ls /etc/cron.d/

WordPress saytlarida wp-cron.php har bir tashrifda fon vazifalarini ishga tushiradi va trafik ko'p bo'lganda ortiqcha yuk beradi. Uni o'chirib, haqiqiy cron orqali muntazam chaqirish odatda ancha yengilroq ishlaydi. Bunda wp-config.php ga define('DISABLE_WP_CRON', true); qatori qo'shiladi va cron'ga har 5 yoki 15 daqiqada bir marta ishga tushadigan vazifa yoziladi.

Shuningdek, bir vazifaning bir nechta nusxasi parallel ishlab qolmaganini tekshiring. Oldingi ishga tushish tugamay turib keyingisi boshlanib ketsa, jarayonlar soni tez ko'payib, xotirani to'ldiradi. Buning oldini olish uchun cron buyrug'ini flock bilan o'rash mumkin.

5-qadam: ma'lumotlar bazasidagi og'ir so'rovlar

Agar mysqld jarayoni yuqorida tursa, aynan qaysi so'rovlar bajarilayotganini ko'rish kerak. MySQL yoki MariaDB konsolida quyidagi buyruq hozir ishlayotgan barcha so'rovlarni chiqaradi:

mysql -e "SHOW FULL PROCESSLIST;"

Bir xil so'rov o'nlab marta takrorlanib, uzoq vaqt «Sending data» yoki «Locked» holatida tursa, ehtimol jadvalda indeks yetishmaydi yoki plagin juda samarasiz so'rov yuboryapti. Uzoq muddatli tahlil uchun sekin so'rovlar jurnalini (slow query log) yoqish foydali: u belgilangan vaqtdan uzoq bajarilgan so'rovlarni yozib boradi va ularni keyin tahlil qilish mumkin bo'ladi.

Natijani qayd eting

Sabab topilgach, uni qisqacha yozib qo'ying: qachon boshlangan, qaysi jarayon yoki IP, qanday hal qilingan. Keyingi safar xuddi shunday holat takrorlansa, vaqt tejaladi. Agar sizda oddiy hosting bo'lsa va server darajasidagi buyruqlarni bajara olmasangiz, sayt.uz kabinetidagi texnik yordam orqali murojaat qilib, yuk qachon oshganini aytib bering: server tomonidagi loglar bo'yicha sababni aniqlash mumkin bo'ladi.