Επεξήγηση της διαχείρισης μνήμης στο Linux: swap, OOM killer και cgroups

Το Linux χειρίζεται τη μνήμη διαφορετικά από τα περισσότερα λειτουργικά συστήματα. Η υψηλή χρήση RAM δεν αποτελεί πάντα πρόβλημα — ο πυρήνας χρησιμοποιεί ενεργά την ελεύθερη μνήμη για προσωρινή αποθήκευση, προκειμένου να επιταχύνει την ανάγνωση του δίσκου. Ωστόσο, όταν δημιουργείται πραγματική πίεση στη μνήμη, τρεις μηχανισμοί αναλαμβάνουν τη δουλειά: το swap, το OOM killer και τα cgroups. Η κατανόηση του τρόπου λειτουργίας του καθενός και του τρόπου διαμόρφωσής τους αποτελεί τη διαφορά μεταξύ ενός διακομιστή που υποβαθμίζεται ομαλά υπό φορτίο και ενός που καταρρέει χωρίς προειδοποίηση.

Πώς διαχειρίζεται το Linux τις σελίδες μνήμης

Κάθε διαδικασία εκτελείται στον δικό της εικονικό χώρο διευθύνσεων, έως και 128 TB σε συστήματα 64-bit. Ο πυρήνας αντιστοιχίζει αυτές τις εικονικές διευθύνσεις στη φυσική μνήμη RAM μέσω πινάκων σελίδων, με το Translation Lookaside Buffer (TLB) να αποθηκεύει προσωρινά τις πρόσφατες αναζητήσεις. Μια επιτυχία TLB διαρκεί περίπου 1 νανοδευτερόλεπτο, ενώ μια αποτυχία κοστίζει 20–100 νανοδευτερόλεπτα, κάτι που συσσωρεύεται σε εργασίες που απαιτούν μεγάλη μνήμη, όπως οι βάσεις δεδομένων.

Η φυσική μνήμη χωρίζεται σε σελίδες των 4 KB και ο πυρήνας τις χωρίζει σε δύο κατηγορίες:

• Σελίδες που υποστηρίζονται από αρχεία — συνδεδεμένες με αρχεία στο δίσκο. Ο πυρήνας μπορεί να απορρίψει τις καθαρές ή να εκκαθαρίσει τις βρώμικες χωρίς να χρειαστεί swap.
• Ανώνυμες σελίδες — μνήμη σωρού και στοίβας χωρίς αρχείο υποστήριξης. Αυτές πρέπει να γραφτούν στο swap πριν ο πυρήνας μπορέσει να τις ελευθερώσει.

Σε διακομιστές με υψηλές απαιτήσεις μνήμης, ένα μεγάλο ποσοστό ανώνυμων σελίδων σημαίνει ότι η swap εμπλέκεται νωρίς. Παρακολουθήστε το si (swap in) και so (swap out) στο vmstat 1 — οι σταθερές τιμές διαφορετικές από το μηδέν είναι η πρώτη σας προειδοποίηση ότι το σύστημα βρίσκεται υπό πίεση.

Για την παρακολούθηση, χρησιμοποιήστε το κατάλληλο εργαλείο για τη δουλειά:

Ένα συνηθισμένο λάθος: η παρακολούθηση της free στήλη free -h και να πανικοβάλλεστε. Η available στήλη είναι αυτή που έχει σημασία. Περιλαμβάνει τη μνήμη που ο πυρήνας μπορεί να ανακτήσει από την κρυφή μνήμη (cache) κατά ζήτηση. Ένας διακομιστής που εμφανίζει μόνο 512 MB ελεύθερα αλλά 5 GB διαθέσιμα δεν έχει πρόβλημα.

Όταν η μνήμη πέσει κάτω από ένα όριο, το kswapd δαίμονας του πυρήνα αρχίζει να ανακτά σελίδες στο παρασκήνιο. Αν αυτό δεν είναι αρκετό, ο πυρήνας προχωρά σε άμεση ανάκτηση, μπλοκάροντας διεργασίες μέχρι να ελευθερωθούν οι σελίδες. Από εδώ προέρχονται οι αιχμές καθυστέρησης. Ρυθμίστε μια ειδοποίηση όταν MemAvailable πέσει κάτω από το 10–15% της συνολικής μνήμης RAM, ώστε να έχετε χρόνο να αντιδράσετε.

