Ρύθμιση του χρονοπρογραμματιστή I/O του Linux: mq-deadline, none και BFQ

Ο χρονοπρογραμματιστής I/O του Linux αποφασίζει τη σειρά με την οποία οι αιτήσεις ανάγνωσης και εγγραφής φτάνουν στη συσκευή αποθήκευσης σας, και η σωστή επιλογή εξαρτάται σχεδόν εξ ολοκλήρου από το υλικό σας. Χρησιμοποιήστε none για NVMe, mq-deadline για SSD SATA και HDD που εκτελούν μικτά φορτία εργασίας, και bfq όταν πρέπει να εμποδίσετε μια διαδικασία να στερεί πόρους από τις άλλες. Αυτός ο οδηγός καλύπτει τον τρόπο λειτουργίας των τριών κύριων χρονοπρογραμματιστών, τον τρόπο αντιστοίχισης ενός με το φορτίο εργασίας σας και τον τρόπο ρύθμισης και επαλήθευσης του αποτελέσματος.

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

Πώς διαφέρουν τα mq-deadline, none και BFQ

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

mq-deadline

Ο mq-deadline προγραμματιστής διασφαλίζει ότι κανένα αίτημα δεν περιμένει επ' αόριστον. Διατηρεί ξεχωριστές ταξινομημένες ουρές για αναγνώσεις και εγγραφές, ταξινομώντας τις κατά Λογική Διεύθυνση Μπλοκ (Logical Block Address) για να μειώσει τον χρόνο αναζήτησης, και επιβάλλει προθεσμίες: 500 ms για αναγνώσεις και 5 δευτερόλεπτα για εγγραφές από προεπιλογή. Όταν ένα αίτημα φτάσει στη προθεσμία του, μετακινείται στην αρχή της ουράς.

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

none

Ο none προγραμματιστής δεν κάνει σχεδόν τίποτα. Διαβιβάζει τα αιτήματα απευθείας στη συσκευή με σειρά First-In-First-Out, χωρίς αναδιάταξη, συγχώνευση ή ιεράρχηση. Αυτό ταιριάζει στις σύγχρονες μονάδες NVMe, οι οποίες διαχειρίζονται τις δικές τους εσωτερικές ουρές και μπορούν να παρακολουθούν δεκάδες χιλιάδες αιτήματα σε εξέλιξη ταυτόχρονα. Η κατάργηση του επιπέδου προγραμματισμού λογισμικού παρέχει τη συντομότερη δυνατή διαδρομή από την εφαρμογή στη συσκευή, κάτι που είναι ακριβώς αυτό που απαιτούν τα φορτία εργασίας NVMe υψηλής απόδοσης.

Το μειονέκτημα είναι ότι αυτό λειτουργεί μόνο όταν το υλικό μπορεί να προγραμματίσει έξυπνα από μόνο του. Σε HDD ή SSD SATA με μικρές ουρές, η παράλειψη της αναδιάταξης λογισμικού συνήθως επιδεινώνει την απόδοση, αντί να την βελτιώνει.

BFQ

Το BFQ (Budget Fair Queuing) δίνει προτεραιότητα στη δικαιοσύνη. Αντί για χρονικά διαστήματα, δίνει σε κάθε διαδικασία έναν προϋπολογισμό που μετράται σε τομείς δίσκου. Οι μεγάλες σειριακές αναγνώσεις λαμβάνουν μεγαλύτερους προϋπολογισμούς για να διατηρήσουν υψηλή απόδοση, ενώ οι εργασίες που είναι ευαίσθητες στην καθυστέρηση λαμβάνουν μικρότερους προϋπολογισμούς ώστε να εξυπηρετούνται γρήγορα, και ένας βρόχος ανατροφοδότησης προσαρμόζει τους προϋπολογισμούς καθώς εκτελείται.

Το BFQ διατηρεί τις διαδραστικές εργασίες ανταποκρινόμενες ακόμη και υπό βαρύ φορτίο, έτσι ώστε η αναπαραγωγή βίντεο ή μια ερώτηση βάσης δεδομένων να παραμένει ομαλή ενώ μια μεταφορά μεγάλου αρχείου εκτελείται στο παρασκήνιο. Αυτή η δικαιοσύνη κοστίζει CPU. Το επιπλέον κόστος ανά αίτημα είναι περίπου 1,9 μικροδευτερόλεπτα, περίπου τρεις φορές αυτό του mq-deadline, και σε έναν πιο αργό πυρήνα ARM αυτό το επιπλέον κόστος περιορίζει τη διακίνηση πολύ κάτω από αυτό που ο ίδιος προγραμματιστής επιτυγχάνει σε ένα γρήγορο τσιπ x86. Σε διακομιστές όπου η ακατέργαστη απόδοση και η αποδοτικότητα της CPU έχουν τη μεγαλύτερη σημασία, αυτή η ανταλλαγή είναι δύσκολο να δικαιολογηθεί.

