Slut på diskutrymme är den vanligaste orsaken till att en server slutar fungera utan att någon velat något illa. Sajten svarar 500, databasen skriver inte, posten går inte ut — och df -h visar samtidigt några lediga gigabyte. Låt oss gå igenom tre fall där det händer, och samtidigt det du behöver veta om SMART.

Fall ett: inoderna tog slut

Ett filsystem har två begränsade resurser: utrymme för innehåll och poster om filer. Den andra tar slut oberoende av den första:

df -h
df -i

Är IUse% i det andra kommandot 100 handlar det om inoder. Utrymmet finns, men det går inte att skapa en enda fil, inte ens en tom.

De skyldiga är alltid desamma: miljoner mycket små filer. PHP-sessioner i /var/lib/php/sessions där städningen gått sönder. En applikationscache utan rensning. En låst e-postkö. En katalog med miniatyrbilder. Så här hittar du dem:

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

Kommandot skriver ut katalogerna med flest filer. På ett stort system tar det några minuter — det är normalt.

Fall två: filen raderad men utrymmet kom inte tillbaka

Ett listigare läge. Någon raderade en uppsvälld logg med rm, men processen som skrev till den håller den fortfarande öppen. Filen finns inte längre i katalogen, utrymmet förblir upptaget, och så är det tills processen startas om.

sudo lsof +L1

Kommandot visar filer utan referenser i filsystemet som ändå hålls av en process. Det botas med en omstart eller en mjuk omladdning av den processen, inte med letande efter ”vart tog gigabytena vägen”.

Därav regeln: en uppsvälld logg raderas inte utan nollställs — då förblir den öppna filhandtaget användbart:

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

Och direkt därefter ställer man in rotation, annars upprepas allt om en vecka.

Fall tre: loggarna åt upp det

Vart utrymmet exakt tog vägen syns när man går nivå för nivå:

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

Flaggan -x hindrar nedstigning i andra filsystem; utan den kryper räkningen in i /proc och i monterade nätverksresurser. Bekvämare är att göra allt detta i ncdu om det finns tillgängligt.

De vanliga slukarna:

  • journald. Ett kommando avgör: journalctl --disk-usage. Begränsas med raden SystemMaxUse=500M i /etc/systemd/journald.conf, engångsrensning med journalctl --vacuum-size=200M;
  • säkerhetsverktygens loggar. Suricata skriver med standardkonfigurationen trettio typer av händelser och ställer inte in någon rotation efter sig — på en riktig server blev det 15 GB på två dygn. Samma sak händer med audit.log och med nginx felsökningsloggar;
  • säkerhetskopior som läggs på samma disk och aldrig raderas;
  • apt-cachen — apt clean ger ibland tillbaka ett par gigabyte.

Särskilt om /boot

En liten partition som fylls av gamla kärnor. I sig fäller den inte sajten, men den stoppar uppdateringarna helt: den nya kärnan installeras inte, och bakom den står hela paketkön still. Det botas med apt autoremove --purge och förebyggs genom att slå på automatisk borttagning av oanvända kärnor i inställningarna för automatiska uppdateringar.

SMART: vilka attribut som betyder något

Först en reservation: på en virtuell server är SMART vanligen otillgängligt — disken är virtuell och den fysiska syns inte under den. Det är inte ett fel, det finns bara inga data. Allt nedan gäller dedikerade servrar och egen hårdvara.

sudo smartctl -a /dev/sda

Raden SMART overall-health self-assessment test result: PASSED är inget skäl till lugn: den förblir grön praktiskt taget ända fram till haveriet. Det man ska titta på är de enskilda räknarna:

  • 5, Reallocated_Sector_Ct — omplacerade sektorer. Ett värde som inte är noll betyder att disken redan håller på att gå sönder; växer det över tid — byt utan dröjsmål;
  • 197, Current_Pending_Sector — oläsbara sektorer som väntar på beslut. Den mest oroande av alla: den betyder oftast att en del data redan inte går att rädda;
  • 198, Offline_Uncorrectable — detsamma, bekräftat av en kontroll;
  • SSD: Percentage Used / Media_Wearout_Indicator — förbrukad skrivkapacitet. En förutsägbar storhet som man planerar bytet efter.

Temperatur och drifttimmar säger däremot ingenting i sig: en disk med fem års drift och nollställda felräknare är säkrare än en ny med en etta i attribut 197.

Poängen med att titta

Allt ovan är reaktion på det som redan hänt. Samtidigt är både diskens påfyllning och SSD:ns förslitning långsamma och fullständigt förutsägbara förlopp: en kurva över utrymmet de senaste två veckorna visar datumet då utrymmet tar slut långt innan det sker. Skillnaden mellan ”sajten ligger nere sedan tre på natten” och ”på torsdag behöver loggarna rensas” är bara att ha en siffra framför ögonen. Hur det ser ut i sin helhet visar demonstrationssidan nedan.