Az elfogyott lemezterület a leggyakoribb oka annak, hogy egy szerver mindenféle rosszindulat nélkül leáll. A webhely 500-at ad vissza, az adatbázis nem ír, a levél nem megy ki — a df -h pedig eközben néhány szabad gigabájtot mutat. Nézzük végig azt a három esetet, amikor ez előfordul, és egyúttal azt is, amit a SMART-ról tudni érdemes.

Első eset: elfogytak az inode-ok

A fájlrendszer két korlátos erőforrást tart: helyet a tartalomnak és bejegyzéseket a fájlokról. A második az elsőtől függetlenül fogy el:

df -h
df -i

Ha a második parancsban az IUse% 100, akkor az inode-okról van szó. Hely van, de egyetlen fájlt sem lehet létrehozni, még üreset sem.

A bűnösök mindig ugyanazok: több millió apró fájl. PHP-munkamenetek a /var/lib/php/sessions könyvtárban, amelyeknél elromlott a takarítás. Alkalmazásgyorsítótár tisztítás nélkül. Beragadt levelezési sor. Bélyegképek könyvtára. Így találod meg őket:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

A parancs kiírja a legtöbb fájlt tartalmazó könyvtárakat. Nagy rendszeren néhány percig fut — ez normális.

Második eset: a fájl törölve, de a hely nem jött vissza

Alattomosabb helyzet. Valaki rm paranccsal törölt egy felduzzadt naplót, de az a folyamat, amely írt bele, még nyitva tartja. A fájl már nincs a könyvtárban, a hely viszont foglalt marad, és így is lesz a folyamat újraindításáig.

sudo lsof +L1

A parancs megmutatja azokat a fájlokat, amelyekre a fájlrendszerben már nincs hivatkozás, de egy folyamat még tartja őket. Ezt az adott folyamat újraindításával vagy lágy újratöltésével orvosolod, nem azzal, hogy azt keresed, „hová lettek a gigabájtok”.

Innen a szabály: a felduzzadt naplót nem törölni kell, hanem nullázni — így a nyitott leíró működőképes marad:

sudo truncate -s 0 /var/log/huge.log

És rögtön utána be kell állítani a rotációt, különben egy hét múlva minden megismétlődik.

Harmadik eset: a naplók ették meg

Hová ment pontosan a hely, az szintenként lefelé haladva látszik:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

A -x kapcsoló nem engedi más fájlrendszerekbe lemenni; nélküle a számolás befúrja magát a /proc könyvtárba és a csatolt hálózati erőforrásokba. Kényelmesebb mindezt ncdu programban végezni, ha elérhető.

A szokásos falánkok:

  • journald. Egyetlen parancs dönti el: journalctl --disk-usage. A SystemMaxUse=500M sorral korlátozható az /etc/systemd/journald.conf fájlban, egyszeri takarítás: journalctl --vacuum-size=200M;
  • a biztonsági eszközök naplói. A Suricata az alapkonfigurációval harmincféle eseményt ír, és nem állít be maga után rotációt — egy valós szerveren ebből 15 GB lett két nap alatt. Ugyanez történik az audit.log fájllal és az nginx hibakeresési naplóival;
  • mentések, amelyeket ugyanarra a lemezre tesznek, és soha nem törölnek;
  • az apt gyorsítótára — az apt clean néha visszaad pár gigabájtot.

Külön a /boot partícióról

Kis partíció, amelyet a régi kernelek töltenek meg. Önmagában nem fekteti le a webhelyet, viszont teljesen megállítja a frissítéseket: az új kernel nem települ, és mögötte áll a teljes csomagsor. Ezt az apt autoremove --purge paranccsal orvosolod, és a nem használt kernelek automatikus törlésének bekapcsolásával előzöd meg az automatikus frissítések beállításaiban.

SMART: mely attribútumok számítanak

Rögtön egy kikötés: virtuális szerveren a SMART általában nem elérhető — a lemez virtuális, a fizikai alatta nem látszik. Ez nem hiba, egyszerűen nincsenek adatok. Minden alábbi a dedikált szerverekre és a saját hardverre vonatkozik.

sudo smartctl -a /dev/sda

A SMART overall-health self-assessment test result: PASSED sor nem ok a nyugalomra: gyakorlatilag a meghibásodásig zöld marad. A konkrét számlálókat kell nézni:

  • 5, Reallocated_Sector_Ct — átirányított szektorok. A nem nulla érték azt jelenti, hogy a lemez már bomlik; ha idővel nő — késlekedés nélkül cserélni;
  • 197, Current_Pending_Sector — olvashatatlan, döntésre váró szektorok. A legaggasztóbb mind közül: általában azt jelenti, hogy az adatok egy része már nem menthető;
  • 198, Offline_Uncorrectable — ugyanez, ellenőrzéssel megerősítve;
  • SSD: Percentage Used / Media_Wearout_Indicator — elhasznált írási erőforrás. Kiszámítható mennyiség, amely alapján a cserét tervezni lehet.

A hőmérséklet és az üzemórák viszont önmagukban semmit nem mondanak: egy ötéves üzemidejű, nulla hibaszámlálójú lemez megbízhatóbb, mint egy új, amelynek a 197-es attribútumában egyes áll.

A figyelés értelme

Minden fenti reakció arra, ami már megtörtént. Eközben a lemez megtelése és az SSD kopása is lassú és teljesen kiszámítható folyamat: a foglaltság kéthetes grafikonja jóval a bekövetkezés előtt megmutatja azt a dátumot, amikor elfogy a hely. A „a webhely hajnali három óta áll” és a „csütörtökön ki kell tisztítani a naplókat” közötti különbség pusztán annyi, hogy van-e szám a szemed előtt. Hogy néz ki mindez egészében, azt az alábbi bemutatóoldal mutatja.