Ρύθμιση του Linux OOM killer για VPS

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

Πώς ο OOM killer επιλέγει ένα θύμα

Όταν ο πυρήνας δεν μπορεί να ανακτήσει αρκετή μνήμη μέσω της εκδίωξης της προσωρινής μνήμης σελίδων ή της ανταλλαγής, ενεργοποιεί τον OOM killer. Κάθε διαδικασία έχει μια oom_score βαθμολογία μεταξύ 0 και 1000, που προέρχεται κυρίως από το Resident Set Size (RSS) και τη χρήση swap. Η διαδικασία με την υψηλότερη βαθμολογία λαμβάνει ένα SIGKILL.

Το RSS κυριαρχεί στον υπολογισμό, γι' αυτό και η διακοπή σχεδόν πάντα πέφτει στον μεγαλύτερο καταναλωτή μνήμης. Αυτός είναι συχνά η βάση δεδομένων σας, ο διακομιστής εφαρμογών σας ή οποιαδήποτε διαδικασία μακράς διάρκειας που εκτελεί το πιο χρήσιμο έργο. Η διαδικασία που προκάλεσε πραγματικά την εκχώρηση, ο «invoker», σπάνια είναι αυτή που τερματίζεται.

Υπάρχουν δύο είδη συμβάντων OOM που πρέπει να διαχωρίζετε:

• Global OOM: ο κεντρικός υπολογιστής (ή το VPS σας στο σύνολό του) έχει εξαντλήσει τη μνήμη RAM και το swap. Ο πυρήνας σαρώνει κάθε διαδικασία και τερματίζει αυτή με την υψηλότερη βαθμολογία.
• Cgroup OOM: μια συγκεκριμένη cgroup έχει φτάσει στο όριο μνήμης της. Ο πυρήνας τερματίζει μόνο μέσα σε αυτή την cgroup, ακόμα και αν το υπόλοιπο σύστημα έχει μνήμη διαθέσιμη.

Εάν έχετε ρυθμίσει όρια μονάδων systemd ή εκτελείτε containers, τα περισσότερα συμβάντα OOM θα είναι cgroup OOM. Αυτό είναι θετικό: η έκταση της επίδρασης περιορίζεται.

Εντοπισμός πίεσης μνήμης πριν από τη διακοπή

Τα συμβάντα OOM σχεδόν ποτέ δεν είναι ξαφνικά. Συνήθως υπάρχει πρώτα ένα παράθυρο αυξανόμενης πίεσης και ο στόχος της παρακολούθησης είναι να το εντοπίσει μέσα σε αυτό το παράθυρο.

free -h σας δίνει την προβολή του συστήματος. Η στήλη που έχει σημασία είναι available, όχι free: αντιπροσωπεύει την ανακτήσιμη προσωρινή μνήμη σελίδων και αντανακλά το τι μπορείτε πραγματικά να εκχωρήσετε χωρίς εναλλαγή. Διατηρήστε MemAvailable πάνω από περίπου 10 έως 15 τοις εκατό MemTotal σε συνθήκες μέγιστου φορτίου.

Για κατανομή ανά διεργασία, ταξινομήστε κατά RSS:

ps aux --sort=-%mem | head -10

Ή χρησιμοποιήστε htop και ταξινομήστε κατά RES. Οι τιμές που βλέπετε εδώ τροφοδοτούν απευθείας τη βαθμολογία του πυρήνα, οπότε οι κορυφαίες καταχωρήσεις είναι οι πιο πιθανές στόχοι OOM.

Στους πυρήνες 4.20 και νεότερους, οι πληροφορίες Pressure Stall είναι το σύστημα έγκαιρης προειδοποίησης που αξίζει να ενσωματωθεί στην παρακολούθηση:

cat /proc/pressure/memory

Ο some avg10 εικόνα δείχνει το ποσοστό του χρόνου που τουλάχιστον μία εργασία παρέμεινε σε αναμονή για μνήμη κατά τη διάρκεια των τελευταίων δέκα δευτερολέπτων. Κάτω από 5 τοις εκατό είναι εντάξει. Συνεχείς τιμές πάνω από 10 τοις εκατό σημαίνουν ότι το σύστημα ξοδεύει πραγματικό χρόνο μπλοκαρισμένο στην ανάκτηση μνήμης, και είναι πιθανό να συμβεί τερματισμός λόγω OOM.