Διαμόρφωση swap

Το swap είναι μια περιοχή του δίσκου — είτε ένα διαμέρισμα είτε ένα αρχείο — όπου ο πυρήνας μεταφέρει ανενεργές ανώνυμες σελίδες όταν η μνήμη RAM γεμίσει. Η διαφορά ταχύτητας είναι σημαντική: η μνήμη RAM DDR4 έχει καθυστέρηση περίπου 100 ns, ενώ οι SSD NVMe έχουν περίπου 100.000 ns και οι SSD SATA πλησιάζουν τα 500.000 ns. Το swap είναι ένας αποθηκευτικός χώρος ασφαλείας, όχι επιπλέον μνήμη RAM. Ένας διακομιστής που βασίζεται συνεχώς στο swap έχει ένα πρόβλημα μνήμης που δεν θα επιλυθεί με περισσότερο swap.

Χρησιμοποιήστε ένα αρχείο swap αντί για ένα διαμέρισμα. Είναι πιο εύκολο να αλλάξετε το μέγεθός του και δεν απαιτεί επαναδιαμέριση.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Προσθέστε το αρχείο ώστε /etc/fstab για να διατηρηθεί μετά από επανεκκινήσεις. Το chmod 600 βήμα είναι απαραίτητο — οποιαδήποτε δεδομένα μεταφέρονται από τη μνήμη RAM είναι αναγνώσιμα από το swap, οπότε το αρχείο δεν πρέπει να είναι αναγνώσιμο από όλους.

Αφού δημιουργήσετε το swap, ρυθμίστε το vm.swappiness. Η προεπιλογή του 60 είναι επιθετική. Για τα περισσότερα φορτία εργασίας φιλοξενίας θέλετε ο πυρήνας να προτιμά τη μνήμη RAM και να χρησιμοποιεί το swap μόνο ως έσχατη λύση:

Για το μέγεθος του swap: 1–2 GB είναι αρκετά για ένα VPS 2 GB που χειρίζεται περιστασιακές αιχμές επισκεψιμότητας. Σε συστήματα με 8 GB ή περισσότερα, ένα σταθερό swap 2–4 GB είναι γενικά επαρκές. Ο στόχος είναι να δοθεί στον πυρήνα μια βαλβίδα εκτόνωσης πίεσης για τις κρύες σελίδες, όχι να επεκταθεί η συνολική διευθυνσιοδοτούμενη μνήμη.

Σε διακομιστές με περιορισμένη μνήμη RAM και άφθονη CPU, το zram δημιουργεί μια συμπιεσμένη περιοχή swap στη μνήμη, αποφεύγοντας εντελώς τις εισόδους/εξόδους δίσκου. Αξίζει να το λάβετε υπόψη σε κεντρικούς υπολογιστές VPS πολλαπλών ενοικιαστών όπου το NVMe μοιράζεται μεταξύ των ενοικιαστών. Προσέξτε για διενέξεις εισόδου/εξόδου αν το swap βρίσκεται στην ίδια συσκευή με τα αρχεία της βάσης δεδομένων — η έντονη χρήση του swap και οι εγγραφές δίσκου υψηλής απόδοσης δεν συνυπάρχουν καλά.

Το OOM killer

Όταν ο πυρήνας εξαντλήσει τη μνήμη RAM και το swap και δεν μπορεί να ανακτήσει αρκετή μνήμη με άλλα μέσα, παρεμβαίνει ο OOM killer. Βαθμολογεί τις διεργασίες χρησιμοποιώντας τη oom_badness() συνάρτηση:

points = (rss_anon + rss_file + rss_shmem + swapents + pgtables_pages) + (oom_score_adj × totalpages / 1000)

