Сервер юки бирдан ошди: сабабни топиш учун 5 та текшириш қадами

Кечагина тез ишлаган сайт бугун секин очилса, панел узоқ юкланса ёки мониторинг хизмати «сервер жавоб бермаяпти» деб огоҳлантирса, биринчи гумон сервер юкига тушади. Юк кескин ошганда ваҳимага тушиб, тарифни дарҳол катталаштириш ёки серверни қайта юклаш кўпинча нотўғри қарор бўлади: сабаб йўқолмайди ва бир неча соатдан кейин муаммо қайтади. Тўғри йўл эса юкни нима яратаётганини аниқлашдир. Қуйидаги беш қадам VPS эгалари учун ёзилган, лекин уларнинг мантиқи оддий хостингда ҳам ишлайди: у ерда баъзи маълумотларни панел ёки техник ёрдам орқали оласиз.

1-қадам: юк ҳақиқатан ҳам юқорими

Аввал рақамларга қаранг. uptime буйруғи охирги 1, 5 ва 15 дақиқадаги ўртача юкни (load average) кўрсатади. Бу сон процессор ядролари сони билан солиштирилганда маънога эга бўлади: 4 ядроли серверда 4 атрофидаги юк тўла банд дегани, 20 эса жиддий навбат борлигини билдиради. Ядролар сонини nproc билан билиб оласиз.

uptime
nproc
free -h
df -h

free -h хотира ва swap ҳолатини кўрсатади: агар бўш хотира деярли қолмаган бўлса, тизим жараёнларни мажбуран тўхтатиши мумкин. df -h эса дискни текширади. Тўлиб қолган диск логлар ёзилишини, база ишини ва сессияларни тўхтатади, натижада сайт ҳам оғирлашади. Баъзан «юк» деб ўйланган нарса аслида тўлган диск бўлиб чиқади.

2-қадам: қайси жараён ресурсни еяпти

top ёки htop реал вақтда энг кўп процессор ва хотира ишлатаётган жараёнларни кўрсатади. Бир марталик рўйхат керак бўлса, ps қулайроқ:

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

Натижада ким юқорида турганига қаранг. Кўп сонли php-fpm ёки httpd жараёнлари сайтга трафик кўп келаётганини билдиради. mysqld юқорида бўлса, оғир сўровлар бор. Агар рўйхатда сиз танимайдиган, ғалати номли ёки /tmp папкасидан ишга тушган жараён процессорни 100% банд қилиб турган бўлса, бу криптовалюта майнери бўлиши мумкин. Бундай жараённи дарҳол тўхтатиш, кейин эса қандай пайдо бўлганини текшириш керак, чунки улар одатда cron орқали ўзини қайта тиклайди.

Процессор кам банд бўлса-ю, юк барибир юқори бўлса, муаммо дискда бўлиши мумкин. top даги wa (iowait) қиймати юқори бўлса, жараёнлар диск жавобини кутиб турибди. Бундай ҳолатда iotop дискка энг кўп ёзаётган жараённи кўрсатади.

3-қадам: кимлар сайтга киряпти

Кўп ҳолларда юк ошишининг сабаби ташқарида бўлади: қидирув ботлари, AI краулерлари, парол танловчи скриптлар ёки оддий DDoS. Веб-сервер access log'идан энг фаол IP манзиллар ва сўралган саҳифаларни чиқариш мумкин:

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

Биринчи буйруқ энг кўп сўров юборган IP манзилларни, иккинчиси браузер ёки бот номларини (User-Agent), учинчиси эса логин саҳифасига неча марта мурожаат қилинганини кўрсатади. Масалан, Тошкентдаги онлайн дўкон сайтида бир кечада юк ўн баробар ошган ва логда битта бот каталогнинг фильтр саҳифаларини минглаб комбинацияда айланиб чиқаётгани аниқланган. robots.txt да фильтр манзилларини ёпиш ва ботни чеклаш юкни бир неча дақиқада нормал ҳолатга қайтарган.

Агар битта IP манзил дақиқасига юзлаб сўров юбораётган бўлса ва у маълум қидирув тизимига тегишли бўлмаса, уни вақтинча блоклаш мумкин. Apache 2.4 да буни .htaccess орқали қуйидагича қилиш мумкин, VPS'да эса файрвол даражасида блоклаш самаралироқ:

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

4-қадам: cron ва фон вазифалари

Агар юк ҳар куни бир хил вақтда, масалан тунда ёки соат бошида кўтарилса, сабаби режалаштирилган вазифа бўлиши эҳтимоли катта: захира нусха олиш, импорт, сайтни индекслаш ёки хабарлар жўнатиш. Жорий фойдаланувчининг cron рўйхатини кўринг:

crontab -l
ls /etc/cron.d/

WordPress сайтларида wp-cron.php ҳар бир ташрифда фон вазифаларини ишга туширади ва трафик кўп бўлганда ортиқча юк беради. Уни ўчириб, ҳақиқий cron орқали мунтазам чақириш одатда анча енгилроқ ишлайди. Бунда wp-config.php га define('DISABLE_WP_CRON', true); қатори қўшилади ва cron'га ҳар 5 ёки 15 дақиқада бир марта ишга тушадиган вазифа ёзилади.

Шунингдек, бир вазифанинг бир нечта нусхаси параллел ишлаб қолмаганини текширинг. Олдинги ишга тушиш тугамай туриб кейингиси бошланиб кетса, жараёнлар сони тез кўпайиб, хотирани тўлдиради. Бунинг олдини олиш учун cron буйруғини flock билан ўраш мумкин.

5-қадам: маълумотлар базасидаги оғир сўровлар

Агар mysqld жараёни юқорида турса, айнан қайси сўровлар бажарилаётганини кўриш керак. MySQL ёки MariaDB консолида қуйидаги буйруқ ҳозир ишлаётган барча сўровларни чиқаради:

mysql -e "SHOW FULL PROCESSLIST;"

Бир хил сўров ўнлаб марта такрорланиб, узоқ вақт «Sending data» ёки «Locked» ҳолатида турса, эҳтимол жадвалда индекс етишмайди ёки плагин жуда самарасиз сўров юборяпти. Узоқ муддатли таҳлил учун секин сўровлар журналини (slow query log) ёқиш фойдали: у белгиланган вақтдан узоқ бажарилган сўровларни ёзиб боради ва уларни кейин таҳлил қилиш мумкин бўлади.

Натижани қайд этинг

Сабаб топилгач, уни қисқача ёзиб қўйинг: қачон бошланган, қайси жараён ёки IP, қандай ҳал қилинган. Кейинги сафар худди шундай ҳолат такрорланса, вақт тежалади. Агар сизда оддий хостинг бўлса ва сервер даражасидаги буйруқларни бажара олмасангиз, sayt.uz кабинетидаги техник ёрдам орқали мурожаат қилиб, юк қачон ошганини айтиб беринг: сервер томонидаги логлар бўйича сабабни аниқлаш мумкин бўлади.