Linux server CPU yoki xotirani yuklayapti: sababini qanday topish

Qisqa javob

Diagnostika tartibi:

1. top yoki htop — hozir aynan kim CPU va xotirani sarflayapti.
2. vmstat 1 — tizimni nima cheklayapti: protsessor, xotira yoki kiritish-chiqarish.
3. iostat -x 1 — hammasi diskka tiralib qolmaganmi.
4. free -h va dmesg — haqiqatda qancha bo‘sh xotira bor va yadro jarayonlarni o‘ldirmaganmi.
5. ps — muayyan jarayon tarixi va tafsilotlari.

vmstat va iostat odatda procps va sysstat paketlariga kiradi.

Load average’ni qanday o‘qish kerak

top yoki uptime natijasida uchta son bor — 1, 5 va 15 daqiqadagi o‘rtacha yuklama. Bu bajarilayotgan yoki bajarilishni kutayotgan jarayonlar soni. Linux’da bunga diskni kutayotgan jarayonlar (D holati) ham kiradi.

• Load average’ni yadrolar soni (nproc) bilan solishtiring. 4 yadroda 4 atrofidagi qiymat to‘liq yuklamani, sezilarli yuqorisi esa navbatni bildiradi.
• Agar load yuqori, CPU esa deyarli bo‘sh bo‘lsa — muammoni protsessorda emas, disk yoki tarmoqda qidiring.
• Birinchi son o‘sib, qolganlari tinch bo‘lsa — bu surunkali muammo emas, yangi sakrash.

1-qadam. top va htop

topda CPU bo‘yicha saralash uchun P, xotira bo‘yicha M tugmasini bosing. htopda buni ustunni bosish yoki F6 tugmasi bilan qilasiz.

%Cpu(s) satriga qarang:

Virtual mashinada yuqori st tizim ichida davolanmaydi — bu xosting yoki tarif bilan bog‘liq masala.

2-qadam. vmstat va iostat

vmstat 1 5

• r ustuni — protsessorga navbat. Doimiy ravishda yadrolar sonidan ko‘p bo‘lsa — CPU yetmayapti.
• b — kiritish-chiqarishda bloklangan jarayonlar.
• si va so — swap’dan va swap’ga almashinuv. Doimiy noldan farqli qiymatlar — xotira kam.

iostat -x 1 5

Diskda yuqori %util va katta await u ulgurmayotganini bildiradi. Unda kim yozayotganini qidiring: iotop jarayonlarni kiritish-chiqarish hajmi bo‘yicha ko‘rsatadi.

3-qadam. Xotira: free, swap va OOM killer

free -h

Asosiysi — free emas, available ustuni. Linux bo‘sh xotirani fayllar keshi (buff/cache) uchun band qiladi va talab bo‘yicha ilovalarga beradi, shuning uchun kichik free — me’yor.

Swap — diskdagi zaxira xotira. Ozroq band qilingan swap qo‘rqinchli emas. Doimiy almashinuv (vmstatdagi si/so) bo‘lsa yomon: tizim sekinlasha boshlaydi.

Xotira va swap tugaganda yadro OOM killerni ishga tushiradi va eng katta «vazn»li jarayonni o‘ldiradi. Tekshiring:

dmesg -T | grep -i -E "killed process|out of memory"
journalctl -k | grep -i oom

Agar ilova o‘z loglarida xatosiz «o‘zi qayta ishga tushsa» — ko‘pincha bu aynan OOM killer.

4-qadam. ps: jarayon tafsilotlari

ps aux --sort=-%cpu | head -n 10
ps aux --sort=-rss  | head -n 10
ps -o pid,etime,rss,cmd -p 1234

RSS — haqiqiy egallangan xotira, etime — jarayon qancha vaqtdan beri ishlayapti. Agar bitta jarayonning RSS’i vaqt o‘tishi bilan faqat o‘ssa, bu sizish belgisi.

Nazoratdan chiqqan jarayon bilan nima qilish kerak

1. Nima ekanini aniqlang: ps -fp PID, ls -l /proc/PID/exe, qaysi servisga tegishli (systemctl status PID).
2. Qayta ishga tushirishdan oldin ma’lumot to‘plang: ilova loglari, journalctl -u servis, muammo boshlangan vaqt. Restartdan keyin dalillar yo‘qoladi.
3. Jarayon kerak, lekin xalaqit bersa, ustuvorligini pasaytiring: renice +10 -p PID.
4. To‘g‘ri to‘xtating: avval kill PID (SIGTERM), faqat yordam bermasa — kill -9 PID.
5. Agar bu cron vazifasi yoki noma’lum jarayon bo‘lsa — u qayerdan ishga tushirilganini tekshiring. Kutilmagan yuqori CPU’li jarayon buzib kirishdan keyin qolgan mayner bo‘lib chiqishi mumkin.

Xotira sizishi: bosqichma-bosqich

1. O‘sishni tasdiqlang: jarayon RSS’ini oraliq bilan yozib boring (siklda ps yoki monitoring).
2. O‘sishni hodisalar bilan bog‘lang: deploy, muayyan marshrut, fon vazifasi.
3. Zararni cheklang: systemd (MemoryMax=) yoki Docker (mem_limit) orqali xotira limiti qo‘ying, shunda butun server emas, faqat shu servis yiqiladi.
4. Vaqtinchalik chora sifatida — rejali qayta ishga tushirish, lekin bu yechim emas.
5. Sababni tilingiz uchun profiler yordamida qidiring: limitsiz o‘sadigan keshlar, yopilmagan ulanishlar, hech kim o‘chirmaydigan hodisa obunachilari.