Το swap thrashing εμφανίζεται στο vmstat 1 ως μη μηδενική si και so στήλες που διατηρούνται με την πάροδο του χρόνου. Μια μικρή ποσότητα μόνιμης ανταλλαγής είναι ακίνδυνη. Η συνεχής εισαγωγή και εξαγωγή δεν είναι.

Προστασία κρίσιμων διαδικασιών με το oom_score_adj

Η βαθμολογία που υπολογίζει ο πυρήνας μπορεί να προσαρμοστεί ανά διαδικασία μέσω oom_score_adj, σε μια κλίμακα από -1000 (απρόσβλητος) έως +1000 (σκότωσέ με πρώτα). Η προσαρμογή προστίθεται απευθείας στην τελική βαθμολογία.

Για μια εφάπαξ αλλαγή σε μια διαδικασία που εκτελείται:

echo -500 | sudo tee /proc/$(pidof sshd)/oom_score_adj

Για οτιδήποτε θέλετε να διατηρηθεί μετά από επανεκκινήσεις, ρυθμίστε το στη μονάδα systemd. Αυτή είναι η σωστή θέση για το sshd, τη βάση δεδομένων σας και οτιδήποτε άλλο δεν μπορείτε να χάσετε:

[Service]
OOMScoreAdjust=-900

Λογικές προεπιλογές για να ξεκινήσετε:

• sshd: -1000. Εάν χάσετε την απομακρυσμένη πρόσβαση κατά τη διάρκεια μιας κρίσης μνήμης, η ανάκτηση γίνεται πολύ πιο δύσκολη.
• MySQL, PostgreSQL, Redis: -800 έως -900. Ισχυρή προστασία χωρίς να τα καθιστάτε εντελώς άθικτα σε μια πραγματικά καταστροφική κατάσταση.
• Εργαζόμενοι εφαρμογών, εργασίες παρτίδας, εργασίες cron: +100 έως +500. Αυτές είναι οι διεργασίες που προτιμάτε να τερματιστούν παρά η βάση δεδομένων σας.

Μην ορίσετε τα πάντα στο -1000. Αν τίποτα δεν μπορεί να τερματιστεί, ο πυρήνας τελικά θα πανικοβληθεί ή θα παγώσει, κάτι που είναι χειρότερο.

Περιορισμός μνήμης με cgroups και systemd

Η προσαρμογή των βαθμολογιών επηρεάζει το ποιος θα τερματιστεί. Τα cgroups επηρεάζουν το αν θα πραγματοποιηθεί ποτέ ο παγκόσμιος τερματισμός. Δίνοντας σε κάθε υπηρεσία ένα αυστηρό ανώτατο όριο, μεταφέρετε τις αστοχίες μνήμης σε ένα μόνο cgroup αντί να αφήσετε μια διαδικασία να εξαντλήσει ολόκληρο το VPS.

Σε ένα αρχείο μονάδας systemd:

[Service]
MemoryHigh=400M
MemoryMax=512M
OOMPolicy=stop
Restart=on-failure
RestartSec=5s

MemoryHigh είναι ένας μαλακός περιορισμός: ο πυρήνας ανακτά επιθετικά σελίδες από το cgroup πάνω από αυτό το σημείο, αλλά δεν τερματίζει τίποτα. MemoryMax είναι το αυστηρό ανώτατο όριο. Εάν το cgroup προσπαθήσει να εκχωρήσει πέρα από αυτό, ο πυρήνας τερματίζει μια διεργασία μέσα στο cgroup. Με Restart=on-failure η υπηρεσία επανέρχεται αμέσως.

Στο cgroup v2 (Ubuntu 22.04 και νεότερες εκδόσεις, πρόσφατο Debian, RHEL 9), memory.oom.group τερματίζει όλες τις διεργασίες στο cgroup μαζί αντί να αφήνει ορφανές διεργασίες. Χρήσιμο για υπηρεσίες πολλαπλών διεργασιών όπως τα pools PHP-FPM όπου μια ομάδα που έχει τερματιστεί κατά το ήμισυ θα λειτουργεί εσφαλμένα.

Μερικές σημειώσεις για συγκεκριμένες εφαρμογές που αξίζει να εφαρμόσετε:

• PHP-FPM: ρυθμίστε pm = ondemand σε μικρές παρουσίες VPS και ρυθμίστε το μέγεθος pm.max_children ανάλογα με το μέσο RSS ανά εργαζόμενο, όχι με την προεπιλογή. Μια ομάδα με μέγεθος 4 GB περιθωρίου σε ένα VPS 2 GB θα παρουσιάσει OOM την πρώτη φορά που θα γεμίσει.
• Node.js: περιορίστε το V8 heap με --max-old-space-size=512 (σε MB). Χωρίς αυτό, το Node θα συνεχίσει να μεγαλώνει μέχρι να παρέμβει ο πυρήνας.
• MySQL και PostgreSQL: innodb_buffer_pool_size και shared_buffers θα πρέπει να αφήνουν ελεύθερο χώρο για την προσωρινή μνήμη σελίδων του λειτουργικού συστήματος, τη μνήμη σύνδεσης και οποιουσδήποτε άλλους χρήστες στο σύστημα. Οι προεπιλογές υποθέτουν έναν αποκλειστικό διακομιστή.

Ανάγνωση των αρχείων καταγραφής μετά από ένα συμβάν OOM

Όταν ενεργοποιείται το OOM killer, ο πυρήνας αποθηκεύει μια λεπτομερή αναφορά στο ring buffer. Ανακτήστε την με:

dmesg -T | grep -iE 'killed process|out of memory'
journalctl -k --grep='Out of memory'

Το τμήμα που πρέπει να διαβάσετε προσεκτικά ξεκινά με τον καλούντα και τελειώνει με το θύμα. Ο πυρήνας εκτυπώνει μια πλήρη λίστα εργασιών με το RSS κάθε διεργασίας, τη χρήση swap και το τελικό oom_score_adj. Τρία πράγματα αξίζει να ελέγξετε:

• Ο περιορισμός. CONSTRAINT_NONE σημαίνει ένα παγκόσμιο OOM, CONSTRAINT_MEMCG σημαίνει ότι ένα cgroup έφτασε στο όριό του. Η λύση διαφέρει σε κάθε περίπτωση.
• Free swap. Αν αυτό 0kB, εξαντλήθηκαν τόσο η μνήμη RAM όσο και ο χώρος swap. Είτε προσθέστε χώρο swap, αυξήστε MemoryMax στον παραβάτη, ή μειώστε τον αριθμό των ταυτόχρονων διεργασιών.
• Η βαθμολογία του θύματος σε σύγκριση με όλα τα άλλα. Εάν η βαθμολογία του θύματος δεν είναι πολύ υψηλότερη από τις επόμενες διαδικασίες, οι oom_score_adj τιμές δεν κάνουν αρκετή δουλειά. Διευρύνετε το χάσμα.

Ειδικά για τα OOM του cgroup, ο μετρητής kill βρίσκεται memory.events μέσα στο cgroup:

cat /sys/fs/cgroup/system.slice/mysql.service/memory.events

Ένας αυξανόμενος oom_kill μετρητή σημαίνει ότι η υπηρεσία φτάνει επανειλημμένα στο όριό της. Αυτό είναι ένα σήμα για να αυξήσετε MemoryMax, να αναλύσετε το φόρτο εργασίας ή να μεταφέρετε την υπηρεσία σε ένα μεγαλύτερο πακέτο, και όχι να συνεχίζετε να την επανεκκινείτε συνεχώς.

Συνοψίζοντας

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

• Προστατέψτε τις υπηρεσίες που δεν μπορείτε να χάσετε, ειδικά το sshd και τις βάσεις δεδομένων σας.
• Περιορίστε όλα τα υπόλοιπα MemoryMax σε μια μονάδα systemd, ώστε μια μεμονωμένη διαφυγή να συνεπάγεται μόνο μια επανεκκίνηση και όχι διακοπή λειτουργίας.
• Παρακολουθήστε το PSI και MemAvailable αντί να περιμένετε dmesg να σας ενημερώσει εκ των υστέρων.
• Αφήστε 15 έως 20 τοις εκατό της μνήμης RAM ως περιθώριο. Η ρύθμιση δεν μπορεί να αντισταθμίσει ένα VPS που είναι απλά πολύ μικρό για το φόρτο εργασίας.

Εάν η πίεση στη μνήμη σας είναι δομική και όχι ρυθμιζόμενη, χρειάζεστε περισσότερη μνήμη RAM ή ταχύτερο χώρο αποθήκευσης με υποστήριξη swap. Τα πακέτα VPS της FDC Servers λειτουργούν σε AMD EPYC με αποθήκευση NVMe, η οποία διατηρεί τις αναγνώσεις με υποστήριξη swap αρκετά γρήγορες ώστε οι σύντομες υπερφορτώσεις μνήμης να μην εξελίσσονται σε διακοπές λειτουργίας.