Η διεργασία με την υψηλότερη βαθμολογία τερματίζεται. Ο τύπος ευνοεί τις διεργασίες που καταναλώνουν μεγάλη μνήμη, και ο πυρήνας αποφεύγει τον τερματισμό πολλών διεργασιών σε γρήγορη διαδοχή ελέγχοντας αν μια διεργασία έχει ήδη τερματιστεί τα τελευταία 5 δευτερόλεπτα.

Δύο τύποι συμβάντων OOM εμφανίζονται στα αρχεία καταγραφής:

• Global OOM — ολόκληρο το σύστημα έχει εξαντλήσει τη μνήμη RAM και το swap. Τα αρχεία καταγραφής έχουν το πρόθεμα Out of memory:
• Cgroup OOM — ένα container ή μια υπηρεσία έφτασε στο memory.max όριο. Τα αρχεία καταγραφής έχουν το πρόθεμα Memory cgroup out of memory:

Για να ελέγξετε προηγούμενα συμβάντα OOM:

dmesg -T | grep -i "out of memory"
journalctl -k --grep="oom"

Δώστε προσοχή στο order πεδίο στα αρχεία καταγραφής OOM. Μια τιμή πάνω από 0 υποδηλώνει κατακερματισμό μνήμης και όχι πλήρη εξάντληση — ο πυρήνας δεν μπόρεσε να βρει αρκετές συνεχόμενες σελίδες ακόμη και με διαθέσιμη ελεύθερη μνήμη.

Μπορείτε να επηρεάσετε ποιες διεργασίες στοχεύει ο OOM killer ρυθμίζοντας το /proc/<pid>/oom_score_adj. Το εύρος είναι από -1000 (ποτέ μη τερματίζω) έως +1000 (τερματίζω πρώτα). Για υπηρεσίες που διαχειρίζεται το systemd, ορίστε αυτό μόνιμα στο αρχείο μονάδας:

[Service]
OOMScoreAdjust=-1000

Πρόσθετες παράμετροι sysctl για τη ρύθμιση της συμπεριφοράς OOM:

Για προληπτική παρακολούθηση, ελέγξτε /proc/pressure/memory (Πληροφορίες Pressure Stall, διαθέσιμες από τον πυρήνα 4.20). Παρακολουθήστε την some avg10 τιμή: κάτω από 5% είναι φυσιολογικό, ενώ αν παραμείνει πάνω από 20% σημαίνει ότι είναι πιθανό να συμβεί ένα συμβάν OOM. Ένας αυξανόμενος allocstall μετρητής στο /proc/vmstat είναι ένα άλλο πρώιμο σήμα — μετράει τις καθυστερήσεις άμεσης ανάκτησης, οι οποίες συχνά προηγούνται των τερματισμών λόγω OOM. Εργαλεία όπως το systemd-oomd ή earlyoom μπορούν να ενεργοποιηθούν στα όρια PSI πριν ενεργοποιηθεί ο OOM killer του πυρήνα.

Cgroups και όρια μνήμης

Οι ομάδες ελέγχου (cgroups) σας επιτρέπουν να οργανώνετε τις διεργασίες σε ομάδες και να επιβάλλετε αυστηρά όρια πόρων. Εισήχθησαν στο Linux 2.6.24 και αποτελούν τη βάση των περιβαλλόντων εκτέλεσης κοντέινερ, συμπεριλαμβανομένων των Docker, Podman, Kubernetes και LXC. Ο πυρήνας παρακολουθεί τη χρήση μνήμης ανά cgroup, καλύπτοντας την ανώνυμη μνήμη, τις σελίδες που υποστηρίζονται από αρχεία και τα αντικείμενα του πυρήνα. Εάν ένα cgroup φτάσει στο όριό του, ο πυρήνας ανακτά μνήμη εντός αυτής της ομάδας ή ενεργοποιεί ένα OOM kill στο πλαίσιο του cgroup.