Προσαρμογή ενός προγραμματιστή στο φόρτο εργασίας σας

Δύο παράγοντες καθορίζουν τον κατάλληλο προγραμματιστή: το υλικό αποθήκευσης και το πρότυπο πρόσβασης της εφαρμογής σας. Ξεκινήστε με το υλικό. Εάν η συσκευή αναδιατάσσει ήδη τα αιτήματα, όπως μια μονάδα NVMe με κατάλληλο υλικολογισμικό, ο προγραμματισμός μέσω λογισμικού προσθέτει μόνο επιπλέον φόρτο, οπότε none κερδίζει. Σε περιστρεφόμενους σκληρούς δίσκους, όπου κυριαρχεί ο χρόνος αναζήτησης, η αναδιάταξη μέσω λογισμικού μειώνει την καθυστέρηση, οπότε mq-deadline ή bfq είναι οι καλύτερες επιλογές. Οι SSD SATA βρίσκονται στο ενδιάμεσο: ταχύτεροι από τους σκληρούς δίσκους αλλά χωρίς τις βαθιές ουρές του NVMe, οπότε mq-deadline ταιριάζει.

Η ίδια λογική ισχύει όταν κάτι άλλο προγραμματίζει ήδη για εσάς. Οι εικονικές μηχανές επισκεπτών στο virtio-blk βασίζονται στον κεντρικό υπολογιστή για τον προγραμματισμό της εισόδου/εξόδου, και οι ελεγκτές RAID υλικού με cache write-back βελτιστοποιούν τη δική τους σειρά. Και στις δύο περιπτώσεις none αποφεύγεται η διπλή καταβολή για την εργασία.

Το πρότυπο πρόσβασης είναι ο δεύτερος παράγοντας. Μια βάση δεδομένων που εκτελεί χιλιάδες τυχαίες αναγνώσεις 4K ανά δευτερόλεπτο δεν έχει τίποτα κοινό με μια εργασία εκπαίδευσης που μεταδίδει μεγάλα διαδοχικά μπλοκ από μια συστοιχία NVMe, και χρειάζονται διαφορετικούς προγραμματιστές. Ο παρακάτω πίνακας αντιστοιχίζει κοινά φορτία εργασίας σε ένα σημείο εκκίνησης.

Υπάρχει μία εξαίρεση που αξίζει να επισημανθεί. Ακόμη και σε NVMe, αν η καθυστέρηση ουράς στο p99 ή p999 είναι η μέτρηση που σας ενδιαφέρει, όπως σε χρηματοοικονομικά συστήματα, mq-deadline μπορεί να νικήσει none επιβάλλοντας αυστηρές προθεσμίες και αποτρέποντας τις περιστασιακές καθυστερήσεις στις αιτήσεις.

Αλλαγή και ρύθμιση παραμέτρων προγραμματιστή

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

Αλλαγή του ενεργού χρονοπρογραμματιστή

Ελέγξτε τι είναι διαθέσιμο για μια συσκευή, όπου η τιμή σε παρένθεση είναι η ενεργή:

cat /sys/block/sda/queue/scheduler

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

echo bfq | sudo tee /sys/block/sda/queue/scheduler

Εάν bfq δεν περιλαμβάνεται στη λίστα, φορτώστε πρώτα το module:

sudo modprobe bfq

Για να κάνετε μια επιλογή μόνιμη, χρησιμοποιήστε έναν κανόνα udev αντί για την παλιά elevator= παράμετρο του πυρήνα, η οποία δεν αλλάζει πλέον τον προγραμματιστή στο RHEL 9 και σε παρόμοιες εκδόσεις. Αυτός ο κανόνας ορίζει mq-deadline για όλους τους μη περιστροφικούς δίσκους SCSI στο /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

Επαναφορτώστε και εφαρμόστε τον χωρίς επανεκκίνηση:

sudo udevadm control --reload-rules && sudo udevadm trigger

Σε συστήματα βασισμένα στο RHEL, τα προφίλ TuneD κάνουν την ίδια δουλειά μέσω προφίλ σε επίπεδο συστήματος αντί για κανόνες ανά συσκευή.

Παράμετροι που αξίζει να ρυθμιστούν

Κάθε χρονοπρογραμματιστής εκθέτει τις ρυθμίσεις του στο /sys/block/<device>/queue/iosched/. Για mq-deadline, οι προθεσμίες είναι οι κύριοι μοχλοί. Οι βάσεις δεδομένων που είναι ευαίσθητες στην καθυστέρηση σε SSD SATA επωφελούνται από μικρότερες προθεσμίες:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

Για bfq σε συστήματα υψηλής απόδοσης, η απενεργοποίηση των ευριστικών αλγορίθμων καθυστέρησης αυξάνει την απόδοση:

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

