- Ο προηγμένος συντονισμός πυρήνα με το sysctl σάς επιτρέπει να προσαρμόσετε το δίκτυο, τη μνήμη, τα αρχεία και τον χρονοπρογραμματιστή για να μεγιστοποιήσετε την απόδοση και τη σταθερότητα.
- Είναι απαραίτητο να μετρώνται τα δεδομένα πριν και μετά με βάση τα σημεία αναφοράς και την παρακολούθηση, ώστε να επικυρώνεται ο πραγματικός αντίκτυπος κάθε αλλαγής.
- Συγκεκριμένα προφίλ (ιστός, βάσεις δεδομένων, χαμηλή καθυστέρηση, Kubernetes) επιτυγχάνουν καλύτερα αποτελέσματα από μια ενιαία γενική διαμόρφωση.
- Εργαλεία όπως τα perf, ftrace, vmstat και iostat διευκολύνουν την επαναληπτική, ασφαλή και αντικειμενική βελτιστοποίηση βάσει δεδομένων.
Αν διαχειρίζεστε διακομιστές Linux για κάποιο χρονικό διάστημα, τελικά θα ανακαλύψετε ότι η διαφορά μεταξύ ενός μέτριου συστήματος και ενός που λειτουργεί υπό μεγάλο φόρτο έγκειται στο πόσο καλά έχετε ρυθμίσει τον πυρήνα. Δεν πρόκειται μόνο για την εγκατάσταση περισσότερης μνήμης RAM ή μιας πιο ισχυρής CPU: πολλά σημεία συμφόρησης επιλύονται προσαρμόζοντας μερικές προσεκτικά επιλεγμένες παραμέτρους.
Ο πυρήνας εκθέτει εκατοντάδες επιλογές δικτύου, μνήμης, συστήματος αρχείων και προγραμματισμού διεργασιών που μπορούν να τροποποιηθούν άμεσα. Με το εργαλείο sysctl και κάποιες προσαρμογές στο /procΕίναι δυνατό να αξιοποιήσετε στο έπακρο το υλικό και να επιτύχετε χαμηλότερη καθυστέρηση, υψηλότερη απόδοση και καλύτερη σταθερότητα Αυτό ισχύει για διακομιστές ιστού και βάσεις δεδομένων, καθώς και για περιβάλλοντα πραγματικού χρόνου και Kubernetes. Ωστόσο, είναι σημαντικό να γνωρίζετε ακριβώς τι κάνετε και πώς να το μετρήσετε.
Τι είναι το sysctl και πώς οργανώνει τις παραμέτρους του πυρήνα;
Χρησιμότητα sysctl Είναι η πύλη για την αλλαγή των παραμέτρων του πυρήνα χωρίς να χρειάζεται επαναμεταγλώττιση ή επανεκκίνηση, επιτρέποντας ανάγνωση και τροποποίηση τιμών κατά τον χρόνο εκτέλεσης για να δοκιμάσετε άμεσα τις διαμορφώσεις. Αυτές οι παράμετροι είναι οργανωμένες σε ένα δέντρο χαμηλής ιεραρχίας /proc/sys/και το καθένα ελέγχει μια συγκεκριμένη συμπεριφορά του συστήματος.
Οι ρυθμίσεις ομαδοποιούνται σε ξεχωριστές κατηγορίες, διευκολύνοντας τον εντοπισμό των αλλαγών που πρέπει να κάνετε όταν αντιμετωπίζετε ένα συγκεκριμένο πρόβλημα απόδοσης ή σταθερότητας. Αυτή η δομή σάς επιτρέπει να εστιάζετε, για παράδειγμα, αποκλειστικά στο δίκτυο (net.*), τη μνήμη (vm.*) ή το σύστημα αρχείων (fs.*) χωρίς να χαθείτε στις υπόλοιπες επιλογές του πυρήνα.
Οι κύριες κατηγορίες που θα βρείτε στο /proc/sys/ Αυτά περιλαμβάνουν, μεταξύ άλλων:
- πυρήνας.*: γενικές επιλογές πυρήνα (χρονοπρογραμματιστής, PID, μηνύματα, NUMA, κ.λπ.).
- vm.*: διαχείριση εικονικής μνήμης, πολιτικές ανταλλαγής, προσωρινής μνήμης και υπερφόρτωσης.
- καθαρά.*Στοίβα δικτύου IPv4/IPv6, buffers TCP/UDP, ουρές, έλεγχος συμφόρησης.
- fs.*: όρια περιγραφέων, inodes, inotify, συμπεριφοράς AIO και VFS.
- προγραμματιστής*: συγκεκριμένες παράμετροι ορισμένων συσκευών και προγραμμάτων οδήγησης.
με sysctl -a Μπορείτε να απαριθμήσετε όλες τις διαθέσιμες παραμέτρους και με εντολές όπως sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse ανάγνωση συγκεκριμένων τιμών, κάτι που είναι το κλειδί για έλεγχος της τρέχουσας διαμόρφωσης πριν αλλάξετε οτιδήποτε. Για να εντοπίσετε κάτι συγκεκριμένο, είναι σύνηθες να φιλτράρετε με grep, για παράδειγμα: sysctl -a | grep tcp.
Η άμεση τροποποίηση μιας παραμέτρου είναι τόσο απλή όσο η χρήση sysctl -w clave=valorΩστόσο, είναι σημαντικό να κατανοήσετε ότι αυτές οι αλλαγές είναι προσωρινές. Για να τις αποθηκεύσετε μετά από μια επανεκκίνηση, είναι απαραίτητο να δημιουργήσετε αντίγραφο ασφαλείας της διαμόρφωσης. /etc/sysctl.conf ή σε αρχεία του /etc/sysctl.d/, συνήθως χρησιμοποιώντας αριθμημένα αρχεία (για παράδειγμα 10-network.conf, 20-memory.conf, 99-custom.conf) που καθορίζουν τη σειρά με την οποία εφαρμόζονται.
Μετρήστε πριν αγγίξετε: σημεία αναφοράς και βασική τιμή συστήματος
Πριν ξεκινήσετε να παίζετε με τους δείκτες, είναι συνετό να καθορίσετε μια αντικειμενική βάση απόδοσης . Χωρίς προηγούμενα δεδομένα, είναι αδύνατο να γνωρίζετε αν οι αλλαγές έχουν βελτιώσει ή επιδεινώσει το σύστημα και θα πέσετε στην κλασική παγίδα του «μου φαίνεται καλύτερο», η οποία είναι άχρηστη για τη λήψη ορθών αποφάσεων.
Σε επίπεδο συστήματος, είναι καλή ιδέα να συλλέγετε στατιστικά στοιχεία για την CPU, το φορτίο, τη μνήμη, τον δίσκο και το δίκτυο για λίγα λεπτά με ένα αντιπροσωπευτικό φορτίο. Εργαλεία όπως uptime, mpstat, vmstat, iostat -x o sar -n DEV Σας επιτρέπουν να δείτε πώς συμπεριφέρεται ο πυρήνας, πόσο swap χρησιμοποιεί, πώς ανταποκρίνεται η είσοδος/έξοδος του δίσκου και εάν το δίκτυο είναι κορεσμένο ή σπαταλά εύρος ζώνης.
Εκτός από αυτήν την επισκόπηση, είναι σημαντικό να εκτελέσετε συγκεκριμένα benchmarks για την εφαρμογή που θέλετε να βελτιστοποιήσετε. Σε διακομιστές ιστού, μπορείτε να χρησιμοποιήσετε ab (Apache Bench) ή παρόμοια εργαλεία για μέτρηση αιτήματα ανά δευτερόλεπτο, μέση καθυστέρηση και σφάλματαΣε βάσεις δεδομένων, βοηθητικά προγράμματα όπως mysqlslap o sysbench Βοηθούν στην αξιολόγηση των συναλλαγών ανά δευτερόλεπτο και των χρόνων ερωτημάτων.
Για παράδειγμα, σε ένα σενάριο χωρίς ρύθμιση, είναι σύνηθες να βρίσκουμε αριθμούς όπως 500 αιτήματα HTTP με μέσο χρόνο απόκρισης 200 ms, περίπου 250 ερωτήματα SQL με καθυστέρηση 40 ms, ταχύτητα δικτύου περίπου 500 Mbps και φόρτο συστήματος που πλησιάζει το όριό του υπό πίεση. Αυτοί οι αριθμοί θα χρησιμοποιηθούν για να επαληθευτεί, μετά την εφαρμογή αλλαγών στον πυρήνα, εάν επιτυγχάνεται πράγματι μια μετρήσιμη αύξηση στην απόδοση και μια μείωση στην καθυστέρηση.
Τέλος, καταγράψτε τις εντολές και τα αποτελέσματα πριν κάνετε οποιεσδήποτε αλλαγές. Η κατοχή ενός ιστορικού θα σας επιτρέψει να συγκρίνετε με ακρίβεια διαφορετικές παρτίδες προσαρμογών και θα σας βοηθήσει επίσης να εντοπίσετε παλινδρομήσεις μετά από μια ενημέρωση πυρήνα ή μετά την εισαγωγή ενός νέου προφίλ sysctl στην παραγωγή.
Προηγμένες ρυθμίσεις μνήμης: vm.*
Η μνήμη είναι ένα από τα υποσυστήματα όπου οι αλλαγές στον πυρήνα είναι πιο αισθητές. Ένας διακομιστής με άφθονη μνήμη RAM, αλλά κακώς διαμορφωμένος, μπορεί να καταλήξει να χρησιμοποιεί άσκοπα χώρο εναλλαγής, προκαλώντας... Αυξήσεις εισόδου/εξόδου και δραστικές μειώσεις στην απόδοσηΓι' αυτό και παράμετροι όπως vm.swappinessΟι αναλογίες σελίδων που δεν είναι καλές ή η συμπεριφορά της προσωρινής μνήμης VFS είναι εξίσου σημαντικές.
Παράμετρος vm.swappiness Αυτό ελέγχει πόσες σελίδες μνήμης στέλνει ο πυρήνας για ανταλλαγή. Σε πολλές διανομές, έχει οριστεί σε 60, μια τιμή που προορίζεται για μικτά περιβάλλοντα επιφάνειας εργασίας. Για διακομιστές βάσεων δεδομένων ή εφαρμογές με χαμηλή καθυστέρηση, είναι συνήθως προτιμότερο να τη μειώσετε σε 10 ή ακόμα και λιγότερο, με αποτέλεσμα ένα πιο αποτελεσματικό σύστημα. Δώστε προτεραιότητα στη διατήρηση δεδομένων στη μνήμη RAM και μειώστε την εναλλαγή δεδομένωνΔεν είναι ασυνήθιστο να βλέπουμε την κίνηση στο δίσκο να μειώνεται κατακόρυφα και οι εφαρμογές να ανταποκρίνονται με πολύ λιγότερο jitter μετά από αυτήν την προσαρμογή.
Ένα άλλο βασικό δομικό στοιχείο είναι vm.dirty_ratio y vm.dirty_background_ratioΑυτές οι τιμές καθορίζουν το ποσοστό της μνήμης που μπορεί να γεμίσει με λερωμένες σελίδες πριν ο πυρήνας ξεκινήσει την εκκαθάρισή τους στον δίσκο. Υπερβολικά υψηλές τιμές μπορούν να οδηγήσουν σε μεγάλες εκρήξεις εγγραφών, με τεράστιες καθυστερήσεις για όλες τις εφαρμογές όταν συμβαίνει η εκκαθάριση. Η μείωση αυτών των ποσοστών σε αριθμούς όπως 15 και 5, αντίστοιχα, συνήθως οδηγεί σε πιο συνεπές και προβλέψιμο μοτίβο εισόδου/εξόδου.
Η ρύθμιση του vm.vfs_cache_pressure Αυτό καθορίζει πόσο επιθετικά ο πυρήνας καθαρίζει τις προσωρινές μνήμες inode και καταλόγων. Μια προεπιλεγμένη τιμή 100 τείνει να καθαρίζει την προσωρινή μνήμη γρήγορα, ενώ ρυθμίσεις γύρω στο 50 επιτρέπουν τη διατήρηση των μεταδεδομένων για μεγαλύτερο χρονικό διάστημα, αυξάνοντας το ποσοστό επιτυχίας για τις λειτουργίες αρχείων και βελτιώνοντας την απόδοση. η αντιληπτή απόδοση του συστήματος αρχείων, κάτι βασικό σε διακομιστές που χειρίζονται εκατομμύρια μικρά αρχεία.
Από την πλευρά του, vm.min_free_kbytes Διατηρήστε μια ελάχιστη ποσότητα ελεύθερης μνήμης για να διασφαλίσετε ότι το σύστημα μπορεί να ανταποκριθεί σε εκρήξεις κατανομής χωρίς να αντιμετωπίσει καταστάσεις αιφνίδιας εκκίνησης (OOB). Το μέγεθος αυτού σε περίπου 0,5% έως 1% της συνολικής μνήμης RAM είναι συνήθως ένα αποτελεσματικό μέτρο ασφαλείας για να αποτρέψετε την εξάντληση του χώρου του πυρήνα υπό ακραίο φόρτο και την έναρξη τερματισμού κρίσιμων διεργασιών, βελτιώνοντας έτσι την απόδοση. συνολική σταθερότητα του ξενιστή.
Τέλος, η πολιτική υπερβολικής δέσμευσης αξίζει προσοχής: παράμετροι όπως vm.overcommit_memory y vm.overcommit_ratio Καθορίζουν πόση εικονική μνήμη εκχωρείται στις διεργασίες σε σχέση με τη διαθέσιμη RAM και την ανταλλαγή. Σε ορισμένες περιπτώσεις (για παράδειγμα, με το Redis ή ορισμένες βάσεις δεδομένων) επιτρέπεται η επιθετική υπερδέσμευση, ενώ σε άλλες προτιμάται μια πιο συντηρητική πολιτική για τον περιορισμό του κινδύνου OOM και καταστάσεις υπερβολικά εξασθενημένης μνήμηςΓια τεχνικές ανάλυσης και διάγνωσης πολύπλοκων περιπτώσεων, συμβουλευτείτε εντοπισμός σφαλμάτων μνήμης σε Linux.
Προηγμένη βελτιστοποίηση δικτύου: net.* και TCP/IP
Η στοίβα δικτύου είναι ίσως η περιοχή όπου η ρύθμιση είναι πιο αισθητή σε περιβάλλοντα παραγωγής. Μια απλή αλλαγή στις ουρές σύνδεσης ή στα buffer μπορεί να κάνει τη διαφορά μεταξύ ενός διακομιστή που πνίγεται στα 500 Mbps και ενός που Κορεσμαίνει εύκολα το gigabit.Οι παράμετροι κάτω από net.core.* y net.ipv4.* Σε αυτόν τον τομέα, είναι οι καλύτεροι σύμμαχοί σας.
Αρχικά, τα μεγέθη των buffer socket επηρεάζουν άμεσα τη μέγιστη απόδοση μιας σύνδεσης, ειδικά όταν υπάρχουν υψηλές καθυστερήσεις ή συνδέσεις υψηλής χωρητικότητας. Προσαρμογή net.core.rmem_max y net.core.wmem_max σε γενναιόδωρες τιμές (δεκάδες ή εκατοντάδες megabyte) και ορίστε σωστά net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (ελάχιστη, προεπιλεγμένη τιμή και μέγιστη) επιτρέπει σε κάθε υποδοχή να έχει το χώρος που απαιτείται για την απορρόφηση των κραδασμών της κυκλοφορίας χωρίς να εμπίπτει σε τεχνητούς περιορισμούς που επιβάλλονται από πολύ συντηρητικές εργοστασιακές αξίες.
Ένα άλλο βασικό σημείο είναι το μέγεθος των ουρών σύνδεσης. Παράμετροι όπως net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Αυτά τα όρια καθορίζουν πόσες εκκρεμείς συνδέσεις μπορεί να χειριστεί το σύστημα πριν από την απόρριψη πακέτων ή την απόρριψη handshakes. Σε διακομιστές ιστού με υψηλή επισκεψιμότητα, η αύξηση αυτών των ορίων μπορεί να αποτρέψει τις κορεσμένες ουρές και να μειώσει δραστικά το φόρτο εργασίας. σφάλματα σύνδεσης κατά τη διάρκεια των φορτίων αιχμής.
Η συμπεριφορά των συνδέσεων TCP μπορεί επίσης να βελτιστοποιηθεί με μια πληθώρα επιλογών: ενεργοποίηση net.ipv4.tcp_window_scaling Για να υποστηρίξετε μεγάλα παράθυρα σε συνδέσμους υψηλού εύρους ζώνης, ενεργοποιήστε net.ipv4.tcp_sack y net.ipv4.tcp_timestamps για τη βελτίωση της διαχείρισης απωλειών και αναμετάδοσης ή για την προσαρμογή net.ipv4.tcp_fin_timeout και η διαχείριση του TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) προκειμένου να ελέγχεται η κατανάλωση πόρων σε διακομιστές με εκατομμύρια σύντομες συνδέσεις ανά λεπτό.
Η επιλογή του αλγορίθμου ελέγχου συμφόρησης έχει επίσης σημασία. cubic Παραμένει η προεπιλεγμένη τιμή σε πολλές διανομές, αλλάζοντας σε bbr στους σύγχρονους πυρήνες (4.9 και νεότερες) από net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Μπορεί να πολλαπλασιάσει την απόδοση TCP σε περιβάλλοντα με πολύπλοκες απώλειες ή καθυστερήσεις, επιτυγχάνοντας βελτιώσεις μεταξύ 2 και 25 φορές σε σύγκριση με τις κλασικές διαμορφώσεις σε ορισμένα σενάρια, με κόστος... κάπως διαφορετική συμπεριφορά σε υπερφορτωμένα δίκτυα.
Δεν πρέπει να ξεχνάμε παραμέτρους ασφάλειας και αξιοπιστίας όπως net.ipv4.tcp_syncookies, η διαχείριση των ανακατευθύνσεων (net.ipv4.conf.all.accept_redirects, send_redirects) ή φιλτράρισμα σε γέφυρες (net.bridge.bridge-nf-call-iptables σε περιβάλλοντα Kubernetes). Με σωστή διαμόρφωση, σας επιτρέπουν να προστατεύετε το σύστημα από συνηθισμένες επιθέσεις (SYN flood, spoofing, κ.λπ.) χωρίς να θυσιάζετε ένα σταθερή απόδοση δικτύουΓια έναν πρακτικό οδηγό σχετικά με τους κανόνες και την ανίχνευση, ανατρέξτε στο Υλοποίηση Netfilter και Suricata.
Σύστημα αρχείων, περιγραφείς και καθολικά όρια: fs.* και ulimit
Στους σύγχρονους διακομιστές, ένα χαμηλό όριο περιγραφέα αρχείων είναι ο γρηγορότερος τρόπος για να διακοπεί η λειτουργία ενός συστήματος κατά τις ώρες αιχμής. Όταν ένας διακομιστής ιστού, ένας αντίστροφος διακομιστής μεσολάβησης ή μια βάση δεδομένων αντιμετωπίζει το κλασικό σφάλμα "πάρα πολλά ανοιχτά αρχεία", αυτό συμβαίνει συνήθως επειδή οι παράμετροι του πυρήνα και τα όρια χρήστη δεν έχουν κλιμακωθεί για το πραγματικό φορτίο.
Σε παγκόσμιο επίπεδο, fs.file-max Αυτό καθορίζει πόσους περιγραφείς μπορεί να έχει ανοιχτούς συνολικά ο πυρήνας. Για εφαρμογές με χιλιάδες ταυτόχρονες συνδέσεις, είναι σύνηθες να αυξάνεται αυτή η τιμή σε αρκετά εκατομμύρια, μαζί με μια αύξηση κατά fs.nr_openτο οποίο καθορίζει το αυστηρό όριο για τους περιγραφείς ανά διεργασία. Επιπλέον, απαιτούνται προσαρμογές. /etc/security/limits.conf έτσι ώστε οι χρήστες (ή οι υπηρεσίες που διαχειρίζεται το systemd) να έχουν μαλακές και σκληρές τιμές συμβατές με τη διαμόρφωση του πυρήνα.
Το υποσύστημα inotify, που χρησιμοποιείται ευρέως από IDE, εργαλεία ανάπτυξης ιστοσελίδων και συστήματα παρακολούθησης αρχείων, ελέγχεται από παραμέτρους όπως fs.inotify.max_user_watches y fs.inotify.max_user_instancesΕάν αντιμετωπίσετε σφάλματα που σχετίζονται με προγράμματα παρακολούθησης ή διεργασίες που σταματούν την παρακολούθηση των αλλαγών στο δίσκο, πιθανώς χρειάζεστε Αυξήστε αυτά τα όρια για να αποφύγετε σιωπηλά σημεία συμφόρησης.
Ένα άλλο σχετικό χαρακτηριστικό είναι η ασύγχρονη είσοδος/έξοδος (AIO), της οποίας το συνολικό μέγιστο ορίζεται με fs.aio-max-nrΣε εφαρμογές που βασίζονται σε μεγάλο βαθμό σε ασύγχρονη είσοδο/έξοδο (ορισμένες μηχανές βάσεων δεδομένων, συστήματα ουρών αναμονής κ.λπ.), η αύξησή της αποτρέπει την εξάντληση των υποδοχών για λειτουργίες AIO στον πυρήνα υπό τεράστιο φόρτο αιτημάτων.
Εκτός από αυτές τις παραμέτρους, η απόδοση του υποσυστήματος δίσκου επηρεάζεται από το Χρονοπρογραμματιστής Εισόδου/Εξόδου διαμορφωμένο σε κάθε συσκευή μπλοκ. Σε συστήματα με SSD ή NVMe, συνήθως συνιστάται η χρήση ελαφρών χρονοπρογραμματιστών όπως none o mq-deadline, ενώ σε μηχανικούς δίσκους άλλες επιλογές μπορεί να έχουν νόημα, όπως bfq ανάλογα με τον τύπο φορτίου. Προσαρμόστε τον προγραμματιστή μέσω /sys/block/<disco>/queue/scheduler και βελτιστοποίηση επιλογών όπως το βάθος ουράς (nr_requests) ή το read_ahead_kb μπορεί να κάνει μια αισθητή διαφορά στο καθυστέρηση ανάγνωσης/εγγραφής και απόδοσηΕίναι επίσης σημαντικό να λάβετε υπόψη ποια συστήματα αρχείων και προγράμματα οδήγησης χρησιμοποιούνται. Για παράδειγμα, άρθρα σχετικά με NTFSplus σε Linux και άλλα συστήματα μπορούν να βοηθήσουν κατά τον σχεδιασμό ετερογενών φορτίων.
Τέλος, δεν πρέπει να ξεχνάμε ότι αυτοί οι περιορισμοί του πυρήνα πρέπει να συμβαδίζουν με τις διαμορφώσεις του συστήματος όπως αυτές του ulimit και συστημικές μονάδες, για να διασφαλιστεί ότι οι υπηρεσίες μπορούν πραγματικά να χρησιμοποιήσουν τους καθορισμένους πρόσθετους πόρους και δεν εμποδίζονται από περιορισμοί στα ανώτερα στρώματα.
Γενικά για τον πυρήνα, NUMA, συγγένεια CPU και τεράστιες σελίδες
Πέρα από τη δικτύωση, τη μνήμη και τα συστήματα αρχείων, ο ίδιος ο πυρήνας προσφέρει μια σειρά από επιλογές ρύθμισης που επηρεάζουν τον τρόπο προγραμματισμού των διεργασιών, τον τρόπο κατανομής των φόρτων εργασίας μεταξύ των πυρήνων και των κόμβων NUMA και τον τρόπο διαχείρισης της μνήμης σε μεγάλη κλίμακα. Σε σύγχρονα μηχανήματα με πολλούς πυρήνες, ακόμη και πολλαπλές υποδοχές, αυτές οι λεπτομέρειες συχνά κάνουν τη διαφορά μεταξύ ενός ισορροπημένου διακομιστή και ενός με ορισμένους πυρήνες κορεσμένους, ενώ άλλοι υποχρησιμοποιούνται . Αξίζει επίσης να εξερευνήσετε εναλλακτικούς πυρήνες, όπως ο πυρήνας Liquorix, σε περιβάλλοντα όπου επιθυμείτε διαφορετικό προφίλ καθυστέρησης.
Παράμετροι όπως kernel.pid_max Καθορίζουν το μέγιστο εύρος των ID διεργασιών που μπορεί να αντιστοιχίσει το σύστημα, κάτι που είναι σημαντικό για κόμβους που εκτελούν μεγάλο αριθμό κοντέινερ ή εφήμερες διεργασίες. Προσαρμογή επιλογών καταγραφής πυρήνα (kernel.printk) βοηθά στη μείωση του υπερβολικού θορύβου στο dmesg ενώ παράλληλα καταγράφει κρίσιμα συμβάντα, τα οποία επηρεάζουν έμμεσα και το διαγνωστική ικανότητα και σταθερότητα.
Όσον αφορά την τοπολογία μνήμης, η παράμετρος kernel.numa_balancing Ελέγχει τον βαθμό στον οποίο ο πυρήνας μετακινεί αυτόματα σελίδες μεταξύ κόμβων NUMA. Η απενεργοποίησή του σε ορισμένα περιβάλλοντα επιτρέπει πιο σαφή διαχείριση της συγγένειας διεργασιών και μνήμης, χρησιμοποιώντας εργαλεία όπως numactl για να διασφαλιστεί ότι οι διεργασίες που απαιτούν μεγάλη χρήση CPU και RAM παραμένουν στον ίδιο κόμβο, μειώνοντας το καθυστέρηση που προκύπτει από απομακρυσμένη πρόσβασηΓια να κατανοήσουμε καλύτερα την αλληλεπίδραση μεταξύ υλικού και προγραμματισμού πυρήνα, είναι επίσης χρήσιμο να εξετάσουμε τεχνολογίες όπως Διευθυντής Νημάτων της Intel.
Οι τεράστιες σελίδες (vm.nr_hugepagesΑυτά είναι ένα άλλο βασικό στοιχείο σε συστήματα βάσεων δεδομένων ή άλλα φόρτα εργασίας που χειρίζονται μεγάλες περιοχές συνεχόμενης μνήμης. Η δέσμευση ενός κατάλληλου αριθμού γιγάντιων σελίδων (2 MB ή ακόμα και 1 GB, ανάλογα με την αρχιτεκτονική) μπορεί να μειώσει την επιβάρυνση TLB και να βελτιώσει σημαντικά την απόδοση των εφαρμογών που εκτελούνται. πολλές λειτουργίες σε μεγάλα μπλοκ μνήμηςΓια να είναι αυτό αποτελεσματικό, η διαμόρφωση του πυρήνα πρέπει να συντονιστεί με την ίδια την εφαρμογή, έτσι ώστε να χρησιμοποιεί ρητά αυτήν τη μνήμη.
Στον τομέα της καθυστέρησης και του χρονοπρογραμματισμού, υπάρχουν παράμετροι χρονοπρογραμματιστή όπως kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsΑυτές οι ρυθμίσεις βελτιώνουν το μέγεθος των "κομματιών" της CPU που έχουν εκχωρηθεί σε κάθε εργασία και την επιθετικότητα με την οποία ο πυρήνας μετακινεί τις διεργασίες μεταξύ των πυρήνων. Μικρότερες τιμές αντιπροσωπεύουν ένα πιο προληπτικό σύστημα, το οποίο τείνει να προσφέρει καλύτερη απάντηση για διαδραστικές εργασίες με κόστος, μερικές φορές, μιας μικρής ακατέργαστης απόδοσης.
Σε συστήματα όπου η μνήμη είναι ένας ευαίσθητος πόρος, ορισμένοι διαχειριστές επιλέγουν να ενεργοποιήσουν τη λειτουργία πανικού σε περίπτωση σφάλματος που εμφανίζεται αμέσως μετά την εγκατάσταση (vm.panic_on_oom) και καθιερώστε kernel.panic με αυτόματο χρόνο επανεκκίνησης. Αυτή η στρατηγική, αν και κάπως δραστική, μπορεί να είναι χρήσιμη σε περιβάλλοντα υψηλής διαθεσιμότητας όπου Μια γρήγορη και ελεγχόμενη επανεκκίνηση είναι προτιμότερη από έναν κολλημένο και ασταθή κεντρικό υπολογιστή. κατά τη διάρκεια ωρών.
Εξειδικευμένα προφίλ: ιστός, βάσεις δεδομένων, χαμηλή καθυστέρηση και Kubernetes
Αντί να εφαρμόσετε μία μόνο μαγική συμβουλή, είναι πιο αποτελεσματικό να δημιουργήσετε προφίλ sysctl προσαρμοσμένα σε διαφορετικούς τύπους φόρτων εργασίας: διακομιστές ιστού, βάσεις δεδομένων, πλατφόρμες κοντέινερ ή συστήματα χαμηλής καθυστέρησης. Η κατανομή αυτών των ρυθμίσεων σε αρχεία όπως 99-webserver.conf, 99-database.conf o 90-kubernetes.conf βοηθήσει να διατηρήστε μια οργανωμένη και εύκολη στην έκδοση διαμόρφωσηΜπορείτε επίσης να εξετάσετε διανομές και εκδόσεις προσανατολισμένες στην απόδοση, όπως Έκδοση διακομιστή CachyOS για πολύ συγκεκριμένα περιβάλλοντα.
Για τους διακομιστές ιστού (Nginx, Apache, proxies, κ.λπ.), το βασικό είναι να χειρίζονται μεγάλους όγκους ταυτόχρονων συνδέσεων με μεγάλες ουρές και χρόνους απόκρισης. FIN_WAIT Με βελτιστοποίηση, εκτεταμένο εύρος προσωρινών θυρών και πολύ υψηλά όρια περιγραφέων, είναι σύνηθες να μεταβαίνουν από μερικές εκατοντάδες αιτήματα HTTP ανά δευτερόλεπτο σε αρκετές χιλιάδες, μειώνοντας τη μέση καθυστέρηση και εξαλείφοντας τα σφάλματα. κορεσμένες ουρές ή γεμάτες θύρες.
Από την πλευρά της βάσης δεδομένων (MySQL, PostgreSQL και παρόμοιες), δίνεται προτεραιότητα στην ελάχιστη χρήση swap, στη βελτιστοποίηση της εγγραφής dirty page και στις κατάλληλες ρυθμίσεις κοινόχρηστης μνήμης και σηματοφορέα για τη μηχανή. Παράμετροι όπως kernel.shmmax, kernel.shmall, kernel.sem και η τεράστια διαμόρφωση σελίδων κάνει τη διαφορά όσον αφορά συναλλαγές ανά δευτερόλεπτο και χρόνος απόκρισης, πολλαπλασιάζοντας την απόδοση επί δύο ή τρία σε σύγκριση με τις προεπιλεγμένες τιμές σε πολλά σενάρια.
Για εφαρμογές με εξαιρετικά χαμηλή καθυστέρηση (trading, online gaming, επεξεργασία σε πραγματικό χρόνο), προστίθενται ακόμη πιο συγκεκριμένες ρυθμίσεις: net.ipv4.tcp_low_latency, απενεργοποίηση αργής εκκίνησης μετά από αδράνεια, χρήση tcp_fastopen, παράμετροι δημοσκόπησης απασχολημένου (net.core.busy_poll, busy_read) και, σε πολλές περιπτώσεις, η απενεργοποίηση διαφανών τεράστιων σελίδων μέσω /sys/kernel/mm/transparent_hugepage/enabledΌλα αυτά έχουν ως στόχο τη μείωση του η ουρά επεξεργασίας και η καθυστέρηση κορυφώνονται σε υψηλά ποσοστά, επιτυγχάνοντας θεαματικές βελτιώσεις στο P99.
Σε περιβάλλοντα container και Kubernetes, η στοίβα δικτύου και η παρακολούθηση συνδέσεων υπόκεινται σε ιδιαίτερη πίεση. Παράμετροι όπως net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxΗ χρήση δεσμευμένων θυρών για το NodePort ή η προσαρμογή πινάκων ARP είναι συνηθισμένη σε κόμβους που χειρίζονται εκατοντάδες ή χιλιάδες pods. Η σωστή προσαρμογή τους αποτρέπει προβλήματα. περικομμένες συνδέσεις, χρονικά όρια ή κορεσμός πίνακα με conntrack.
Εκτός από αυτά τα συγκεκριμένα προφίλ, ορισμένοι οργανισμοί επιλέγουν ένα αρχείο που εστιάζει στην απόδοση με βελτιωμένη ασφάλεια, συνδυάζοντας μεγάλα buffer δικτύου και μειωμένη εναλλαγή με μέτρα όπως tcp_syncookies ή το μπλοκάρισμα επικίνδυνων ανακατευθύνσεων. Στόχος είναι η επίτευξη ενός σημείο ισορροπίας μεταξύ επιθετικής απόδοσης και λογικής σκλήρυνσης.
Εργαλεία δημιουργίας προφίλ και παρακολούθησης πυρήνα
Η ρύθμιση του πυρήνα χωρίς μέτρηση είναι σαν να παίζετε έναν μίκτη ήχου με δεμένα μάτια. Το Linux προσφέρει ένα οπλοστάσιο εργαλείων για να κατανοήσετε τι κάνει στην πραγματικότητα το σύστημα, από απλούς μετρητές έως λεπτομερή ίχνη των συναρτήσεων του πυρήνα, επιτρέποντάς σας να συσχετίσετε τις αλλαγές διαμόρφωσης με μετρήσιμα αποτελέσματα.
Μεταξύ των καθημερινών υπηρεσιών κοινής ωφέλειας είναι vmstat, iostat, sar, ss, slabtop, htop o pidstatτα οποία παρέχουν γρήγορες πληροφορίες σχετικά με τις διεργασίες, την CPU, τις εισόδους/εξόδους, τις υποδοχές και τη χρήση της προσωρινής μνήμης. Σε συνδυασμό με αρχεία καταγραφής συστήματος και μετρήσεις που εξάγονται στο Prometheus, το Grafana ή το collectd, και με πόρους όπως προηγμένη οθόνη συστήματος για LinuxΔίνουν μια αρκετά πλήρη εικόνα για το πώς συμπεριφέρεται ο παρουσιαστής πριν και μετά από κάθε κούρδισμα.
Για να εμβαθύνουμε περισσότερο, εργαλεία όπως perf Επιτρέπουν την καταγραφή της χρήσης της CPU σε επίπεδο λειτουργίας, τόσο χρήστη όσο και πυρήνα, καταγράφοντας συμβάντα για λίγα δευτερόλεπτα ή λεπτά και στη συνέχεια παρέχοντας μια διαδραστική αναφορά. perf stat, perf record y perf report μπορείτε να δείτε πού καταναλώνεται στην πραγματικότητα ο χρόνος της CPU και ποιο μέρος αντιστοιχεί στον πυρήνα, εντοπίζοντας, για παράδειγμα, μια καταιγίδα διακοπών ή έναν κακώς προσαρμοσμένο προγραμματιστή.
Αν χρειάζεστε ακόμη μεγαλύτερη λεπτομέρεια, ftrace Το υποσύστημα ιχνηλάτησης του πυρήνα προσφέρει τη δυνατότητα ενεργοποίησης συγκεκριμένων ιχνηθετών (για παράδειγμα, της συνάρτησης tracer) και εξέτασης σε πραγματικό χρόνο ή μετά θάνατον ποιες κλήσεις πραγματοποιούνται. Ενεργοποίηση του κατάλληλου ιχνηθέτη και ανάλυση του περιεχομένου του /sys/kernel/debug/tracing/trace σου αποκαλύπτει hotspots μέσα στον ίδιο τον πυρήναΑυτό είναι πολύ χρήσιμο όταν οι μετρήσεις υψηλού επιπέδου δεν επαρκούν.
Παράλληλα, συνιστάται η εφαρμογή αυτοματοποιημένων σεναρίων παρακολούθησης που καταχωρούν περιοδικά βασικά δεδομένα (στατιστικά δικτύου, μετρητές μνήμης, αριθμό ανοιχτών περιγραφέων αρχείων κ.λπ.) σε εναλλασσόμενα αρχεία καταγραφής. Μόλις επιτευχθούν ορισμένα όρια (για παράδειγμα, υπέρβαση ενός καθορισμένου αριθμού ανοιχτών περιγραφέων αρχείων), αυτά τα σενάρια μπορούν να δημιουργήσουν ειδοποιήσεις μέσω email ή άλλων καναλιών, βοηθώντας στην ανίχνευση επικίνδυνων τάσεων πριν κλιμακωθεί ένα πρόβλημα.
Τέλος, σε παρατεταμένες φάσεις δοκιμών αντοχής (24 ώρες ή περισσότερο), εργαλεία όπως stress-ng σε συνδυασμό με τη συνεχή συλλογή μετρήσεων (μέσω vmstat, iostat, sar) σας επιτρέπουν να αξιολογήσετε τη σταθερότητα του συστήματος με τη νέα διαμόρφωση πυρήνα, επαληθεύοντας ότι δεν υπάρχουν συμβάντα OOM, διακοπές λειτουργίας, απροσδόκητες επανεκκινήσεις ή προοδευτική υποβάθμιση της απόδοσης υπό παρατεταμένο φόρτο.
Η βελτιστοποίηση του πυρήνα Linux με sysctl και άλλους μηχανισμούς δεν είναι μια εφάπαξ εργασία, αλλά μάλλον μια επαναληπτική διαδικασία που περιλαμβάνει τη μέτρηση αποτελεσμάτων, την προσαρμογή παραμέτρων και την σχολαστική καταγραφή των πάντων. Με μια σαφή μεθοδολογία, συγκεκριμένα προφίλ για κάθε τύπο φόρτου εργασίας, μια ισχυρή σουίτα εργαλείων δημιουργίας προφίλ και αυστηρό έλεγχο αλλαγών, είναι δυνατό να επιτευχθούν διακομιστές που αξιοποιούν πλήρως το υλικό τους, με αυξημένη απόδοση, μειωμένη καθυστέρηση και σημαντικά μεγαλύτερη σταθερότητα από τη γενική εργοστασιακή διαμόρφωση.
Δείκτης
- 1 Τι είναι το sysctl και πώς οργανώνει τις παραμέτρους του πυρήνα;
- 2 Μετρήστε πριν αγγίξετε: σημεία αναφοράς και βασική τιμή συστήματος
- 3 Προηγμένες ρυθμίσεις μνήμης: vm.*
- 4 Προηγμένη βελτιστοποίηση δικτύου: net.* και TCP/IP
- 5 Σύστημα αρχείων, περιγραφείς και καθολικά όρια: fs.* και ulimit
- 6 Γενικά για τον πυρήνα, NUMA, συγγένεια CPU και τεράστιες σελίδες
- 7 Εξειδικευμένα προφίλ: ιστός, βάσεις δεδομένων, χαμηλή καθυστέρηση και Kubernetes
- 8 Εργαλεία δημιουργίας προφίλ και παρακολούθησης πυρήνα