Τα cgroup v1 και v2 διαφέρουν κυρίως ως προς τον τρόπο δομής τους. Το V1 συνδέει κάθε ελεγκτή (μνήμη, CPU, I/O) ξεχωριστά κάτω από /sys/fs/cgroup/<controller>/, γεγονός που οδηγεί σε ασυνεπή παρακολούθηση των πόρων. Η V2 χρησιμοποιεί μια ενοποιημένη ιεραρχία στο /sys/fs/cgroup/. Το Kubernetes μεταπήδησε στο v2 ως προεπιλογή στην έκδοση 1.25 και κατάργησε την υποστήριξη για το v1 στην έκδοση 1.31.

Για να ελέγξετε ποια έκδοση χρησιμοποιεί το σύστημά σας:

stat -fc %T /sys/fs/cgroup/

cgroup2fs σημαίνει v2; tmpfs συνήθως σημαίνει v1.

Τα βασικά στοιχεία ελέγχου μνήμης στο cgroup v2:

Ένας πρακτικός κανόνας: ρυθμίστε memory.high περίπου 10–20% κάτω memory.max για να δώσετε στον πυρήνα χώρο να ανακτήσει πριν φτάσει στο σκληρό όριο. Κατά τον υπολογισμό του μεγέθους memory.max, προσθέστε 20–30% πάνω από τη μέγιστη χρήση της εφαρμογής για να λάβετε υπόψη την προσωρινή μνήμη σελίδων, η οποία υπολογίζεται στα συνολικά όρια μνήμης του cgroup.

Διαχειριστείτε τα cgroups μέσω του systemd αντί να γράφετε απευθείας στο σύστημα αρχείων του cgroup. Χρησιμοποιήστε οδηγίες αρχείων μονάδας όπως MemoryMax=, MemoryHigh=και MemoryMin= για μόνιμα όρια. Για γρήγορες δοκιμές:

systemd-run --scope -p MemoryMax=512M <command>

Για ομάδες εργαζομένων διακομιστών ιστού, η ρύθμιση memory.oom.group=1 εξασφαλίζει μια καθαρή διακοπή λειτουργίας εάν ένας εργαζόμενος υπερβεί το όριό του — χωρίς να μένουν πίσω ορφανές διεργασίες. Για μηχανές βάσεων δεδομένων, memory.min προστατεύει το buffer pool από την ανάκτηση υπό πίεση σε επίπεδο συστήματος.

Διαμόρφωση μνήμης ανά ρόλο διακομιστή

Οι σωστές ρυθμίσεις μνήμης εξαρτώνται από τη λειτουργία του διακομιστή. Η εφαρμογή της ίδιας διαμόρφωσης σε μια βάση δεδομένων και έναν διακομιστή ιστού PHP θα βλάψει έναν από τους δύο.

Για MySQL και PostgreSQL, εκχωρήστε το 50–70% της διαθέσιμης μνήμης RAM στο innodb_buffer_pool_size, απενεργοποιήστε το Transparent Huge Pages για να μειώσετε τις αιχμές καθυστέρησης και προστατέψτε τη διαδικασία με OOMScoreAdjust=-900 στο αρχείο μονάδας systemd.

Για το PHP-FPM, διαμορφώστε το μέγεθος των ομάδων εργαζομένων (worker pools) με βάση την πραγματική χρήση μνήμης. Κάθε εργαζόμενος χρησιμοποιεί συνήθως 30–100 MB. Διαιρέστε τη διατεθειμένη μνήμη RAM με το μέσο μέγεθος εργαζομένου για να λάβετε μια ασφαλή pm.max_children τιμή. Χρησιμοποιήστε memory.max τα cgroups για να περιορίσετε το pool.

Για φόρτους εργασίας με έντονη εγγραφή, ορίστε vm.dirty_ratio σε περίπου 10% και vm.dirty_background_ratio στο 3%. Αυτό εκκαθαρίζει τις «βρώμικες» σελίδες πιο συχνά, αποφεύγοντας μεγάλες καθυστερήσεις I/O.

Κάντε τη ρύθμιση του πυρήνα μόνιμη αποθηκεύοντας τις παραμέτρους στο /etc/sysctl.d/90-memory.conf. Οι ρυθμίσεις που εφαρμόζονται κατά την εκτέλεση χάνονται κατά την επανεκκίνηση.

Για μια σύνοψη των συνιστώμενων τιμών ανά ρόλο:

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