Levytilan loppuminen on yleisin syy siihen, että palvelin lakkaa toimimasta ilman että kukaan olisi tarkoittanut pahaa. Sivusto palauttaa 500, tietokanta ei kirjoita, posti ei lähde — ja df -h näyttää samaan aikaan muutaman vapaan gigatavun. Käydään läpi kolme tapausta, joissa niin käy, ja samalla se, mitä SMARTista kannattaa tietää.

Tapaus yksi: inodet loppuivat

Tiedostojärjestelmällä on kaksi rajallista resurssia: tila sisällölle ja merkinnät tiedostoista. Jälkimmäinen loppuu ensimmäisestä riippumatta:

df -h
df -i

Jos toisessa komennossa IUse% on 100, kyse on inodeista. Tilaa on, mutta yhtäkään tiedostoa ei voi luoda, ei edes tyhjää.

Syylliset ovat aina samat: miljoonat pienenpienet tiedostot. PHP-istunnot hakemistossa /var/lib/php/sessions, joiden siivous on rikki. Sovelluksen välimuisti ilman puhdistusta. Jumittunut postijono. Pienoiskuvien hakemisto. Näin ne löytyvät:

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

Komento tulostaa hakemistot, joissa on eniten tiedostoja. Suuressa järjestelmässä se kestää muutaman minuutin — se on normaalia.

Tapaus kaksi: tiedosto poistettiin, mutta tila ei palautunut

Kavalampi tilanne. Joku poisti paisuneen lokin komennolla rm, mutta prosessi, joka siihen kirjoitti, pitää sitä yhä avoinna. Tiedostoa ei enää ole hakemistossa, tila pysyy varattuna, ja niin on prosessin uudelleenkäynnistykseen asti.

sudo lsof +L1

Komento näyttää tiedostot, joilla ei ole viitteitä tiedostojärjestelmässä mutta joita prosessi silti pitää. Tämä korjataan käynnistämällä tuo prosessi uudelleen tai lataamalla se pehmeästi, ei etsimällä ”minne gigatavut katosivat”.

Siitä sääntö: paisunutta lokia ei poisteta vaan nollataan — silloin avoin tiedostokahva pysyy käyttökelpoisena:

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

Ja heti perään asetetaan kierto, muuten kaikki toistuu viikon kuluttua.

Tapaus kolme: lokit söivät sen

Minne tila tarkalleen meni, näkyy kun edetään taso kerrallaan:

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

Valitsin -x estää siirtymisen toisiin tiedostojärjestelmiin; ilman sitä laskenta ryömii hakemistoon /proc ja liitettyihin verkkoresursseihin. Kätevämpää on tehdä tämä kaikki työkalulla ncdu, jos se on saatavilla.

Tavalliset ahmijat:

  • journald. Yksi komento ratkaisee: journalctl --disk-usage. Rajoitetaan rivillä SystemMaxUse=500M tiedostossa /etc/systemd/journald.conf, kertasiivous komennolla journalctl --vacuum-size=200M;
  • tietoturvatyökalujen lokit. Suricata kirjoittaa oletusasetuksilla kolmekymmentä tapahtumatyyppiä eikä aseta jälkeensä kiertoa — oikealla palvelimella siitä tuli 15 Gt kahdessa vuorokaudessa. Samoin käy audit.log-tiedostolle ja nginxin vianetsintälokeille;
  • varmuuskopiot, jotka tallennetaan samalle levylle eikä niitä koskaan poisteta;
  • apt-välimuisti — apt clean palauttaa toisinaan pari gigatavua.

Erikseen /boot-osiosta

Pieni osio, jonka vanhat ytimet täyttävät. Sinänsä se ei kaada sivustoa, mutta se pysäyttää päivitykset kokonaan: uusi ydin ei asennu, ja sen taakse jää koko pakettijono seisomaan. Tämä korjataan komennolla apt autoremove --purge ja estetään kytkemällä käyttämättömien ytimien automaattinen poisto päälle automaattipäivitysten asetuksissa.

SMART: mitkä attribuutit merkitsevät

Ensin varaus: virtuaalipalvelimella SMART on yleensä saavuttamattomissa — levy on virtuaalinen, eikä fyysistä näy sen alta. Se ei ole vika, dataa vain ei ole. Kaikki alla oleva koskee omistuspalvelimia ja omaa laitteistoa.

sudo smartctl -a /dev/sda

Rivi SMART overall-health self-assessment test result: PASSED ei ole syy rauhoittua: se pysyy vihreänä käytännössä aivan vikaantumiseen asti. Katsottavia ovat yksittäiset laskurit:

  • 5, Reallocated_Sector_Ct — uudelleensijoitetut sektorit. Nollasta poikkeava arvo tarkoittaa, että levy on jo hajoamassa; jos se kasvaa ajan myötä — vaihda viivyttelemättä;
  • 197, Current_Pending_Sector — lukukelvottomat sektorit, jotka odottavat ratkaisua. Kaikista huolestuttavin: se tarkoittaa yleensä, ettei osaa datasta enää saa pelastettua;
  • 198, Offline_Uncorrectable — sama, tarkistuksella vahvistettuna;
  • SSD: Percentage Used / Media_Wearout_Indicator — kulunut kirjoitusvara. Ennustettava suure, jonka mukaan vaihto suunnitellaan.

Lämpötila ja käyttötunnit sen sijaan eivät kerro sinänsä mitään: viisi vuotta käynnissä ollut levy nollatuilla virhelaskureilla on varmempi kuin uusi, jonka attribuutissa 197 on ykkönen.

Miksi seurata

Kaikki edellä oleva on reagointia siihen, mikä on jo tapahtunut. Samalla sekä levyn täyttyminen että SSD:n kuluminen ovat hitaita ja täysin ennustettavia prosesseja: kahden viikon tilankäyttökäyrä näyttää päivämäärän, jolloin tila loppuu, kauan ennen kuin niin käy. Ero lauseiden ”sivusto on ollut alhaalla kolmesta yöllä” ja ”torstaina pitää siivota lokit” välillä on vain siinä, onko luku silmien edessä. Miltä se näyttää kokonaisuutena, näkyy alla olevalla esittelysivulla.