Η εξάντληση του χώρου είναι ο συνηθέστερος λόγος που ένας διακομιστής σταματά να δουλεύει χωρίς καμία κακή πρόθεση στη μέση. Ο ιστότοπος επιστρέφει 500, η βάση δεν γράφει, το ταχυδρομείο δεν φεύγει — και το df -h εν τω μεταξύ αναφέρει αρκετά ελεύθερα γιγαμπάιτ. Ας δούμε και τις τρεις περιπτώσεις όπου συμβαίνει αυτό, καθώς και τι αξίζει να ξέρετε για το SMART.

Περίπτωση πρώτη: τελείωσαν τα inodes

Ένα σύστημα αρχείων κρατά δύο περιορισμένους πόρους: χώρο για περιεχόμενο και εγγραφές για τα αρχεία. Το δεύτερο εξαντλείται ανεξάρτητα από το πρώτο:

df -h
df -i

Αν το IUse% στη δεύτερη εντολή είναι 100, το πρόβλημα είναι τα inodes. Χώρος υπάρχει, αλλά δεν μπορεί να δημιουργηθεί ούτε ένα αρχείο, ούτε καν κενό.

Οι ένοχοι είναι πάντα οι ίδιοι: εκατομμύρια μικροσκοπικά αρχεία. Συνεδρίες PHP στο /var/lib/php/sessions των οποίων η αποκομιδή απορριμμάτων χάλασε. Μια προσωρινή μνήμη εφαρμογής που δεν καθαρίζεται ποτέ. Μια κολλημένη ουρά ταχυδρομείου. Ένας κατάλογος μικρογραφιών. Μπορείτε να τα βρείτε έτσι:

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

Η εντολή παραθέτει τους καταλόγους με τα περισσότερα αρχεία. Σε μεγάλο σύστημα τρέχει επί λεπτά — αυτό είναι φυσιολογικό.

Περίπτωση δεύτερη: το αρχείο διαγράφηκε και ο χώρος δεν επέστρεψε

Ακόμη πιο ύπουλη κατάσταση. Κάποιος αφαίρεσε με rm ένα αρχείο καταγραφής που είχε φουσκώσει, αλλά η διεργασία που γράφει σε αυτό το κρατά ακόμη ανοιχτό. Το αρχείο δεν είναι πια στον κατάλογο, ο χώρος παραμένει πιασμένος και θα μείνει έτσι μέχρι να επανεκκινηθεί η διεργασία.

sudo lsof +L1

Η εντολή δείχνει αρχεία με μηδέν συνδέσμους στο σύστημα αρχείων αλλά με διεργασία που ακόμη τα κρατά. Η θεραπεία είναι η επανεκκίνηση ή η ήπια επαναφόρτωση εκείνης της διεργασίας, όχι το κυνήγι του «πού πήγαν τα γιγαμπάιτ».

Εξ ου και ο κανόνας: ένα φουσκωμένο αρχείο καταγραφής δεν διαγράφεται αλλά περικόπτεται, ώστε ο ανοιχτός περιγραφέας να παραμένει χρησιμοποιήσιμος:

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

Και αμέσως μετά, ρυθμίστε περιστροφή — αλλιώς όλο αυτό επαναλαμβάνεται μέσα σε μία εβδομάδα.

Περίπτωση τρίτη: τα αρχεία καταγραφής τον έφαγαν

Πού ακριβώς πήγε ο χώρος φαίνεται κατεβαίνοντας επίπεδο προς επίπεδο:

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

Η σημαία -x το εμποδίζει να περιπλανηθεί σε άλλα συστήματα αρχείων· χωρίς αυτήν η καταμέτρηση σέρνεται στο /proc και σε δικτυακές προσαρτήσεις. Όλα αυτά είναι πιο άνετα στο ncdu, αν είναι διαθέσιμο.

