free i uptime — memorija i opterećenje sistema
Dve komande koje odgovaraju na pitanje „zašto je server spor". Prva pokazuje memoriju, druga opterećenje. Obe se često pogrešno tumače — i to na isti način: ljudi vide veliki broj i zaključe da je problem tu.
free
$ free -h
total used free shared buff/cache available
Mem: 15Gi 4,2Gi 412Mi 892Mi 11Gi 10Gi
Swap: 4,0Gi 0B 4,0Gi
Prva reakcija početnika: slobodno je samo 412 MB, memorija je pri kraju, treba dodati RAM.
To je pogrešan zaključak. Pravi odgovor je u poslednjoj koloni: dostupno je 10 GB.
Zašto je „free" mali broj, a to je dobro
Linux slobodnu memoriju smatra protraćenom. Sve što nije zauzeto koristi za keš — čuva sadržaj fajlova sa diska, jer je čitanje iz RAM-a hiljadu puta brže. Kad aplikaciji zatreba memorija, kernel keš oslobodi trenutno.
Otud kolone:
| total | Ukupno fizičke memorije koju kernel vidi. |
| used | Stvarno zauzeto od strane aplikacija. |
| free | Potpuno nedirnuto. Na sistemu koji radi neko vreme uvek je malo — i to je normalno. |
| shared | Deljena memorija, uglavnom /dev/shm i tmpfs. |
| buff/cache | Keš fajl sistema. Zauzeto, ali se oslobađa po potrebi. |
| available | Jedina kolona koja te zaista zanima. Procena koliko nova aplikacija može dobiti bez korišćenja swap-a. |
Pravilo: gledaj available. Ako je on udoban, memorije ima, bez
obzira na to šta piše u koloni free.
Kada memorije stvarno nema
$ free -h
total used free shared buff/cache available
Mem: 15Gi 14Gi 298Mi 48Mi 412Mi 184Mi
Swap: 4,0Gi 3,7Gi 310Mi
Ovo je stvarni problem, i vidi se po tri stvari: available je
mali, buff/cache je skoro nestao (kernel ga je već žrtvovao), a
swap je gotovo pun.
Ko troši, saznaje se preko ps:
$ ps aux --sort=-%mem | head -5 USER PID %CPU %MEM VSZ RSS COMMAND mysql 1204 2.1 41.3 8912456 6584312 /usr/sbin/mysqld java 2891 0.8 22.7 6234112 3621408 /usr/bin/java -Xmx4g alen 4821 0.1 3.2 892456 512340 /usr/bin/firefox
Kolona RSS je stvarno zauzeta fizička memorija.
VSZ je virtuelna i skoro uvek je mnogo veća — ne brini zbog
nje.
Ostale zastavice
$ free -m # u megabajtima $ free -g # u gigabajtima $ free -s 2 # osvežavaj svake 2 sekunde $ free -h -t # dodaj red sa ukupnim zbirom $ free -h -w # razdvoji buffers i cache u dve kolone
Za praćenje u realnom vremenu bolji su top i htop, gde htop keš prikazuje drugom bojom pa se odmah vidi razlika.
Swap: koliko je normalno
Postojanje zauzetog swap-a nije samo po sebi problem. Kernel tamo preseli stranice koje se dugo nisu koristile, čak i kad ima slobodnog RAM-a.
Problem je aktivna razmena — kad se podaci stalno prebacuju napred i
nazad. To se vidi kroz vmstat:
$ vmstat 2 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa 2 1 3812456 298432 12048 421088 4821 6234 8912 4102 8234 12093 12 8 4 76
Kolone si i so su ulaz i izlaz iz swap-a. Ako
stalno nisu nula, sistem je u nevolji. Kolona wa od 76 znači da
procesor tri četvrtine vremena čeka disk — to je opis potpuno zaglavljenog
servera.
Na zdravom sistemu si i so su nule.
Čišćenje keša
$ sudo sync && sudo sysctl -w vm.drop_caches=3
Naći ćeš ovaj savet na forumima. Skoro nikada ti nije potreban. Kernel keš oslobađa sam kad zatreba, a ovako ga samo praznis pa sistem mora ponovo da čita sve sa diska — što ga privremeno usporava. Jedina legitimna upotreba je merenje performansi diska, kad hoćeš čisto stanje.
uptime
$ uptime 14:23:07 up 47 days, 3:12, 2 users, load average: 0,48 0,72 1,04
Redom: trenutno vreme, koliko sistem radi, koliko je korisnika prijavljeno, i tri broja opterećenja.
$ uptime -p up 6 weeks, 5 days, 3 hours, 12 minutes $ uptime -s 2026-07-06 11:11:23
Druga komanda daje tačno vreme poslednjeg pokretanja — korisno kad proveravaš da li se server neplanirano restartovao.
Load average, i šta on zapravo meri
Tri broja su prosečno opterećenje u poslednjem minutu, pet minuta i petnaest minuta.
Ključna stvar koju gotovo svi pogrešno razumeju: to nije procenat iskorišćenosti procesora. To je prosečan broj procesa koji rade ili čekaju. A na Linuxu — za razliku od većine drugih Unix sistema — u to se računa i čekanje na disk.
Zato broj treba porediti sa brojem jezgara:
$ nproc 4
| 1,00 na 4 jezgra | Iskorišćeno 25%. Sistem je opušten. |
| 4,00 na 4 jezgra | Pun kapacitet, ali bez reda čekanja. Granično, još uvek u redu. |
| 8,00 na 4 jezgra | Duplo preopterećen. Sve se izvršava sporo. |
Isti broj, dakle, znači različite stvari na različitim mašinama. Na mašini sa 32 jezgra opterećenje od 4 je dosada; na jednojezgarnom VPS-u je kriza.
Trend je važniji od trenutnog broja
load average: 0,48 0,72 1,04 # opada — kriza je prošla load average: 3,84 1,92 0,71 # raste — nešto se upravo dešava load average: 2,10 2,08 2,12 # stabilno — ovo je normalno stanje
Prvi broj je najnoviji. Ako je manji od trećeg, sistem se oporavlja; ako je veći, problem je u toku.
Visoko opterećenje, a procesor ne radi ništa
Ovo je najkorisnija stvar na ovoj stranici. Situacija:
$ uptime 15:02:11 up 12 days, load average: 18,42 16,08 12,71 $ top %Cpu(s): 2,1 us, 1,4 sy, 0,0 ni, 4,2 id, 91,8 wa, 0,0 hi, 0,5 si
Opterećenje osamnaest, a procesor gotovo neaktivan. Objašnjenje je
wa — 91,8% vremena se čeka na ulaz i izlaz. Procesi ne rade,
nego stoje u redu za disk, i baš to čekanje diže brojku.
Koji procesi čekaju:
$ ps -eo state,pid,comm | grep "^D" D 2891 mysqld D 2892 mysqld D 4103 rsync
Stanje D znači neprekidivo spavanje, gotovo uvek čekanje na
disk ili mrežni fajl sistem. Takav proces se ne može ubiti čak ni sa
kill -9 — vidi kill.
Zaključak: ovde ne treba jači procesor, nego brži disk ili popravka upita koji čita previše. Bez ovog razlikovanja ljudi mesecima nadograđuju pogrešnu stvar.
Odakle brojevi dolaze
$ cat /proc/loadavg 0.48 0.72 1.04 2/847 12094
Prva tri broja su ista. Zatim broj procesa koji trenutno rade u odnosu na ukupan broj, i PID poslednjeg pokrenutog procesa. Ovaj fajl je zgodan za skripte, jer ne zahteva parsiranje ispisa:
$ cut -d' ' -f1 /proc/loadavg 0.48
Isto važi i za memoriju — /proc/meminfo ima sve što
free prikazuje, samo detaljnije.
Radni tok: server je spor
Redosled provera, od najbržeg ka najsporijem:
$ uptime # da li je opterećenje uopšte visoko $ free -h # da li ima memorije (kolona available) $ top # us, sy ili wa — gde odlazi vreme $ ps aux --sort=-%mem | head # ko troši memoriju $ df -h # nije li disk pun $ vmstat 2 5 # da li se aktivno swapuje
Ovih šest komandi u minutu daju odgovor u većini slučajeva. Napomena uz
df: pun disk ume da izgleda kao problem sa
memorijom, jer usporava sve — a proveri i df -i, o čemu piše u
lekciji Inode-ovi i linkovi.
Sitnice
Zašto je total manji od instalirane memorije
$ free -h | head -2
total used free
Mem: 15Gi 4,2Gi 412Mi
Mašina ima 16 GB, a piše 15. Deo memorije rezervišu kernel i firmver, a deo odlazi integrisanoj grafici. Razlika od nekoliko stotina megabajta je normalna.
free unutar kontejnera laže
U Docker kontejneru free prikazuje memoriju cele mašine
domaćina, a ne ograničenje koje je kontejneru dodeljeno. Stvarno stanje je
u cgroup fajlovima:
$ cat /sys/fs/cgroup/memory.max 2147483648 $ cat /sys/fs/cgroup/memory.current 1893203968
Isto važi i za uptime i za nproc. Ako pišeš
skriptu za nadzor koja radi u kontejneru, ove komande nisu pouzdane.
OOM killer
Kad memorije potpuno nestane, kernel bira proces i ubija ga:
$ sudo dmesg | grep -i "killed process" [3847291.238] Out of memory: Killed process 2891 (java) total-vm:6234112kB
Ako ti je aplikacija „nestala bez traga", ovo je prvo mesto koje treba
proveriti. U logu ostaje trag i kroz
journalctl -k | grep -i oom.
Dug uptime nije razlog za ponos
Sistem koji radi 800 dana znači i da bezbednosne zakrpe kernela nikada nisu primenjene. Provera da li je restart potreban:
$ ls /var/run/reboot-required /var/run/reboot-required
Ako fajl postoji, čeka se restart.
Kratka referenca
free
free -h— čitljive jedinice- gledaj kolonu
available, nefree free -s 2— osvežavanje na dve sekundefree -w— buffers i cache razdvojenops aux --sort=-%mem | head— najveći potrošačivmstat 2— kolonesiisoza aktivnu razmenu
uptime
uptime— vreme rada i opterećenjeuptime -p— čitljivo ·uptime -s— vreme pokretanjanproc— broj jezgara, bez kog load average nema značenjecat /proc/loadavg— isti podaci za skripte- visoko opterećenje uz visok
wautop— problem je disk, ne procesor
Vežba
- Utvrdi koliko memorije tvoj sistem stvarno ima na raspolaganju i
objasni sebi zašto se to razlikuje od kolone
free. - Pronađi tri procesa koji troše najviše memorije, sortirano opadajuće.
- Izračunaj koliki procenat kapaciteta procesora predstavlja tvoje
trenutno opterećenje, koristeći
nproc. - Napravi opterećenje sa
yes > /dev/null &pokrenutim nekoliko puta, prati kako load average raste, pa sve ugasi jednom komandom. - Utvrdi kada je sistem poslednji put pokrenut i da li čeka restart zbog zakrpi.
Za četvrti zadatak ti treba
killall, i obavezno proveri
pgrep pre gašenja.
Praćenje procesa u realnom vremenu je na stranicama top i htop, a zauzeće diska na stranicama df i du.
Cela lekcija je deo vodiča Linux osnove.
Comments
Post a Comment