Pilns disks Linux serverī: kā atrast un atbrīvot vietu

Kad Linux serverī beidzas vieta uz diska, viss sāk lūzt neprognozējami: datubāzes atsakās rakstīt, žurnāli apklust, pakotņu atjauninājumi apstājas pusceļā. Šī pamācība ir domāta ikvienam, kurš administrē Linux serveri vai VPS. Tā parāda, kā atrast, kas īsti apēd vietu, kā to droši atbrīvot un kurus failus nekad nedrīkst aiztikt.

Vispirms noskaidro, kas īsti ir pilns

Sāc ar divām komandām:

df -h
df -i

Pirmā parāda aizņemto vietu katrā failu sistēmā, otrā parāda inode izlietojumu. Ja df -h rāda brīvus gigabaitus, bet programmas joprojām met "No space left on device", visticamāk ir beigušies inodi, nevis baiti. To gandrīz vienmēr izraisa miljoniem sīku failu: PHP sesijas, kešatmiņas fragmenti, rindu faili. Tādā gadījumā risinājums ir izdzēst failu plūdus, un lielāks disks nepalīdzētu.

Pievērs uzmanību arī tam, kurš montēšanas punkts ir pilns. Pilns /var atsevišķā nodalījumā prasa citu tīrīšanas ceļu nekā pilna saknes failu sistēma, un nepareizās vietas tīrīšana neko nedos.

df rāda pilnu, du nepiekrīt: izdzēstie, bet atvērtie faili

Klasiskas lamatas: du -sh / atrod 40 GB failu, bet df apgalvo, ka aizņemti 75 GB. Starpība parasti ir vieta, ko tur faili, kuri ir izdzēsti, kamēr kāds process tos joprojām tur atvērtus. Kodols nevar atbrīvot blokus, kamēr nav aizvērts pēdējais faila deskriptors. Tipisks stāsts: kāds ar rm izdzēsa milzīgu žurnālfailu, bet serviss turpināja rakstīt nu jau neredzamajā failā.

lsof -nP +L1

Šī komanda parāda atvērtos failus ar saišu skaitu nulle kopā ar procesu un faila deskriptoru, kas tos tur. Servisa pārstartēšana vai pārlāde atbrīvo vietu uzreiz:

systemctl restart nginx

Ja servisu šobrīd pārstartēt nevari, saīsini izdzēsto failu caur /proc, izmantojot PID un FD numuru no lsof izvades:

: > /proc/1234/fd/4

Vēl viens tā paša simptoma cēlonis: dati, kas paslēpti zem montēšanas punkta. Ja rezerves kopiju darbs kādreiz rakstīja uz /mnt/backup, kamēr rezerves disks nebija piemontēts, šie faili guļ saknes failu sistēmā un nav redzami, kamēr pa virsu ir piemontēts disks. Atmontē un paskaties, vai ar bind mount piemontē / citā vietā un apskati tur.

Izstaigā koku ar ncdu

Visam pārējam ncdu ir ātrākais veids, kā redzēt, kur aizgājusi vieta:

apt install ncdu
ncdu -x /

Karogs -x notur to vienā failu sistēmā, lai tīkla montējumi un citi nodalījumi nesabojā skaitļus. Navigācija ar bultiņām, direktorijas sakārtotas pēc izmēra, un taustiņš d dzēš izvēlēto vienumu, tāpēc ar šo taustiņu esi apzināts. Ja disks ir tik pilns, ka pakotņu instalēšana neizdodas, parasts du dara to pašu darbu ar vairāk rakstīšanas:

du -xh --max-depth=1 / 2>/dev/null | sort -h

Ej iekšā lielākajā direktorijā un atkārto, līdz atrodi vaininieku.

Parastie aizdomās turamie un kā tos droši iztīrīt

Journald un aplikāciju žurnāli

journalctl --disk-usage
journalctl --vacuum-size=200M

