Wyczerpane miejsce to najczęstsza przyczyna, dla której serwer przestaje działać bez żadnej złej woli. Witryna zwraca 500, baza nie zapisuje, poczta nie wychodzi, a df -h pokazuje przy tym kilka wolnych gigabajtów. Przejdźmy przez trzy przypadki, w których tak bywa, i przy okazji przez to, co warto wiedzieć o SMART.

Przypadek pierwszy: skończyły się i-węzły

System plików przechowuje dwa ograniczone zasoby: miejsce na treść i wpisy o plikach. Drugi kończy się niezależnie od pierwszego:

df -h
df -i

Jeśli w drugim poleceniu IUse% wynosi 100, rzecz dotyczy i-węzłów. Miejsce jest, ale nie da się utworzyć ani jednego pliku, nawet pustego.

Winowajcy zawsze ci sami: miliony maleńkich plików. Sesje PHP w /var/lib/php/sessions, którym zepsuło się sprzątanie. Pamięć podręczna aplikacji bez czyszczenia. Zablokowana kolejka pocztowa. Katalog z miniaturami. Znaleźć je można tak:

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

Polecenie wypisze katalogi z największą liczbą plików. W dużym systemie działa kilka minut — to normalne.

Przypadek drugi: plik usunięty, a miejsce nie wróciło

Sytuacja bardziej podstępna. Ktoś usunął poleceniem rm rozrośnięty dziennik, ale proces, który do niego pisał, nadal trzyma go otwartym. Pliku nie ma już w katalogu, miejsce pozostaje zajęte i tak będzie do restartu procesu.

sudo lsof +L1

Polecenie pokazuje pliki bez odniesień w systemie plików, wciąż trzymane przez proces. Leczy się to restartem albo łagodnym przeładowaniem tego procesu, a nie poszukiwaniem „gdzie podziały się gigabajty”.

Stąd zasada: rozrośniętego dziennika się nie usuwa, tylko zeruje — wtedy otwarty deskryptor pozostaje sprawny:

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

I od razu potem konfiguruje się rotację, inaczej za tydzień wszystko się powtórzy.

Przypadek trzeci: zjadły dzienniki

Dokąd dokładnie poszło miejsce, widać przy schodzeniu poziom po poziomie:

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

Przełącznik -x nie pozwala zejść na inne systemy plików; bez niego liczenie wpełza w /proc i w zamontowane zasoby sieciowe. Wygodniej robić to wszystko w ncdu, jeśli jest dostępne.

Zwykli pożeracze:

  • journald. Rozstrzyga jedno polecenie: journalctl --disk-usage. Ogranicza się wierszem SystemMaxUse=500M w /etc/systemd/journald.conf, jednorazowo czyści journalctl --vacuum-size=200M;
  • dzienniki narzędzi bezpieczeństwa. Suricata z domyślną konfiguracją zapisuje trzydzieści rodzajów zdarzeń i nie konfiguruje po sobie rotacji — na prawdziwym serwerze dało to 15 GB w dwie doby. To samo bywa z audit.log i z dziennikami diagnostycznymi nginksa;
  • kopie zapasowe składane na tym samym dysku i nigdy nieusuwane;
  • pamięć podręczna apt — apt clean zwraca czasem parę gigabajtów.

Osobno o /boot

Mała partycja, którą zapychają stare jądra. Sama w sobie witryny nie kładzie, za to całkowicie zatrzymuje aktualizacje: nowe jądro się nie instaluje, a za nim staje cała kolejka pakietów. Leczy się to poleceniem apt autoremove --purge, a zapobiega włączeniem automatycznego usuwania nieużywanych jąder w ustawieniach automatycznych aktualizacji.

SMART: które atrybuty mają znaczenie

Od razu zastrzeżenie: na serwerze wirtualnym SMART zwykle jest niedostępny — dysk jest wirtualny, fizycznego pod nim nie widać. To nie awaria, po prostu nie ma danych. Wszystko dalsze dotyczy serwerów dedykowanych i własnego sprzętu.

sudo smartctl -a /dev/sda

Wiersz SMART overall-health self-assessment test result: PASSED to nie powód do spokoju: pozostaje zielony praktycznie do samej awarii. Patrzeć trzeba na konkretne liczniki:

  • 5, Reallocated_Sector_Ct — sektory przeniesione. Nie zero oznacza, że dysk już się sypie; rośnie z czasem — wymieniać bez zwłoki;
  • 197, Current_Pending_Sector — sektory nieczytelne, czekające na decyzję. Najbardziej niepokojący ze wszystkich: zwykle oznacza, że części danych już nie da się odzyskać;
  • 198, Offline_Uncorrectable — to samo, potwierdzone sprawdzeniem;
  • SSD: Percentage Used / Media_Wearout_Indicator — zużyty zasób zapisu. Wielkość przewidywalna, według której planuje się wymianę.

Natomiast temperatura i godziny pracy same w sobie nie mówią nic: dysk z pięcioletnim stażem i zerowymi licznikami błędów jest pewniejszy niż nowy z jedynką w atrybucie 197.

Sens obserwacji

Wszystko powyższe to reakcja na to, co już się wydarzyło. Tymczasem i zapełnianie dysku, i zużycie SSD to procesy powolne i doskonale przewidywalne: wykres zajętości za dwa tygodnie pokazuje datę, w której miejsce się skończy, na długo przed tym, jak to nastąpi. Różnica między „witryna leży od trzeciej w nocy” a „w czwartek trzeba wyczyścić dzienniki” to tylko obecność liczby przed oczami. Jak to wygląda w całości, pokazuje strona demonstracyjna poniżej.