Μεταγραφή της αναφοράς του 2015 από τον Ilya Kosmodemyansky "Συντονισμός Linux για τη βελτίωση της απόδοσης PostgreSQL"
Αποποίηση ευθύνης: Σημειώνω ότι αυτή η αναφορά έχει ημερομηνία Νοεμβρίου 2015 - έχουν περάσει περισσότερα από 4 χρόνια και έχει περάσει πολύς χρόνος. Η έκδοση 9.4 που συζητείται στην αναφορά δεν υποστηρίζεται πλέον. Τα τελευταία 4 χρόνια, υπήρξαν 5 νέες εκδόσεις PostgreSQL και 15 εκδόσεις του πυρήνα Linux. Αν ξαναγράψετε αυτά τα μέρη, θα καταλήξετε με διαφορετική αναφορά. Αλλά εδώ είναι ένας θεμελιώδης συντονισμός Linux για την PostgreSQL, ο οποίος εξακολουθεί να είναι επίκαιρος σήμερα.
Το όνομά μου είναι Ilya Kosmodemyansky. Εργάζομαι για την PostgreSQL-Consulting εταιρεία. Και τώρα θα μιλήσω λίγο για το τι πρέπει να κάνουμε με το Linux σε σχέση με τις βάσεις δεδομένων γενικά και την PostgreSQL ειδικότερα, γιατί οι αρχές είναι αρκετά παρόμοιες.
Τι θα συζητηθεί; Εάν έχετε να κάνετε με PostgreSQL, τότε θα πρέπει να είστε διαχειριστής UNIX σε κάποιο βαθμό. Τι σημαίνει? Αν συγκρίνουμε Oracle και PostgreSQL, τότε στην Oracle πρέπει να είστε 80% διαχειριστής βάσης δεδομένων DBA και 20% διαχειριστής Linux.
Το PostgreSQL είναι λίγο πιο δύσκολο. Με το PostgreSQL, πρέπει να έχετε μια πολύ καλύτερη ιδέα για το πώς λειτουργεί το Linux. Και ταυτόχρονα, τρέξτε λίγο μετά την ατμομηχανή, γιατί τον τελευταίο καιρό όλα έχουν ενημερωθεί πολύ ωραία. Και βγαίνουν νέοι πυρήνες και εμφανίζονται νέα λειτουργικότητα, βελτιώνεται η απόδοση κ.λπ.
Γιατί μιλάμε για Linux; Καθόλου γιατί βρισκόμαστε στο συνέδριο του Linux Peter, αλλά γιατί στις σύγχρονες συνθήκες ένα από τα πιο δικαιολογημένα λειτουργικά συστήματα για λειτουργία με βάσεις δεδομένων γενικά και με PostgreSQL ειδικότερα είναι το Linux. Επειδή το FreeBSD, δυστυχώς, αναπτύσσεται σε μια πολύ περίεργη κατεύθυνση. Και θα υπάρξουν προβλήματα τόσο με την απόδοση όσο και με πολλά άλλα πράγματα. Η απόδοση της PostgreSQL στα Windows είναι γενικά ένα ξεχωριστό σκληρό θέμα, στηριζόμενο στο γεγονός ότι τα Windows δεν διαθέτουν κοινή μνήμη όπως το UNIX και το PostgreSQL έχει να κάνει με αυτήν την επιχείρηση, επειδή είναι ένα σύστημα πολλαπλών διεργασιών.
Και τα εξωτικά όπως το Solaris, νομίζω, ενδιαφέρουν λιγότερο όλους, οπότε πάμε.
Μια σύγχρονη διανομή Linux έχει πάνω από 1 επιλογές syctl, ανάλογα με τον τρόπο κατασκευής του πυρήνα. Ταυτόχρονα, αν κοιτάξουμε διαφορετικούς ξηρούς καρπούς, τότε μπορεί να υπάρχουν ακόμα πολλοί τρόποι για να προσαρμόσουμε κάτι. Υπάρχουν επιλογές συστήματος αρχείων σχετικά με τον τρόπο προσάρτησης. Εάν έχετε ερωτήσεις σχετικά με το πώς να ξεκινήσετε: τι να ενεργοποιήσετε στο BIOS, πώς να ρυθμίσετε τις παραμέτρους του υλικού κ.λπ.
Αυτός είναι ένας πολύ μεγάλος τόμος, για τον οποίο μπορούμε να μιλήσουμε για αρκετές ημέρες, και όχι σε μια σύντομη αναφορά, αλλά τώρα θα επικεντρωθώ σε σημαντικά πράγματα, πώς να αποφύγετε αυτές τις τσουγκράνες που δεν θα σας επιτρέψουν να λειτουργήσετε καλά μια βάση δεδομένων στο Linux εάν δεν τα φτιάχνεις.. Και ταυτόχρονα, ένα σημαντικό σημείο είναι ότι πολλές προεπιλεγμένες παράμετροι δεν περιλαμβάνονται στις ρυθμίσεις που είναι σωστές για τη βάση δεδομένων. Δηλαδή από προεπιλογή θα δουλεύει άσχημα ή δεν θα λειτουργεί καθόλου.
Ποιοι είναι οι παραδοσιακοί στόχοι συντονισμού στο Linux; Νομίζω ότι αφού όλοι ασχολείστε με διαχείριση Linux, δεν χρειάζεται να εξηγήσετε ποιοι είναι οι στόχοι.
Μπορείτε να συντονιστείτε:
- CPU.
- Μνήμη.
- Αποθήκευση.
- άλλα. Θα μιλήσουμε για αυτό στο τέλος για ένα σνακ. Ακόμη, για παράδειγμα, ρυθμίσεις όπως η πολιτική εξοικονόμησης ενέργειας μπορεί να επηρεάσουν την απόδοση με πολύ απρόβλεπτο και όχι πολύ ευχάριστο τρόπο.
Ποιες είναι οι ιδιαιτερότητες της PostgreSQL και της βάσης δεδομένων γενικότερα; Το πρόβλημα είναι ότι δεν μπορείτε να τροποποιήσετε κάποιο συγκεκριμένο παξιμάδι και να δείτε ότι η απόδοσή μας έχει βελτιωθεί πολύ.
Ναι, υπάρχουν τέτοια gadget, αλλά η βάση δεδομένων είναι πολύπλοκο πράγμα. Αλληλεπιδρά με όλους τους πόρους που διαθέτει ο διακομιστής και προτιμά να αλληλεπιδρά πλήρως. Αν κοιτάξετε τις τρέχουσες οδηγίες της Oracle σχετικά με τον τρόπο χρήσης ενός λειτουργικού συστήματος υποδοχής, είναι σαν το αστείο του Μογγολικού αστροναύτη - ταΐστε τον σκύλο και μην αγγίζετε τίποτα. Ας δώσουμε στη βάση δεδομένων όλους τους πόρους, η ίδια η βάση θα καταστρέψει τα πάντα.
Κατ 'αρχήν, σε κάποιο βαθμό, η κατάσταση είναι ακριβώς η ίδια με την PostgreSQL. Η διαφορά έγκειται στο γεγονός ότι η βάση δεν είναι επίσης σε θέση να πάρει όλους τους πόρους για τον εαυτό της, δηλαδή, κάπου σε επίπεδο Linux πρέπει να τα ταξινομήσετε όλα μόνοι σας.
Η κύρια ιδέα δεν είναι να επιλέξετε έναν μεμονωμένο στόχο και να αρχίσετε να τον συντονίζετε, για παράδειγμα, μνήμη, CPU ή κάτι τέτοιο, αλλά να αναλύσετε τον φόρτο εργασίας και να προσπαθήσετε να βελτιώσετε τη διεκπεραίωση όσο το δυνατόν περισσότερο, έτσι ώστε το φορτίο που δημιούργησαν οι καλοί προγραμματιστές εμάς, συμπεριλαμβανομένων των χρηστών μας.
Εδώ είναι μια εικόνα για να εξηγήσει τι είναι. Υπάρχει μια προσωρινή μνήμη του λειτουργικού συστήματος Linux και υπάρχει κοινόχρηστη μνήμη και υπάρχουν κοινόχρηστα buffer PostgreSQL. Η PostgreSQL, σε αντίθεση με την Oracle, λειτουργεί απευθείας μόνο μέσω του buffer του πυρήνα, δηλαδή, για να μπει μια σελίδα από το δίσκο στην κοινόχρηστη μνήμη της, πρέπει να περάσει από το buffer του πυρήνα και να επιστρέψει ακριβώς την ίδια κατάσταση.
Οι δίσκοι ζουν κάτω από αυτό το σύστημα. Το σχεδίασα ως δίσκους. Μάλιστα, μπορεί να υπάρχει ελεγκτής RAID κ.λπ.
Και αυτή η είσοδος-έξοδος με τον ένα ή τον άλλο τρόπο συμβαίνει μέσω αυτής της περίπτωσης.
Η PostgreSQL είναι μια κλασική βάση δεδομένων. Είναι μέσα στη σελίδα. Και όλα τα δεδομένα εισόδου-εξόδου γίνονται με τη βοήθεια σελίδων. Ανεβάζουμε μπλοκ στη μνήμη ανά σελίδες. Και αν δεν συνέβαινε τίποτα, απλώς τα διαβάζουμε, μετά σταδιακά βυθίζονται από αυτήν την κρυφή μνήμη, από κοινόχρηστα buffer και επιστρέφουν στο δίσκο.
Αν έχουμε αντικαταστήσει κάτι κάπου, τότε ολόκληρη η σελίδα μας επισημαίνεται ως βρώμικη. Τα σημείωσα με μπλε εδώ. Και αυτό σημαίνει ότι αυτή η σελίδα πρέπει να συγχρονιστεί με μπλοκ αποθήκευσης. Δηλαδή όταν το λερώσαμε, κάναμε είσοδο στο WAL. Και σε κάποια ωραία χρονική στιγμή, ήρθε ένα φαινόμενο που ονομάζεται σημείο ελέγχου. Και αυτό το ημερολόγιο κατέγραψε πληροφορίες ότι ήρθε. Και αυτό σημαίνει ότι όλες οι βρώμικες σελίδες που βρίσκονταν εκεί εκείνη τη στιγμή σε αυτά τα κοινόχρηστα buffer συγχρονίστηκαν με τον δίσκο αποθήκευσης χρησιμοποιώντας fsync μέσω του buffer του πυρήνα.
Σε τι χρησιμεύει; Εάν χάναμε τάση, τότε δεν είχαμε την κατάσταση ότι χάθηκαν όλα τα δεδομένα. Η επίμονη μνήμη, για την οποία μας είπαν όλοι, βρίσκεται μέχρι στιγμής στη θεωρία της βάσης δεδομένων - αυτό είναι ένα λαμπρό μέλλον, για το οποίο, φυσικά, προσπαθούμε και μας αρέσει, αλλά μέχρι στιγμής ζουν ακόμα σε μείον 20 χρόνια. Και, φυσικά, όλα αυτά πρέπει να παρακολουθούνται.
Και το καθήκον της μεγιστοποίησης της απόδοσης είναι να συντονιστείτε σε όλα αυτά τα στάδια, έτσι ώστε όλα να πηγαίνουν γρήγορα μπροστά και πίσω. Η κοινόχρηστη μνήμη είναι βασικά μια προσωρινή μνήμη σελίδας. Στην PostgreSQL, στείλαμε ένα αίτημα επιλογής κάτι, πήρε αυτά τα δεδομένα από το δίσκο. Μπήκαν σε κοινόχρηστα buffers. Αντίστοιχα, για να λειτουργήσει καλύτερα, πρέπει να υπάρχει πολλή μνήμη.
Για να λειτουργήσουν όλα αυτά καλά και γρήγορα, πρέπει να ρυθμίσετε σωστά το λειτουργικό σύστημα σε όλα τα στάδια. Και επιλέξτε ισορροπημένο σίδερο, γιατί αν έχετε ανισορροπία σε κάποιο μέρος, τότε μπορείτε να φτιάξετε πολλή μνήμη, αλλά θα σερβίρεται με ανεπαρκή ταχύτητα.
Ας περάσουμε από κάθε ένα από αυτά τα σημεία.
Προκειμένου αυτές οι σελίδες να ταξιδεύουν εμπρός και πίσω πιο γρήγορα, πρέπει να επιτύχετε τα εξής:
- Πρώτον, πρέπει να εργαστείτε πιο αποτελεσματικά με τη μνήμη.
- Δεύτερον, αυτή η μετάβαση θα πρέπει να είναι πιο αποτελεσματική όταν οι σελίδες από τη μνήμη πηγαίνουν στο δίσκο.
- Και, τρίτον, πρέπει να υπάρχουν καλοί δίσκοι.
Εάν έχετε 512 GB μνήμης RAM στον διακομιστή και όλα αυτά καταλήγουν σε έναν σκληρό δίσκο SATA χωρίς καμία προσωρινή μνήμη, τότε ολόκληρος ο διακομιστής βάσης δεδομένων μετατρέπεται όχι μόνο σε κολοκύθα, αλλά σε κολοκύθα με διεπαφή SATA. Θα το αντιμετωπίσετε απευθείας. Και τίποτα δεν θα σε σώσει.
Όσο για το πρώτο σημείο με τη μνήμη, υπάρχουν τρία πράγματα που μπορούν να κάνουν τη ζωή πολύ δύσκολη.
Το πρώτο είναι το NUMA. Το NUMA είναι ένα πράγμα που έχει δημιουργηθεί για να βελτιώσει την απόδοση. Ανάλογα με τον φόρτο εργασίας, μπορείτε να βελτιστοποιήσετε διαφορετικά πράγματα. Και στη νέα του τρέχουσα μορφή, δεν είναι πολύ καλό για εφαρμογές όπως μια βάση δεδομένων που χρησιμοποιούν εντατικά κοινόχρηστα buffer προσωρινής μνήμης σελίδας.
Με λίγα λόγια. Πώς να καταλάβετε ότι κάτι δεν πάει καλά με το NUMA; Έχετε κάποιο δυσάρεστο χτύπημα, ξαφνικά κάποια CPU υπερφορτώνεται. Ταυτόχρονα, αναλύεις ερωτήματα στο PostgreSQL και βλέπεις ότι δεν υπάρχει κάτι παρόμοιο εκεί. Αυτά τα αιτήματα δεν πρέπει να είναι τόσο εντάσεως CPU. Μπορείς να το πιάσεις για πολύ καιρό. Είναι πιο εύκολο να χρησιμοποιήσετε τις σωστές συμβουλές από την αρχή για το πώς να ρυθμίσετε το NUMA για PostgreSQL.
Τι πραγματικά συμβαίνει; Το NUMA σημαίνει μη ομοιόμορφη πρόσβαση στη μνήμη. Ποιο είναι το νόημα? Έχετε μια CPU, δίπλα της υπάρχει η τοπική της μνήμη. Και αυτή η διασύνδεση μνήμης μπορεί να τραβήξει τη μνήμη από άλλες CPU.
Αν τρέχεις numactl --hardware, τότε θα πάρετε ένα τόσο μεγάλο σεντόνι. Μεταξύ άλλων θα υπάρχει και πεδίο αποστάσεων. Θα υπάρχουν αριθμοί - 10-20, κάτι τέτοιο. Αυτοί οι αριθμοί δεν είναι παρά ο αριθμός των αναπηδήσεων για να σηκώσετε αυτήν την απομακρυσμένη μνήμη και να τη χρησιμοποιήσετε τοπικά. Βασικά μια καλή ιδέα. Αυτό βελτιώνει καλά την απόδοση σε έναν αριθμό φόρτων εργασίας.
Τώρα φανταστείτε ότι έχετε μια CPU που προσπαθεί πρώτα να χρησιμοποιήσει την τοπική της μνήμη και μετά προσπαθεί να τραβήξει μια άλλη μνήμη μέσω διασύνδεσης για κάτι. Και ολόκληρη η προσωρινή μνήμη της σελίδας PostgreSQL φτάνει σε αυτήν την CPU - αυτό είναι, πόσα gigabyte υπάρχουν. Παίρνετε πάντα τη χειρότερη περίπτωση επειδή υπάρχει συνήθως λίγη μνήμη στη CPU απευθείας σε αυτήν τη μονάδα. Και όλη η μνήμη που σερβίρεται περνά μέσα από αυτές τις διασυνδέσεις. Αποδεικνύεται αργά και λυπηρά. Και έχετε έναν επεξεργαστή που εξυπηρετεί ότι αυτός ο κόμβος είναι συνεχώς υπερφορτωμένος. Και ο χρόνος πρόσβασης αυτής της μνήμης είναι κακός, αργός. Αυτό είναι το είδος της κατάστασης που δεν θέλετε εάν χρησιμοποιείτε αυτήν την περίπτωση για μια βάση δεδομένων.
Επομένως, μια πιο σωστή επιλογή για τη βάση δεδομένων είναι ότι το λειτουργικό σύστημα Linux δεν γνωρίζει καθόλου τι συμβαίνει εκεί. Ώστε να απευθύνεται στη μνήμη όπως απευθύνεται.
Γιατί αυτό? Φαίνεται ότι θα έπρεπε να είναι το αντίστροφο. Αυτό συμβαίνει για έναν απλό λόγο, ότι χρειαζόμαστε πολλή μνήμη για την προσωρινή μνήμη σελίδων - δεκάδες, εκατοντάδες gigabyte.
Και αν τα διαθέσουμε όλα αυτά και αποθηκεύσουμε τα δεδομένα μας εκεί, τότε το κέρδος από τη χρήση της κρυφής μνήμης θα είναι σημαντικά μεγαλύτερο από το κέρδος από μια τόσο πονηρή πρόσβαση στη μνήμη. Και με αυτόν τον τρόπο θα κερδίσουμε ασύγκριτα σε σύγκριση με το γεγονός ότι θα έχουμε πρόσβαση στη μνήμη πιο αποτελεσματικά χρησιμοποιώντας το NUMA.
Επομένως, υπάρχουν δύο προσεγγίσεις αυτή τη στιγμή, μέχρι να έρθει ένα λαμπρό μέλλον, και η ίδια η βάση δεδομένων δεν μπορεί να καταλάβει σε ποιες CPU λειτουργεί και από πού πρέπει να αντλήσει κάτι.
Επομένως, η σωστή προσέγγιση είναι να απενεργοποιήσετε εντελώς το NUMAπχ κατά την επανεκκίνηση. Στις περισσότερες περιπτώσεις, τα κέρδη είναι σε τέτοιες τάξεις που δεν τίθεται καθόλου θέμα, τι είναι καλύτερο.
Υπάρχει μια άλλη επιλογή. Το χρησιμοποιούμε πιο συχνά από το πρώτο, γιατί όταν ένας πελάτης έρχεται σε εμάς για υποστήριξη, τότε η επανεκκίνηση του διακομιστή είναι μια ολόκληρη υπόθεση. Έχει μια επιχείρηση εκεί. Και αντιμετωπίζουν προβλήματα λόγω της NUMA. Επομένως, προσπαθούμε να το απενεργοποιήσουμε με λιγότερο επεμβατικούς τρόπους από την επανεκκίνηση, αλλά εδώ προσέξτε να ελέγξετε ότι είναι απενεργοποιημένο. Επειδή, όπως δείχνει η εμπειρία, ότι απενεργοποιούμε το NUMA στη γονική διαδικασία της PostgreSQL, αυτό είναι καλό, αλλά δεν είναι καθόλου απαραίτητο να λειτουργήσει. Πρέπει να ελέγξουμε και να δούμε ότι όντως απενεργοποιήθηκε.
Υπάρχει μια καλή ανάρτηση από τον Robert Haas. Αυτός είναι ένας από τους committers PostgreSQL. Ένας από τους βασικούς προγραμματιστές όλων των εντόσθων χαμηλού επιπέδου. Και αν ακολουθήσετε τους συνδέσμους από αυτήν την ανάρτηση, περιγράφει πολλές πολύχρωμες ιστορίες για το πώς η NUMA έκανε τη ζωή δύσκολη για τους ανθρώπους. Κοιτάξτε, μελετήστε τη λίστα ελέγχου του διαχειριστή συστήματος σχετικά με το τι πρέπει να ρυθμιστεί στον διακομιστή προκειμένου η βάση δεδομένων μας να λειτουργεί καλά. Αυτές οι ρυθμίσεις πρέπει να καταγραφούν και να ελεγχθούν, γιατί διαφορετικά δεν θα είναι πολύ καλές.
Εφιστώ την προσοχή σας στο γεγονός ότι αυτό ισχύει για όλες τις ρυθμίσεις για τις οποίες θα μιλήσω. Αλλά συνήθως οι βάσεις δεδομένων συναρμολογούνται σε λειτουργία master-slave για ανοχή σφαλμάτων. Μην ξεχάσετε να κάνετε αυτές τις ρυθμίσεις στο slave, γιατί μια μέρα θα έχετε ένα ατύχημα και θα μεταβείτε στο slave και θα γίνει ο κύριος.
Σε περίπτωση έκτακτης ανάγκης, όταν όλα είναι πολύ άσχημα, το τηλέφωνό σας χτυπά συνεχώς και το αφεντικό σας τρέχει με ένα μεγάλο ραβδί, δεν θα έχετε χρόνο να σκεφτείτε να ελέγξετε. Και τα αποτελέσματα μπορεί να είναι πολύ καταστροφικά.
Η επόμενη στιγμή είναι τεράστιες σελίδες. Οι τεράστιες σελίδες είναι δύσκολο να δοκιμαστούν ξεχωριστά και δεν έχει νόημα σε αυτό, αν και υπάρχουν σημεία αναφοράς που μπορούν να το κάνουν αυτό. Ψάχνονται εύκολα στο google.
Ποιο ειναι το νοημα? Έχετε έναν όχι πολύ ακριβό διακομιστή που έχει πολλή μνήμη RAM, για παράδειγμα, πάνω από 30 GB. Δεν χρησιμοποιείτε τεράστιες σελίδες. Αυτό σημαίνει ότι έχετε σίγουρα επιβάρυνση στη χρήση της μνήμης. Και αυτό το γενικό κόστος απέχει πολύ από το πιο ευχάριστο.
Γιατί αυτό? Και τι συμβαίνει; Το λειτουργικό σύστημα εκχωρεί τη μνήμη σε μικρά κομμάτια. Τόσο βολικό, τόσο ιστορικά. Και αν μπείτε σε λεπτομέρειες, τότε το λειτουργικό σύστημα πρέπει να μεταφράσει τις εικονικές διευθύνσεις σε φυσικές. Και αυτή η διαδικασία δεν είναι η πιο εύκολη, επομένως το λειτουργικό σύστημα αποθηκεύει το αποτέλεσμα αυτής της λειτουργίας στο Translation Lookaside Buffer (TLB).
Και δεδομένου ότι το TLB είναι μια κρυφή μνήμη, τότε σε αυτήν την κατάσταση προκύπτουν όλα τα προβλήματα που είναι εγγενή στη μνήμη cache. Πρώτον, εάν έχετε πολλή μνήμη RAM και κατανέμεται όλη σε μικρά κομμάτια, τότε αυτό το buffer γίνεται πολύ μεγάλο. Και αν η κρυφή μνήμη είναι μεγάλη, τότε είναι πιο αργή η αναζήτηση για αυτήν. Το overhead είναι υγιές και πιάνει χώρο από μόνο του, δηλαδή κάτι λάθος καταναλώνει τη μνήμη RAM. Αυτή τη φορά.
Δύο - όσο περισσότερο αυξάνεται η προσωρινή μνήμη σε μια τέτοια κατάσταση, τόσο πιο πιθανό είναι να έχετε ελλείψεις προσωρινής μνήμης. Και η αποτελεσματικότητα αυτής της κρυφής μνήμης πέφτει γρήγορα καθώς το μέγεθός της μεγαλώνει. Έτσι τα λειτουργικά συστήματα κατέληξαν σε μια απλή προσέγγιση. Το Linux το χρησιμοποιεί εδώ και πολύ καιρό. Εμφανίστηκε στο FreeBSD όχι πολύ καιρό πριν. Αλλά μιλάμε για Linux. Αυτές είναι τεράστιες σελίδες.
Και εδώ πρέπει να σημειωθεί ότι τεράστιες σελίδες, ως ιδέα, αρχικά προωθήθηκαν από κοινότητες που περιελάμβαναν την Oracle και την IBM, δηλαδή, οι κατασκευαστές βάσεων δεδομένων σκέφτηκαν σκληρά το γεγονός ότι αυτό θα ήταν χρήσιμο, ακόμη και για βάσεις δεδομένων.
Και πώς να κάνετε φίλους με την PostgreSQL; Πρώτον, τεράστιες σελίδες πρέπει να είναι ενεργοποιημένες στον πυρήνα του Linux.
Δεύτερον, πρέπει να προσδιορίζονται ρητά από την παράμετρο sysctl - πόσα είναι. Οι αριθμοί εδώ είναι από κάποιον παλιό διακομιστή. Μπορείτε να υπολογίσετε περίπου πόσα κοινόχρηστα buffer έχετε έτσι ώστε να χωρούν εκεί τεράστιες σελίδες.
Και αν έχετε ολόκληρο τον διακομιστή αφιερωμένο στην PostgreSQL, τότε ένα καλό σημείο εκκίνησης είναι είτε να δώσετε το 25% της μνήμης RAM για κοινόχρηστα buffer, είτε το 75% εάν είστε βέβαιοι ότι η βάση δεδομένων σας θα ταιριάζει σίγουρα σε αυτά τα 75%. Αφετηρία πρώτα. Και σκεφτείτε, εάν έχετε 256 GB μνήμης RAM, τότε, κατά συνέπεια, θα έχετε 64 GB αποθηκευτικών χώρων. Υπολογίστε περίπου με κάποιο περιθώριο - σε τι πρέπει να ορίσετε αυτό το νούμερο.
Πριν από την έκδοση 9.2 (αν δεν κάνω λάθος, από την έκδοση 8.2) ήταν δυνατό να κάνετε φίλους με τεράστιες σελίδες PostgreSQL χρησιμοποιώντας μια βιβλιοθήκη τρίτων. Και αυτό πρέπει να γίνεται πάντα. Πρώτον, χρειάζεσαι τον πυρήνα για να μπορείς να εκχωρήσεις τεράστιες σελίδες σωστά. Και, δεύτερον, για να τα χρησιμοποιήσει η εφαρμογή που συνεργάζεται με αυτά. Απλώς δεν θα χρησιμοποιηθεί με αυτόν τον τρόπο. Εφόσον η PostgreSQL εκχώρησε μνήμη σε στυλ συστήματος 5, αυτό θα μπορούσε να γίνει χρησιμοποιώντας libhugetlbfs - αυτό είναι το πλήρες όνομα της βιβλιοθήκης.
9.3 βελτίωσε την απόδοση της μνήμης PostgreSQL και αφαίρεσε τη μέθοδο εκχώρησης μνήμης του συστήματος 5. Όλοι ήταν πολύ χαρούμενοι, γιατί διαφορετικά προσπαθείτε να εκτελέσετε δύο περιπτώσεις PostgreSQL στον ίδιο υπολογιστή και λέει ότι δεν έχω αρκετή κοινόχρηστη μνήμη. Και λέει ότι πρέπει να διορθώσετε το sysctl. Και υπάρχει ένα τέτοιο sysctl που πρέπει ακόμα να κάνετε επανεκκίνηση, κλπ. Γενικά, όλοι έμειναν ευχαριστημένοι. Αλλά η κατανομή μνήμης mmap χάλασε χρησιμοποιώντας τεράστιες σελίδες. Οι περισσότεροι από τους πελάτες μας χρησιμοποιούν μεγάλα κοινόχρηστα buffer. Και συνιστούσαμε ανεπιφύλακτα να μην μεταβείτε στο 9.3, γιατί εκεί τα γενικά έξοδα άρχισαν να υπολογίζονται σε καλά ποσοστά.
Αλλά από την άλλη πλευρά, η κοινότητα επέστησε την προσοχή σε αυτό το πρόβλημα και στο 9.4 ξαναδούλεψαν αυτό το γεγονός πολύ καλά. Και στο 9.4, εμφανίστηκε μια παράμετρος στο postgresql.conf, στην οποία μπορείτε να ενεργοποιήσετε, να ενεργοποιήσετε ή να απενεργοποιήσετε τη δοκιμή.
Η δοκιμή είναι η πιο ασφαλής επιλογή. Όταν ξεκινά η PostgreSQL, όταν εκχωρεί κοινόχρηστη μνήμη, προσπαθεί να αρπάξει αυτή τη μνήμη από τεράστιες σελίδες. Και αν δεν λειτουργεί, τότε επιστρέφει στη συνηθισμένη επιλογή. Και αν έχετε FreeBSD ή Solaris, τότε μπορείτε να δοκιμάσετε, είναι πάντα ασφαλές.
Εάν είναι ενεργοποιημένο, τότε απλά δεν ξεκινά εάν δεν μπορούσε να επιλέξει από τεράστιες σελίδες. Εδώ ήδη - σε ποιον και τι είναι πιο χαριτωμένο. Αλλά αν έχετε μια δοκιμή, τότε ελέγξτε ότι έχετε πραγματικά επισημάνει αυτό που χρειάζεστε, επειδή υπάρχουν πολλά κενά για ένα σφάλμα. Προς το παρόν, αυτή η λειτουργία λειτουργεί μόνο σε Linux.
Μια ακόμη μικρή σημείωση πριν προχωρήσουμε. Οι διαφανείς τεράστιες σελίδες δεν αφορούν ακόμα την PostgreSQL. Δεν μπορεί να τα χρησιμοποιήσει κανονικά. Και με τις Διαφανείς τεράστιες σελίδες για τέτοιο φόρτο εργασίας, όταν χρειάζεστε ένα μεγάλο κομμάτι κοινόχρηστης μνήμης, τα πλεονεκτήματα έρχονται μόνο με πολύ μεγάλους όγκους. Εάν έχετε terabytes μνήμης, τότε αυτό μπορεί να παίξει κάποιο ρόλο. Αν μιλάμε για πιο καθημερινές εφαρμογές, όταν έχετε 32, 64, 128, 256 GB μνήμης στο μηχάνημα, τότε οι συνηθισμένες τεράστιες σελίδες είναι ΟΚ και απλά απενεργοποιούμε το Transparent.
Και το τελευταίο πράγμα για τη μνήμη δεν σχετίζεται άμεσα με το φρούτο, μπορεί να καταστρέψει πολύ τη ζωή. Όλη η απόδοση θα επηρεαστεί σε μεγάλο βαθμό από το γεγονός ότι ο διακομιστής αλλάζει συνεχώς.
Και θα είναι πολύ δυσάρεστο σε κάποια σημεία. Και το κύριο πρόβλημα είναι ότι στους σύγχρονους πυρήνες η συμπεριφορά είναι ελαφρώς διαφορετική από τους παλαιότερους πυρήνες Linux. Και αυτό το πράγμα, που είναι μάλλον δυσάρεστο να το πατάς, γιατί όταν μιλάμε για κάποια δουλειά με swap, τελειώνει με την άκαιρη άφιξη του OOM-killer. Και το OOM-killer, που δεν ήρθε εγκαίρως και πέταξε την PostgreSQL, είναι δυσάρεστο. Όλοι θα το γνωρίζουν, δηλαδή μέχρι τον τελευταίο χρήστη.
Τι συμβαίνει? Έχετε μεγάλη ποσότητα μνήμης RAM εκεί, όλα λειτουργούν καλά. Αλλά για κάποιο λόγο ο διακομιστής κολλάει στο swap και επιβραδύνει εξαιτίας αυτού. Φαίνεται ότι υπάρχει πολλή μνήμη, αλλά συμβαίνει.
Προηγουμένως, συμβουλεύαμε το vm.swappiness να μηδενιστεί, δηλαδή να απενεργοποιήσετε την εναλλαγή. Προηγουμένως, φαινόταν ότι τα 32 GB μνήμης RAM και τα αντίστοιχα κοινόχρηστα buffer ήταν ένα τεράστιο ποσό. Ο κύριος σκοπός της ανταλλαγής είναι να έχουμε ένα μέρος για να ρίξουμε μια κρούστα αν πέσουμε. Και δεν έχει γίνει πολύ καλά. Και μετά τι θα κάνετε με αυτή την κρούστα; Αυτό είναι ήδη μια τέτοια εργασία όταν δεν είναι πολύ σαφές γιατί χρειάζεται ανταλλαγή, ειδικά τέτοιου μεγέθους.
Αλλά στις πιο σύγχρονες, δηλαδή στις τρίτες εκδόσεις του πυρήνα, η συμπεριφορά έχει αλλάξει. Και αν ρυθμίσετε το swap στο μηδέν, δηλ. το απενεργοποιήσετε, τότε αργά ή γρήγορα, ακόμα και με λίγη μνήμη RAM, θα έρθει σε εσάς ένας OOM-killer για να σκοτώσει τους πιο εντατικούς καταναλωτές. Γιατί θα θεωρήσει ότι με τέτοιο φόρτο εργασίας μας μένει λίγο ακόμα και θα πηδήξουμε έξω, δηλαδή να μην σκοτώσουμε τη διαδικασία του συστήματος, αλλά να σκοτώσουμε κάτι λιγότερο σημαντικό. Αυτό το λιγότερο σημαντικό θα είναι ο μεγάλος καταναλωτής της κοινής μνήμης, δηλαδή ο ταχυδρόμος. Και μετά από αυτό θα είναι καλό αν η βάση δεν χρειάζεται να αποκατασταθεί.
Επομένως, τώρα η προεπιλογή, από όσο θυμάμαι, οι περισσότερες διανομές είναι κάπου γύρω στις 6, δηλαδή σε ποιο σημείο να αρχίσετε να χρησιμοποιείτε το swap, ανάλογα με το πόση μνήμη έχει απομείνει. Τώρα σας συμβουλεύουμε να ορίσετε το vm.swappiness = 1, γιατί πρακτικά το απενεργοποιεί, αλλά δεν δίνει τέτοια εφέ όπως με ένα απροσδόκητο OOM-killer που ήρθε και σκότωσε το όλο θέμα.
Τι έπεται? Όταν μιλάμε για την απόδοση των βάσεων δεδομένων και σταδιακά, σταδιακά, είμαστε σαν δίσκοι, όλοι αρχίζουν να πιάνουν το κεφάλι τους. Γιατί η αλήθεια ότι ο δίσκος είναι αργός και η μνήμη γρήγορη είναι γνωστή σε όλους από την παιδική ηλικία. Και όλοι γνωρίζουν ότι θα υπάρξουν προβλήματα απόδοσης δίσκου στη βάση δεδομένων.
Το κύριο πρόβλημα απόδοσης PostgreSQL με τις αιχμές των σημείων ελέγχου δεν είναι επειδή ο δίσκος είναι αργός. Αυτό είναι πιο πιθανό λόγω του γεγονότος ότι η μνήμη και το εύρος ζώνης του δίσκου δεν είναι ισορροπημένα. Ωστόσο, μπορεί να μην είναι ισορροπημένα σε διαφορετικά σημεία. Το PostgreSQL δεν έχει ρυθμιστεί, το λειτουργικό σύστημα δεν έχει ρυθμιστεί, το υλικό δεν έχει ρυθμιστεί και το υλικό είναι λάθος. Και αυτό το πρόβλημα δεν συμβαίνει μόνο εάν όλα πάνε όπως θα έπρεπε, δηλαδή είτε δεν υπάρχει φόρτωση, είτε οι ρυθμίσεις και το υλικό είναι σωστά επιλεγμένα.
Τι είναι και πώς μοιάζει; Συνήθως, τα άτομα που εργάζονται με την PostgreSQL έχουν μπει σε αυτήν την επιχείρηση περισσότερες από μία φορές. Θα εξηγήσω. Όπως είπα, η PostgreSQL κάνει περιοδικά σημεία ελέγχου για να απορρίπτει βρώμικες σελίδες στην κοινόχρηστη μνήμη στο δίσκο. Εάν έχουμε μεγάλη ποσότητα κοινής μνήμης, τότε το σημείο ελέγχου αρχίζει να επηρεάζει έντονα τον δίσκο, επειδή το fsync απορρίπτει αυτές τις σελίδες. Φτάνει στο buffer του πυρήνα και γράφεται στο δίσκο χρησιμοποιώντας fsync. Και αν ο όγκος αυτής της θήκης είναι μεγάλος, τότε μπορούμε να παρατηρήσουμε ένα δυσάρεστο αποτέλεσμα, δηλαδή μια πολύ μεγάλη χρήση δίσκων.
Εδώ έχω δύο φωτογραφίες. Θα εξηγήσω τώρα τι είναι. Αυτά είναι δύο χρονικά συσχετισμένα γραφήματα. Το πρώτο γράφημα είναι η χρήση του δίσκου. Εδώ φτάνει σχεδόν το 90% σε αυτό το χρονικό σημείο. Εάν έχετε πτώση βάσης δεδομένων με φυσικούς δίσκους, με ελεγκτή RAID κάτω από 90% χρήση, τότε αυτό είναι άσχημα νέα. Αυτό σημαίνει ότι θα έρθουν λίγο παραπάνω και 100 και θα σταματήσει η είσοδος / έξοδος.
Εάν έχετε μια συστοιχία δίσκων, τότε υπάρχει μια ελαφρώς διαφορετική ιστορία. Εκεί εξαρτάται από το πώς έχει ρυθμιστεί, τι είδους πίνακας κ.λπ.
Και παράλληλα, ένα γράφημα διαμορφώνεται εδώ από την εσωτερική προβολή postgres, το οποίο λέει πώς εμφανίζεται το σημείο ελέγχου. Και το πράσινο χρώμα εδώ δείχνει πόσα buffer από αυτές τις βρώμικες σελίδες εκείνη τη στιγμή έφτασαν σε αυτό το σημείο ελέγχου για συγχρονισμό. Και αυτό είναι το κύριο πράγμα που πρέπει να γνωρίζετε εδώ. Βλέπουμε ότι έχουμε πολλές σελίδες εδώ και κάποια στιγμή μπήκαμε σε χρέωση, δηλαδή γράψαμε και γράψαμε, εδώ το σύστημα του δίσκου είναι σαφώς πολύ απασχολημένο. Και το σημείο ελέγχου μας έχει πολύ ισχυρή επίδραση στο δίσκο. Στην ιδανική περίπτωση, η κατάσταση θα έπρεπε να μοιάζει περισσότερο με αυτό, δηλαδή είχαμε λιγότερο ρεκόρ εδώ. Και μπορούμε να το διορθώσουμε με ρυθμίσεις ώστε να συνεχίσει έτσι. Δηλαδή η ανακύκλωση είναι μικρή, αλλά κάπου γράφουμε κάτι εδώ.
Τι πρέπει να γίνει για να ξεπεραστεί αυτό το πρόβλημα; Εάν έχετε σταματήσει το IO στη βάση δεδομένων, τότε αυτό σημαίνει ότι όλοι οι χρήστες που ήρθαν για να εκτελέσουν τα αιτήματά τους θα περιμένουν.
Αν κοιτάξετε από τη σκοπιά του Linux, αν πήρατε καλό υλικό, το ρυθμίσατε σωστά, ρυθμίσατε κανονικά την PostgreSQL έτσι ώστε να κάνει αυτά τα σημεία ελέγχου λιγότερο συχνά, να τα διανέμει εγκαίρως μεταξύ τους, τότε μπείτε στις προεπιλεγμένες παραμέτρους του Debian . Για τις περισσότερες διανομές Linux, αυτή είναι η εικόνα: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Τι σημαίνει? Από τον πυρήνα 2.6, εμφανίστηκε ένα flushing ενός δαίμονα. Το Pdglush, ανάλογα με το ποιος χρησιμοποιεί τι, το οποίο ασχολείται με το παρασκήνιο να πετάει βρώμικες σελίδες από το buffer του πυρήνα και να πετάει βρώμικες σελίδες όταν είναι απαραίτητο, ανεξάρτητα από το τι, όταν το backgrouind ρίχνει δεν βοηθά.
Πότε έρχεται το παρασκήνιο; Όταν το 10% της συνολικής μνήμης RAM που υπάρχει στον διακομιστή καταλαμβάνεται από βρώμικες σελίδες στο buffer του πυρήνα, τότε καλείται μια ειδική συνάρτηση εξαπάτησης στο παρασκήνιο. Γιατί είναι φόντο; Χρειάζεται ως παράμετρος πόσες σελίδες θα διαγραφούν. Και, ας πούμε, διαγράφει Ν σελίδες. Και για λίγο αυτό το πράγμα πέφτει για ύπνο. Και μετά επιστρέφει και γράφει μερικές ακόμα σελίδες.
Αυτή είναι μια εξαιρετικά απλή ιστορία. Εδώ η εργασία είναι όπως με μια πισίνα, όταν χύνεται σε έναν σωλήνα, χύνεται σε έναν άλλο. Το σημείο ελέγχου μας ήρθε και αν έστειλε μερικές βρώμικες σελίδες για απόρριψη, τότε σταδιακά από την προσωρινή μνήμη του πυρήνα pgflush όλο αυτό το θέμα θα επιλυθεί όμορφα.
Εάν αυτές οι βρώμικες σελίδες συνεχίσουν να συσσωρεύονται, συσσωρεύονται έως και 20%, μετά από αυτό, η προτεραιότητα του λειτουργικού συστήματος είναι να διαγράψουμε ολόκληρο το πράγμα στο δίσκο, επειδή το ρεύμα θα πετάξει και όλα θα είναι άσχημα για εμάς. Θα χάσουμε αυτά τα δεδομένα, για παράδειγμα.
Ποιο είναι το κόλπο; Το κόλπο είναι ότι αυτές οι παράμετροι στον σύγχρονο κόσμο του 20 και του 10% του συνόλου της μνήμης RAM που υπάρχει στο μηχάνημα, είναι απολύτως τερατώδεις όσον αφορά την απόδοση οποιουδήποτε συστήματος δίσκων που έχετε.
Φανταστείτε ότι έχετε 128 GB μνήμης RAM. 12,8 GB έρχονται στο σύστημα του δίσκου σας. Και ό,τι cache και να έχεις εκεί, όποια συστοιχία και να έχεις εκεί, δεν θα αντέξουν τόσο πολύ.
Επομένως, συνιστούμε να προσαρμόσετε αμέσως αυτούς τους αριθμούς ανάλογα με τις δυνατότητες του ελεγκτή RAID σας. Έδωσα αμέσως μια σύσταση εδώ για έναν ελεγκτή που έχει 512 MB προσωρινής μνήμης.
Όλα θεωρούνται πολύ απλά. Μπορείτε να βάλετε vm.dirty_background σε byte. Και αυτές οι ρυθμίσεις υπερισχύουν των δύο προηγούμενων. Είτε η αναλογία είναι από προεπιλογή, είτε αυτά με byte είναι ενεργοποιημένα, τότε αυτά με byte θα λειτουργήσουν. Αλλά επειδή είμαι σύμβουλος DBA και δουλεύω με διαφορετικούς πελάτες, προσπαθώ να βάλω καλαμάκια και επομένως, αν σε bytes, τότε σε byte. Κανείς δεν έδωσε καμία εγγύηση ότι ένας καλός διαχειριστής δεν θα πρόσθετε μνήμη στον διακομιστή, δεν θα τον επανεκκινούσε και η τιμή θα παρέμενε η ίδια. Απλώς υπολογίστε αυτούς τους αριθμούς για να χωρέσουν όλα εκεί με εγγύηση.
Τι θα συμβεί αν δεν ταιριάζετε; Έχω γράψει ότι ουσιαστικά σταματά κάθε ξέπλυμα, αλλά στην πραγματικότητα είναι σχήμα λόγου. Το λειτουργικό σύστημα έχει ένα μεγάλο πρόβλημα - έχει πολλές βρώμικες σελίδες, οπότε το IO που δημιουργούν οι πελάτες σας σταματά αποτελεσματικά, δηλαδή η εφαρμογή ήρθε να στείλει ένα ερώτημα sql στη βάση δεδομένων, περιμένει. Οποιαδήποτε είσοδος/έξοδος σε αυτό είναι στη χαμηλότερη προτεραιότητα, επειδή η βάση καταλαμβάνεται από το σημείο ελέγχου. Και όταν τελειώνει είναι εντελώς ακατανόητο. Και όταν έχετε φτάσει στο flushing χωρίς παρασκήνιο, χωρίς παρασκήνιο, σημαίνει ότι όλο το IO σας είναι κατειλημμένο από αυτό. Και μέχρι να τελειώσει δεν θα κάνεις τίποτα.
Υπάρχουν δύο ακόμη σημαντικά σημεία που δεν εμπίπτουν στο πεδίο εφαρμογής αυτής της έκθεσης. Αυτές οι ρυθμίσεις θα πρέπει να ταιριάζουν με τις ρυθμίσεις στο postgresql.conf, δηλαδή τις ρυθμίσεις των σημείων ελέγχου. Και το σύστημα του δίσκου σας πρέπει να είναι επαρκώς διαμορφωμένο. Αν έχετε κρυφή μνήμη στο RAID, τότε πρέπει να έχει μπαταρία. Οι άνθρωποι αγοράζουν RAID με καλή κρυφή μνήμη χωρίς μπαταρία. Εάν έχετε SSD στο RAID, τότε πρέπει να είναι διακομιστής, πρέπει να υπάρχουν πυκνωτές. Εδώ είναι η διευρυμένη λίστα ελέγχου. Σε αυτόν τον σύνδεσμο υπάρχει η αναφορά μου σχετικά με τον τρόπο ρύθμισης της απόδοσης του δίσκου στο PostgreSQL. Όλες αυτές οι λίστες ελέγχου είναι εκεί.
Τι άλλο μπορεί να κάνει τη ζωή πολύ δύσκολη; Αυτές είναι δύο επιλογές. Είναι σχετικά καινούργια. Από προεπιλογή, μπορούν να συμπεριληφθούν σε διαφορετικές εφαρμογές. Και μπορούν να περιπλέξουν τη ζωή εξίσου εάν ενεργοποιηθούν λανθασμένα.
Υπάρχουν δύο σχετικά νέα κομμάτια. Έχουν ήδη εμφανιστεί στους τρίτους πυρήνες. Αυτά είναι sched_migration_cost σε νανοδευτερόλεπτα και sched_autogroup_enabled που είναι ένα από προεπιλογή.
Και πώς χαλάνε τη ζωή; Τι είναι το sched_migration_cost; Ο προγραμματιστής Linux μπορεί να μετεγκαταστήσει μια διεργασία από τη μια CPU στην άλλη. Και για την PostgreSQL, η οποία εκτελεί ερωτήματα, η μετάβαση σε άλλη CPU είναι εντελώς ακατανόητη γιατί. Από την άποψη του λειτουργικού συστήματος, όταν αλλάζετε τα παράθυρα μεταξύ openoffice και τερματικού, αυτό μπορεί να είναι εντάξει, αλλά για τη βάση δεδομένων - είναι πολύ κακό. Επομένως, μια λογική πολιτική είναι να ορίσετε το migration_cost σε κάποια μεγάλη τιμή, τουλάχιστον μερικές χιλιάδες νανοδευτερόλεπτα.
Τι θα σημαίνει αυτό για τον προγραμματιστή; Θα υποτεθεί ότι κατά τη διάρκεια αυτής της περιόδου αυτή η διαδικασία είναι ακόμα καυτή. Δηλαδή, εάν έχετε κάποιο είδος μακράς συναλλαγής που κάνει κάτι για μεγάλο χρονικό διάστημα, ο προγραμματιστής θα το καταλάβει αυτό. Θα υποθέσει ότι μέχρι να περάσει αυτό το χρονικό άουτ, τότε αυτή η διαδικασία δεν χρειάζεται να μεταφερθεί πουθενά. Εάν ταυτόχρονα η διαδικασία κάνει κάτι, τότε δεν θα μεταφερθεί πουθενά, θα τελειώσει ήρεμα στην CPU που της έχει εκχωρηθεί. Και το αποτέλεσμα είναι εξαιρετικό.
Το δεύτερο σημείο είναι η αυτόματη ομάδα. Υπάρχει μια καλή ιδέα για συγκεκριμένους φόρτους εργασίας που δεν σχετίζονται με σύγχρονες βάσεις δεδομένων - πρόκειται για ομαδοποίηση διεργασιών από το εικονικό τερματικό από το οποίο εκκινούνται. Είναι βολικό για ορισμένες εργασίες. Στην πράξη, το PostgreSQL είναι ένα σύστημα πολλαπλών διεργασιών prefork που εκτελείται από ένα μόνο τερματικό. Έχετε ένα πρόγραμμα εγγραφής κλειδαριών, ένα σημείο ελέγχου και όλα τα αιτήματα των πελατών σας ομαδοποιούνται σε έναν προγραμματιστή, ανά CPU. Και θα περιμένουν μαζί εκεί όταν είναι ελεύθερος, για να παρεμβαίνουν ο ένας στον άλλον και να τον απασχολούν περισσότερο. Αυτή είναι μια ιστορία που είναι εντελώς περιττή στην περίπτωση ενός τέτοιου φορτίου και επομένως θα πρέπει να απενεργοποιηθεί.
Ο συνάδελφός μου Alexey Lesovsky έκανε δοκιμές με ένα απλό pgbench, όπου αύξησε το migration_cost κατά μια τάξη μεγέθους και απενεργοποίησε την αυτόματη ομάδα. Η διαφορά σε ένα κακό κομμάτι σίδερου ήταν σχεδόν 10%. Υπάρχει μια συζήτηση στη λίστα αλληλογραφίας postgres όπου οι άνθρωποι αναφέρουν αποτελέσματα όπως παρόμοιες αλλαγές στην ταχύτητα ερωτήματος επηρέασε το 50%. Υπάρχουν αρκετές τέτοιες ιστορίες.
Και τέλος, σχετικά με την πολιτική εξοικονόμησης ενέργειας. Είναι καλό που τώρα το Linux μπορεί να χρησιμοποιηθεί σε φορητό υπολογιστή. Και υποτίθεται ότι θα καταναλώσει καλά την μπαταρία. Αλλά ξαφνικά αποδεικνύεται ότι αυτό μπορεί να συμβεί και στον διακομιστή.
Επιπλέον, αν νοικιάσετε διακομιστές από κάποιο hoster, τότε οι «καλοί» hosters δεν ενδιαφέρονται να έχετε καλύτερη απόδοση. Το καθήκον τους είναι να διασφαλίσουν ότι ο σίδηρος τους χρησιμοποιείται όσο το δυνατόν πιο αποτελεσματικά. Επομένως, από προεπιλογή, μπορούν να ενεργοποιήσουν τη λειτουργία εξοικονόμησης ενέργειας φορητού υπολογιστή στο λειτουργικό σύστημα.
Εάν το χρησιμοποιείτε σε έναν διακομιστή βάσης δεδομένων με μεγάλο φορτίο, τότε η επιλογή σας είναι acpi_cpufreq + permormance. Ακόμη και με ondemand, θα υπάρχουν ήδη προβλήματα.
Το Intel_pstate είναι ένα ελαφρώς διαφορετικό πρόγραμμα οδήγησης. Και τώρα προτιμάται αυτό, όπως σε μεταγενέστερο και καλύτερο λειτουργικό.
Και, κατά συνέπεια, ο κυβερνήτης είναι μόνο απόδοση. Ondemand, powersave και όλα τα υπόλοιπα - αυτό δεν αφορά εσάς.
Τα αποτελέσματα της εξήγησης ανάλυσης PostgreSQL μπορεί να διαφέρουν κατά πολλές τάξεις μεγέθους εάν ενεργοποιήσετε την εξοικονόμηση ενέργειας, επειδή στην πράξη θα έχετε απόρριψη της CPU κάτω από τη βάση δεδομένων με εντελώς απρόβλεπτο τρόπο.
Αυτά τα πράγματα μπορούν να ενεργοποιηθούν από προεπιλογή. Κοιτάξτε προσεκτικά για να δείτε αν έχουν ενεργοποιηθεί από προεπιλογή. Αυτό μπορεί να είναι ένα πραγματικά μεγάλο πρόβλημα.
Και στο τέλος, ήθελα να ευχαριστήσω τα παιδιά από την ομάδα μας στο PosgreSQL-Consulting DBA, δηλαδή τον Max Boguk και τον Alexey Lesovsky, που κάθε μέρα γεμίζουν προβλήματα σε αυτήν την επιχείρηση. Και για τους πελάτες μας, προσπαθούμε να κάνουμε το καλύτερο, ώστε όλα να λειτουργούν για αυτούς. Είναι όπως με τις οδηγίες ασφάλειας της αεροπορίας. Όλα εδώ είναι γραμμένα με αίμα. Κάθε ένα από αυτά τα καρύδια ανακαλύπτεται στη διαδικασία κάποιου είδους προβλήματος. Είμαι στην ευχάριστη θέση να τα μοιραστώ μαζί σας.
Ερωτήσεις:
Ευχαριστώ! Εάν, για παράδειγμα, μια εταιρεία θέλει να εξοικονομήσει χρήματα και να φιλοξενήσει τη βάση δεδομένων και τη λογική της εφαρμογής στον ίδιο διακομιστή ή εάν η εταιρεία ακολουθεί την τάση της μόδας των αρχιτεκτονικών microservice στις οποίες η PostgreSQL εκτελείται σε ένα κοντέινερ. Ποιο ειναι το νοημα? Το Sysctl επηρεάζει παγκοσμίως ολόκληρο τον πυρήνα. Δεν έχω ακούσει ότι το sysctl είναι κατά κάποιο τρόπο εικονικοποιημένο ώστε να λειτουργούν ξεχωριστά στο κοντέινερ. Υπάρχει μόνο cgroup και μόνο ένα μέρος του έχει τον έλεγχο. Πώς μπορείς να ζήσεις με αυτό; Ή αν θέλετε απόδοση, τότε εκτελέστε το PostgreSQL σε έναν ξεχωριστό διακομιστή και συντονιστείτε;
Έχουμε απαντήσει στην ερώτησή σας με τρεις περίπου τρόπους. Εάν δεν μιλάμε για έναν σιδερένιο διακομιστή που μπορεί να συντονιστεί κ.λπ., τότε χαλαρώστε, όλα θα λειτουργήσουν καλά χωρίς αυτές τις ρυθμίσεις. Εάν έχετε τέτοιο φορτίο που πρέπει να κάνετε αυτές τις ρυθμίσεις, τότε θα έρθετε στον διακομιστή σιδήρου νωρίτερα από αυτές τις ρυθμίσεις.
Ποιο είναι το πρόβλημα? Εάν πρόκειται για εικονική μηχανή, τότε πιθανότατα θα έχετε πολλά προβλήματα, για παράδειγμα, με το γεγονός ότι οι περισσότερες εικονικές μηχανές έχουν μάλλον ασυνεπή καθυστέρηση δίσκου. Ακόμα κι αν η διεκπεραίωση του δίσκου είναι καλή, τότε μια μεμονωμένη αποτυχημένη συναλλαγή εισόδου/εξόδου που δεν επηρεάζει πολύ τη μέση απόδοση που συνέβη τη στιγμή του σημείου ελέγχου ή τη στιγμή της εγγραφής στο WAL, τότε η βάση δεδομένων θα υποφέρει πολύ από αυτό. Και θα το παρατηρήσετε πριν αντιμετωπίσετε αυτά τα προβλήματα.
Εάν έχετε NGINX στον ίδιο διακομιστή, θα έχετε επίσης το ίδιο πρόβλημα. Θα αγωνιστεί για την κοινή μνήμη. Και δεν θα φτάσετε στα προβλήματα που περιγράφονται εδώ.
Αλλά από την άλλη πλευρά, ορισμένες από αυτές τις παραμέτρους θα εξακολουθούν να είναι σχετικές με εσάς. Για παράδειγμα, με το sysctl, ρυθμίστε το dirty_ratio για να μην είναι τόσο τρελό - σε κάθε περίπτωση, αυτό θα βοηθήσει. Με τον ένα ή τον άλλο τρόπο, θα έχετε αλληλεπίδραση με το δίσκο. Και θα είναι λάθος. Αυτή είναι γενικά η προεπιλογή των παραμέτρων που έδειξα. Και σε κάθε περίπτωση, είναι καλύτερο να τα αλλάξετε.
Και με το NUMA μπορεί να υπάρχουν προβλήματα. Το VmWare, για παράδειγμα, λειτουργεί καλά με το NUMA με ακριβώς τις αντίθετες ρυθμίσεις. Και εδώ πρέπει να επιλέξετε - έναν σιδερένιο διακομιστή ή έναν μη σιδερένιο διακομιστή.
Έχω μια ερώτηση σχετικά με το Amazon AWS. Έχουν προδιαμορφωμένες εικόνες. Ένα από αυτά ονομάζεται Amazon RDS. Υπάρχουν προσαρμοσμένες ρυθμίσεις για το λειτουργικό τους σύστημα;
Υπάρχουν ρυθμίσεις, αλλά είναι διαφορετικές ρυθμίσεις. Εδώ διαμορφώνουμε το λειτουργικό σύστημα ως προς τον τρόπο με τον οποίο η βάση δεδομένων θα χρησιμοποιήσει αυτήν την επιχείρηση. Και υπάρχουν παράμετροι που καθορίζουν πού πρέπει να πάμε τώρα, μια τέτοια διαμόρφωση. Δηλαδή χρειαζόμαστε τόσους πόρους, θα τους φάμε τώρα. Μετά από αυτό, το Amazon RDS στερεώνει αυτούς τους πόρους και η απόδοση πέφτει εκεί. Υπάρχουν ξεχωριστές ιστορίες για το πώς οι άνθρωποι αρχίζουν να αντιμετωπίζουν τη χημεία με αυτό το θέμα. Μερικές φορές μάλιστα με μεγάλη επιτυχία. Αλλά δεν έχει καμία σχέση με τις ρυθμίσεις του λειτουργικού συστήματος. Είναι σαν το cloud hacking. Είναι μια διαφορετική ιστορία.
Γιατί οι Διαφανείς τεράστιες σελίδες δεν έχουν κανένα αποτέλεσμα σε σύγκριση με το τεράστιο TLB;
Μην δώσεις. Αυτό μπορεί να εξηγηθεί με πολλούς τρόπους. Αλλά στην πραγματικότητα απλά δεν το δίνουν. Ποια είναι η ιστορία της PostgreSQL; Κατά την εκκίνηση, εκχωρεί ένα μεγάλο κομμάτι κοινόχρηστης μνήμης. Διαφανή είναι ταυτόχρονα ή όχι διαφανή - δεν έχει καμία σημασία. Το γεγονός ότι ξεχωρίζουν στο ξεκίνημα τα εξηγεί όλα. Και αν υπάρχει πολλή μνήμη και πρέπει να δημιουργήσετε ξανά το τμήμα shared_memory, τότε οι Διαφανείς τεράστιες σελίδες θα είναι σχετικές. Στην PostgreSQL, απλά τονίζεται στην αρχή με ένα τεράστιο κομμάτι και τέλος, και μετά δεν συμβαίνει τίποτα ιδιαίτερο εκεί. Μπορείτε, φυσικά, να το χρησιμοποιήσετε, αλλά υπάρχει μια πιθανότητα να λάβετε το curruption shared_memory όταν εκχωρεί εκ νέου κάτι. Η PostgreSQL δεν γνωρίζει κάτι τέτοιο.
Πηγή: www.habr.com