Vakuumēšana dzēš tikai arhivētos žurnāla ierakstus, tāpēc tā ir droša. Lai žurnālu ierobežotu pastāvīgi, iestati SystemMaxUse=200M failā /etc/systemd/journald.conf un pārstartē systemd-journald. Parastajos failos /var/log meklē vienu žurnālu, kas aug daudz ātrāk par pārējiem: strauji augošs žurnāls nozīmē, ka kāda aplikācija cikliski krīt, un īstais labojums ir tur, nevis pierādījumu dzēšanā. Pārbaudi, vai logrotate tiešām strādā, un nekad nedzēs atvērtu žurnālfailu, tā vietā to saīsini:

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

Apt kešs un vecie kodoli

du -sh /var/cache/apt
apt-get clean
apt-get autoremove --purge

apt-get clean vienmēr ir drošs: tas dzēš tikai lejupielādētos pakotņu failus. autoremove --purge dzēš arī vecos kodolus, kas bieži aizņem vairākus gigabaitus /boot un /usr/lib/modules. Pirms apstiprini, palaid uname -r un pārliecinies, ka strādājošais kodols nav dzēšamo sarakstā. Paturi pašreizējo kodolu un vienu zināmi labu rezerves variantu.

Docker attēli, konteineri un sējumi

docker system df
docker system prune

Pirmā komanda parāda, cik vietas aizņem attēli, konteineri, sējumi (volumes) un būvēšanas kešs. Parasts prune dzēš apturētos konteinerus, nelietotos tīklus un bezsaimnieka attēlus, kas parasti ir droši. Bīstamie varianti ir prune -a, kas dzēš katru attēlu, ko nelieto neviens strādājošs konteiners, un viss, kas aiztiek sējumus. Sējumos dzīvo datubāžu dati: palaid docker volume ls un dzēs sējumu tikai tad, kad vari pateikt, kam tas pieder.

Core dumpi un pasta rindas

coredumpctl list
du -sh /var/lib/systemd/coredump /var/crash

Programma, kas regulāri krīt, var atstāt gigabaitiem dumpu. Vecos var dzēst; lai apturētu augšanu, ierobežo tos failā /etc/systemd/coredump.conf un salabo to, kas krīt. Paskaties arī pēc core.* failiem aplikāciju darba direktorijās.

mailq | tail -1
du -sh /var/spool/postfix

Pārpildīta pasta rinda parasti nozīmē ļaunprātīgi izmantotu tīmekļa formu vai skriptu, kas ciklā sūta kļūdu vēstules. Vispirms salabo cēloni. Pēc tam postsuper -d ALL iztukšo rindu, bet tas izdzēš arī leģitīmās izejošās vēstules, tāpēc pirms tīrīšanas rindu izlasi.

Ko nedrīkst dzēst

• Datubāžu direktorijas, piemēram, /var/lib/mysql vai /var/lib/postgresql. Vietu tur atbrīvo, tīrot datus caur pašu datubāzi, nekad ar rm.
• Neko /var/lib/docker iekšienē ar rokām. Lieto docker komandas, citādi sabojāsi krātuves draivera stāvokli.
• /proc/kcore un citus failus /proc vai /sys iekšienē. Tie izskatās milzīgi, bet diska vietu neaizņem vispār.
• Strādājošo kodolu vai tā moduļu direktoriju.
• Atvērtus žurnālfailus. To dzēšana tikai atkārto iepriekš aprakstīto neredzamā atvērtā faila problēmu.

Ja šaubies, pārvieto failu uz citu failu sistēmu, nevis dzēs, pārliecinies, ka nekas nesalūza, un tikai tad dzēs.

Novērs nākamo incidentu

Iestati monitoringa brīdinājumu pie 80 procentu aizpildījuma, lai problēmas risinātu mierīgi, nevis pie 100 procentiem. Ierobežo journald, pārbaudi, vai logrotate aptver katru žurnālu, ko raksta tavas aplikācijas, un ieliec apt-get clean plus piesardzīgu docker prune ikmēneša rutīnā, ko izpildi apzināti, nevis akli no cron. Un, ja dati vienkārši aug, jo aug projekts, tīrīšana ir nepareizais rīks: diskam, kas pastāvīgi ir virs 90 procentiem, vajag vairāk vietas, nevis vairāk dzēšanas. Mūsu VPS serveros Rīgas datu centrā diska vietu vari paplašināt bez pārinstalēšanas, un tas parasti ir lētāk nekā stundas, kas pavadītas, medījot pēdējo gigabaitu.