Για κοινόχρηστη φιλοξενία, το BFQ συνδυάζεται καλά με τα cgroups v2. Η εκχώρηση io.weight τιμών σας επιτρέπει να δώσετε σε μια διαδικασία βάσης δεδομένων δέκα φορές το μερίδιο I/O μιας εργασίας δημιουργίας αντιγράφων ασφαλείας, για παράδειγμα, έτσι ώστε η εργασία στο παρασκήνιο να μην επισκιάζει την διαδραστική κίνηση. Ό,τι και αν αλλάξετε, το υψηλότερο κόστος ανά αίτημα του BFQ συσσωρεύεται σε συστήματα που εξαρτώνται από την CPU και έχουν υψηλό IOPS, οπότε κάντε δοκιμές απόδοσης πριν προχωρήσετε.

Επαλήθευση της απόδοσης μετά τη ρύθμιση

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

Το fio είναι το τυπικό εργαλείο για αυτό. Αναπαράγει συγκεκριμένα μοτίβα φόρτου εργασίας μέσω του μεγέθους μπλοκ, του βάθους ουράς και των ρυθμίσεων του μηχανισμού I/O. Πάντα να περνάτε --direct=1 ώστε να παρακάμπτει την προσωρινή μνήμη σελίδων και να μετρά απευθείας τον προγραμματιστή και τη συσκευή αντί για τις αποθηκευμένες αναγνώσεις. Προσαρμόστε τη δοκιμή στο πραγματικό φορτίο εργασίας:

Εκτελέστε την ίδια δοκιμή σε iodepth τιμές από 1 έως 256 για να βρείτε το σημείο κορεσμού της συσκευής, το βάθος στο οποίο οι IOPS σταματούν να αυξάνονται και η καθυστέρηση κορυφώνεται. Για ζωντανή παρακολούθηση μετά από μια αλλαγή, iostat -x 1 αναφέρετε τις μετρήσεις που έχουν σημασία: r_await και w_await για την καθυστέρηση ολοκλήρωσης ανάγνωσης και εγγραφής, aqu-sz για το μέσο βάθος ουράς, και %util για τη χρήση της συσκευής. Όταν %util βρίσκεται κοντά στο 100 τοις εκατό, το υλικό αποτελεί το όριο και καμία αλλαγή στον προγραμματιστή δεν θα βοηθήσει.

Για να διαχωρίσετε το κόστος λογισμικού από το κόστος υλικού, εκτελέστε το blktrace με το btt. Διαχωρίζει την καθυστέρηση σε Q2D, τον χρόνο που δαπανάται στην ουρά λογισμικού, και D2C, τον χρόνο που χρειάζεται η συσκευή για να εξυπηρετήσει το αίτημα. Εάν κυριαρχεί το Q2D, ο προγραμματιστής είναι το σημείο συμφόρησης. Εάν κυριαρχεί το D2C, το υλικό είναι.

Ένα πράγμα που πρέπει να έχετε κατά νου όταν διαβάζετε τα αποτελέσματα: η επιλογή του χρονοπρογραμματιστή διαμορφώνει κυρίως την ουρά της κατανομής της καθυστέρησης, όχι τη διάμεση τιμή. Η αλλαγή από none σε mq-deadline στο NVMe μπορεί να αυξήσει τη μέση καθυστέρηση κατά μερικά μικροδευτερόλεπτα, ενώ μειώνει την καθυστέρηση p99 και p999 κατά το ήμισυ. Για υπηρεσίες που απευθύνονται σε χρήστες και δεσμεύονται από SLA, αυτή η ανταλλαγή αξίζει σχεδόν πάντα τον κόπο, γι' αυτό και η μέτρηση της καθυστέρησης στην ουρά, και όχι της μέσης απόδοσης, είναι ο σκοπός της άσκησης.

Επιλογή του σωστού προγραμματιστή

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

• NVMe: χρησιμοποιήστε none και αφήστε το firmware να αναλάβει τη διαχείριση της ουράς.
• SSD SATA και HDD με μικτή I/O: χρησιμοποιήστε mq-deadline για προβλέψιμη καθυστέρηση.
• Κοινόχρηστοι ή πολυ-ενοικιαζόμενοι κεντρικοί υπολογιστές: χρησιμοποιήστε bfq για να αποτρέψετε ένα φορτίο εργασίας από το να στερεί πόρους από τα υπόλοιπα.
• Παρακολουθήστε την καθυστέρηση ουράς, όχι τη μέση τιμή: οι αλλαγές του χρονοπρογραμματιστή εμφανίζονται στα p99 και p999, οπότε αυτά πρέπει να μετρήσετε.
• Κάντε το μόνιμο: χρησιμοποιήστε κανόνες udev ή TuneD, ποτέ την elevator= .

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