Οι συνηθισμένοι λαίμαργοι:

  • journald. Μία εντολή το λύνει: journalctl --disk-usage. Περιορίζεται με τη γραμμή SystemMaxUse=500M στο /etc/systemd/journald.conf και καθαρίζεται μία φορά με journalctl --vacuum-size=200M·
  • αρχεία εργαλείων ασφαλείας. Η Suricata με την προεπιλεγμένη ρύθμιση γράφει τριάντα τύπους συμβάντων και δεν ρυθμίζει καμία περιστροφή για τον εαυτό της — σε πραγματικό διακομιστή αυτό παρήγαγε 15 GB σε δύο μέρες. Το ίδιο συμβαίνει με το audit.log και με τα αρχεία αποσφαλμάτωσης στον nginx·
  • αντίγραφα ασφαλείας γραμμένα στον ίδιο δίσκο και ποτέ αφαιρούμενα·
  • η προσωρινή μνήμη του apt — το apt clean επιστρέφει πού και πού κάνα δυο γιγαμπάιτ.

Δυο λόγια για το /boot

Ένα μικρό διαμέρισμα που γεμίζει με παλιούς πυρήνες. Δεν ρίχνει από μόνο του τον ιστότοπο, αλλά σταματά τις ενημερώσεις εντελώς: ο νέος πυρήνας δεν εγκαθίσταται και ολόκληρη η ουρά πακέτων κολλά πίσω του. Θεραπεύεται με apt autoremove --purge και προλαμβάνεται ενεργοποιώντας την αυτόματη αφαίρεση αχρησιμοποίητων πυρήνων στις ρυθμίσεις των αυτόματων ενημερώσεων.

SMART: ποια χαρακτηριστικά μετράνε

Μια επιφύλαξη πρώτα: σε εικονικό διακομιστή το SMART συνήθως δεν είναι διαθέσιμο — ο δίσκος είναι εικονικός και δεν βλέπετε τον φυσικό από κάτω. Αυτό δεν είναι βλάβη, απλώς δεν υπάρχουν δεδομένα. Όλα όσα ακολουθούν αφορούν αποκλειστικούς διακομιστές και δικό σας υλικό.

sudo smartctl -a /dev/sda

Η γραμμή SMART overall-health self-assessment test result: PASSED δεν είναι λόγος να χαλαρώσετε: μένει πράσινη πρακτικά μέχρι να πεθάνει ο δίσκος. Αυτό που πρέπει να κοιτάτε είναι οι συγκεκριμένοι μετρητές:

  • 5, Reallocated_Sector_Ct — ανακατανεμημένοι τομείς. Το μη μηδενικό σημαίνει ότι ο δίσκος ήδη φθείρεται· η αύξηση με τον χρόνο σημαίνει αντικαταστήστε τον χωρίς καθυστέρηση·
  • 197, Current_Pending_Sector — τομείς που δεν διαβάζονται και περιμένουν απόφαση. Ο πιο ανησυχητικός από όλους: συνήθως σημαίνει ότι μέρος των δεδομένων είναι ήδη μη ανακτήσιμο·
  • 198, Offline_Uncorrectable — το ίδιο, επιβεβαιωμένο με έλεγχο·
  • SSD: Percentage Used / Media_Wearout_Indicator — η καταναλωμένη αντοχή εγγραφής. Προβλέψιμος αριθμός, και αυτός βάσει του οποίου προγραμματίζεται η αντικατάσταση.

Αντίθετα, η θερμοκρασία και οι ώρες λειτουργίας δεν λένε τίποτα από μόνες τους: ένας δίσκος με πέντε χρόνια λειτουργίας και μηδενικούς μετρητές σφαλμάτων είναι πιο αξιόπιστος από έναν καινούριο με 1 στο χαρακτηριστικό 197.

Το νόημα της παρακολούθησης

Όλα τα παραπάνω είναι αντίδραση σε κάτι που ήδη συνέβη. Κι όμως τόσο ο δίσκος που γεμίζει όσο και η φθορά του SSD είναι αργές, απολύτως προβλέψιμες διαδικασίες: ένα γράφημα πληρότητας δύο εβδομάδων δείχνει την ημερομηνία που θα τελειώσει ο χώρος πολύ πριν συμβεί. Η διαφορά ανάμεσα στο «ο ιστότοπος είναι κάτω από τις τρεις τα ξημερώματα» και στο «την Πέμπτη πρέπει να καθαριστούν τα αρχεία» δεν είναι τίποτα άλλο από το να έχετε τον αριθμό μπροστά σας. Πώς μοιάζει αυτό συναρμολογημένο το δείχνει η σελίδα επίδειξης παρακάτω.