Προτείνω να διαβάσετε τη μεταγραφή της έκθεσης των αρχών του 2016 από τον Andrey Salnikov "Τυπικά σφάλματα σε εφαρμογές που οδηγούν σε bloat in postgresql"
Σε αυτήν την αναφορά, θα αναλύσω τα κύρια σφάλματα σε εφαρμογές που συμβαίνουν στο στάδιο του σχεδιασμού και της σύνταξης κώδικα εφαρμογής. Και θα πάρω μόνο εκείνα τα σφάλματα που οδηγούν σε bloat στο Postgresql. Κατά κανόνα, αυτή είναι η αρχή του τέλους της απόδοσης του συστήματός σας στο σύνολό του, αν και αρχικά δεν φάνηκαν προϋποθέσεις για αυτό.
Χαίρομαι που καλωσορίζω όλους! Αυτή η έκθεση δεν είναι τόσο τεχνική όσο η προηγούμενη από τον συνάδελφό μου. Αυτή η ομιλία απευθύνεται σε προγραμματιστές συστημάτων back-end, κυρίως επειδή έχουμε έναν αρκετά μεγάλο αριθμό πελατών. Και όλοι κάνουν τα ίδια λάθη. Θα σας πω για αυτούς. Θα εξηγήσω σε τι μοιραίο και κακό οδηγούν αυτά τα λάθη.
Γιατί γίνονται λάθη; Εκτελούνται για δύο λόγους: τυχαία, ίσως να λειτουργήσει από άγνοια ορισμένων μηχανισμών που συμβαίνουν στο επίπεδο μεταξύ της βάσης και της εφαρμογής, καθώς και στην ίδια τη βάση.
Θα σας δώσω τρία παραδείγματα με τρομερές εικόνες για το πώς τα πράγματα έγιναν άσχημα. Θα περιγράψω εν συντομία τον μηχανισμό που εμφανίζεται εκεί. Και πώς να τα αντιμετωπίσετε, πότε συνέβησαν και ποιες προληπτικές μεθόδους να χρησιμοποιήσετε για να αποτρέψετε λάθη. Θα σας πω για βοηθητικά εργαλεία και θα δώσω χρήσιμους συνδέσμους.
Χρησιμοποίησα μια δοκιμαστική βάση δεδομένων όπου είχα δύο πίνακες. Το ένα πιάτο με λογαριασμούς πελατών, το άλλο με πράξεις σε αυτούς τους λογαριασμούς. Και με κάποια περιοδικότητα, ενημερώνουμε τα υπόλοιπα σε αυτούς τους λογαριασμούς.
Τα αρχικά δεδομένα της πλάκας: είναι αρκετά μικρό, 2 MB. Πολύ καλός είναι και ο χρόνος απόκρισης για τη βάση δεδομένων και συγκεκριμένα για την πλάκα. Και ένα αρκετά καλό φορτίο - 2 λειτουργίες ανά δευτερόλεπτο στο πιάτο.
Και μέσα από αυτήν την αναφορά, θα σας δείξω γραφήματα για να είναι ξεκάθαρο τι συμβαίνει. Θα υπάρχουν πάντα 2 διαφάνειες με γραφήματα. Η πρώτη διαφάνεια είναι αυτό που συμβαίνει γενικά στον διακομιστή.
Και σε αυτή την κατάσταση, βλέπουμε ότι έχουμε πραγματικά ένα μικρό πιάτο. Το ευρετήριο είναι μικρό στα 2 MB. Αυτό είναι το πρώτο γράφημα στα αριστερά.
Ο μέσος χρόνος απόκρισης στον διακομιστή είναι επίσης σταθερός, μικρός. Αυτό είναι το πάνω δεξιά γράφημα.
Το κάτω αριστερό γράφημα είναι οι μεγαλύτερες συναλλαγές. Μπορούμε να δούμε ότι οι συναλλαγές ολοκληρώνονται γρήγορα. Και η αυτόματη ηλεκτρική σκούπα δεν λειτουργεί ακόμα εδώ, γιατί - ήταν μια δοκιμή εκκίνησης. Τότε θα λειτουργήσει και θα μας είναι χρήσιμο.
Η δεύτερη διαφάνεια θα είναι πάντα αφιερωμένη στη δοκιμαστική πλάκα. Σε αυτήν την περίπτωση, ενημερώνουμε συνεχώς τα υπόλοιπα των λογαριασμών του πελάτη. Και βλέπουμε ότι ο μέσος χρόνος απόκρισης για τη λειτουργία ενημέρωσης είναι αρκετά καλός, λιγότερο από ένα χιλιοστό του δευτερολέπτου. Βλέπουμε ότι οι πόροι του επεξεργαστή (αυτό είναι το πάνω δεξιά γράφημα) καταναλώνονται επίσης ομοιόμορφα και αρκετά μικρά.
Το κάτω δεξιά γράφημα δείχνει πόση λειτουργική και μνήμη δίσκου περνάμε αναζητώντας τη γραμμή που επιθυμούμε πριν την ενημερώσουμε. Και ο αριθμός των επεμβάσεων στο πιάτο είναι 2 το δευτερόλεπτο, όπως είπα στην αρχή.
Και τώρα έχουμε μια τραγωδία. Για κάποιο λόγο, εμφανίζεται μια ξεχασμένη από καιρό συναλλαγή. Οι λόγοι είναι συνήθως κοινόχρηστοι:
- Ένα από τα πιο συνηθισμένα είναι ότι αρχίσαμε να έχουμε πρόσβαση σε μια εξωτερική υπηρεσία στον κώδικα της εφαρμογής. Και αυτή η υπηρεσία δεν μας απαντά. Δηλαδή ανοίξαμε μια συναλλαγή, κάναμε μια αλλαγή στη βάση δεδομένων και πήγαμε από την εφαρμογή για να διαβάσουμε mail ή σε άλλη υπηρεσία εντός της υποδομής μας και για κάποιο λόγο δεν μας απαντά. Και η συνεδρία μας κρεμόταν σε κατάσταση - δεν είναι γνωστό πότε θα επιλυθεί.
- Η δεύτερη κατάσταση είναι όταν προέκυψε μια εξαίρεση στον κώδικά μας για κάποιο λόγο. Και δεν επεξεργαστήκαμε το κλείσιμο της συναλλαγής στην εξαίρεση. Και πήραμε μια εκκρεμή συνεδρία με μια ανοιχτή συναλλαγή.
- Και το τελευταίο είναι επίσης αρκετά συνηθισμένο. Αυτός είναι κώδικας κακής ποιότητας. Ορισμένα πλαίσια ανοίγουν μια συναλλαγή. Κρεμάει και μπορεί να μην ξέρεις στην εφαρμογή ότι το έχεις κρεμασμένο.
Πού οδηγούν τέτοια πράγματα;
Στο γεγονός ότι οι πίνακες και τα ευρετήρια μας αρχίζουν να διογκώνονται δραματικά. Αυτό είναι ακριβώς το ίδιο αποτέλεσμα φουσκώματος. Για τη βάση δεδομένων, αυτό θα εκφραστεί στο γεγονός ότι θα έχουμε μια πολύ απότομη αύξηση του χρόνου απόκρισης της βάσης δεδομένων, θα αυξηθεί το φορτίο στον διακομιστή της βάσης δεδομένων. Και ως αποτέλεσμα, η εφαρμογή μας θα υποφέρει. Γιατί αν στον κώδικά σας ξοδέψατε 10 χιλιοστά του δευτερολέπτου σε ένα αίτημα στη βάση δεδομένων, 10 χιλιοστά του δευτερολέπτου στη λογική σας, τότε η συνάρτησή σας λειτούργησε 20 χιλιοστά του δευτερολέπτου. Και τώρα η κατάστασή σας θα είναι πολύ θλιβερή.
Και ας δούμε τι θα γίνει. Το κάτω αριστερό γράφημα δείχνει ότι έχουμε μια μακροχρόνια συναλλαγή. Και αν κοιτάξουμε το επάνω αριστερό γράφημα, βλέπουμε ότι το μέγεθος του πίνακα μεταπήδησε από δύο megabyte στα 300 megabyte. Ταυτόχρονα, ο όγκος των δεδομένων στον πίνακα δεν έχει αλλάξει, δηλαδή υπάρχει αρκετά μεγάλος όγκος σκουπιδιών.
Η συνολική κατάσταση όσον αφορά τον μέσο χρόνο απόκρισης διακομιστή έχει επίσης αλλάξει κατά αρκετές τάξεις μεγέθους. Δηλαδή, όλα τα αιτήματα στον διακομιστή άρχισαν να πέφτουν εντελώς. Και ταυτόχρονα δρομολογήθηκαν οι εσωτερικές διαδικασίες Postgres απέναντι στο autovacuum, που προσπαθούν να κάνουν κάτι και να καταναλώσουν πόρους.
Τι συμβαίνει στο πιάτο μας; Το ίδιο. Ο μέσος χρόνος απόκρισης στο tablet αυξήθηκε αρκετές τάξεις μεγέθους. Αν συγκεκριμένα όσον αφορά τους πόρους που καταναλώνονται, τότε βλέπουμε ότι το φορτίο στον επεξεργαστή έχει αυξηθεί πολύ. Αυτό είναι το πάνω δεξιά γράφημα. Και έχει αυξηθεί επειδή ο επεξεργαστής πρέπει να περάσει από ένα σωρό άχρηστες γραμμές αναζητώντας αυτή που χρειάζεστε. Αυτό είναι το κάτω δεξιά γράφημα. Και ως αποτέλεσμα, ο αριθμός των κλήσεων ανά δευτερόλεπτο άρχισε να μειώνεται πολύ, επειδή η βάση δεδομένων δεν έχει χρόνο να επεξεργαστεί τον ίδιο αριθμό αιτημάτων.
Πρέπει να επιστρέψουμε στη ζωή. Ανεβαίνουμε στο Διαδίκτυο και ανακαλύπτουμε ότι οι μεγάλες συναλλαγές οδηγούν σε πρόβλημα. Βρίσκουμε και σκοτώνουμε αυτή τη συναλλαγή. Και όλα πάνε καλά για εμάς. Όλα λειτουργούν όπως πρέπει.
Ηρεμήσαμε, αλλά μετά από λίγο αρχίζουμε να παρατηρούμε ότι η εφαρμογή δεν λειτουργεί όπως πριν από την έκτακτη ανάγκη. Τα αιτήματα διεκπεραιώνονται το ίδιο πιο αργά και πολύ πιο αργά. Μιάμιση με δύο φορές πιο αργά ειδικά στο παράδειγμά μου. Το φορτίο στον διακομιστή είναι επίσης υψηλότερο από ό,τι πριν από το ατύχημα.
Και η ερώτηση: «Τι γίνεται με τη βάση αυτή τη στιγμή;». Και με βάση υπάρχει η εξής κατάσταση. Στο γράφημα συναλλαγών, μπορείτε να δείτε ότι έχει σταματήσει και πραγματικά δεν υπάρχουν μακροπρόθεσμες συναλλαγές. Όμως οι διαστάσεις της πλάκας κατά τη διάρκεια του ατυχήματος μεγάλωσαν μοιραία. Και δεν έχει μειωθεί από τότε. Ο μέσος χρόνος στη βάση έχει σταθεροποιηθεί. Και οι απαντήσεις φαίνεται να πηγαίνουν επαρκώς με μια αποδεκτή ταχύτητα για εμάς. Το Autovacuum έγινε πιο ενεργό και άρχισε να κάνει κάτι με το tablet, γιατί χρειάζεται να φτυαρίζει περισσότερα δεδομένα.
Συγκεκριμένα, στον πίνακα αποτελεσμάτων των δοκιμών, όπου αλλάζουμε τις ισορροπίες: ο χρόνος απόκρισης για το αίτημα φαίνεται να έχει επιστρέψει στο φυσιολογικό. Αλλά στην πραγματικότητα είναι μιάμιση φορά υψηλότερο.
Και από το φορτίο στον επεξεργαστή, βλέπουμε ότι το φορτίο στον επεξεργαστή δεν επέστρεψε στην επιθυμητή τιμή πριν από τη συντριβή. Και οι λόγοι βρίσκονται ακριβώς στο κάτω δεξιά γράφημα. Μπορεί να φανεί ότι υπάρχει μια αναζήτηση κάποιας ποσότητας μνήμης. Δηλαδή, για να αναζητήσουμε την επιθυμητή γραμμή, ξοδεύουμε τους πόρους του διακομιστή της βάσης δεδομένων κατά την ταξινόμηση άχρηστων δεδομένων. Ο αριθμός των συναλλαγών ανά δευτερόλεπτο έχει σταθεροποιηθεί.
Σε γενικές γραμμές, καλό, αλλά η κατάσταση είναι χειρότερη από ότι ήταν. Ρητή υποβάθμιση της βάσης δεδομένων ως συνέπεια της εφαρμογής μας που λειτουργεί με αυτήν τη βάση δεδομένων.
Και για να καταλάβετε τι συμβαίνει εκεί, αν δεν ήσασταν στην προηγούμενη έκθεση, τότε τώρα λίγη θεωρία. Θεωρία για την εσωτερική διαδικασία. Γιατί η αυτόματη σκούπα και τι κάνει;
Κυριολεκτικά με λίγα λόγια για κατανόηση. Κάποια στιγμή έχουμε ένα τραπέζι. Έχουμε σειρές στον πίνακα. Αυτές οι γραμμές μπορούν να είναι ενεργές, ζωντανές, χρειαζόμαστε τώρα. Στην εικόνα σημειώνονται με πράσινο χρώμα. Και υπάρχουν προθεσμίες που έχουν ήδη επεξεργαστεί, έχουν ενημερωθεί, έχουν εμφανιστεί νέες εγγραφές σε αυτές. Και επισημαίνονται ότι δεν είναι πλέον ενδιαφέροντα για τη βάση δεδομένων. Όμως κείτονται στον πίνακα λόγω των ιδιαιτεροτήτων της Postgres.
Γιατί χρειάζεστε αυτόματη σκούπα; Το Autovacuum έρχεται κάποια στιγμή, καλεί τη βάση δεδομένων και τη ρωτά: «Παρακαλώ δώστε μου το αναγνωριστικό της παλαιότερης συναλλαγής που είναι ανοιχτή αυτήν τη στιγμή στη βάση δεδομένων». Η βάση δεδομένων επιστρέφει αυτό το αναγνωριστικό. Και το αυτόματο κενό, βασιζόμενο σε αυτό, περνάει μέσα από τις γραμμές του πίνακα. Και αν δει ότι κάποιες γραμμές έχουν αλλάξει από πολύ παλαιότερες συναλλαγές, τότε έχει το δικαίωμα να τις επισημάνει ως γραμμές που μπορούμε να ξαναχρησιμοποιήσουμε στο μέλλον γράφοντας εκεί νέα δεδομένα. Αυτή είναι μια διαδικασία παρασκηνίου.
Αυτή τη στιγμή, συνεχίζουμε να εργαζόμαστε με τη βάση δεδομένων, συνεχίζουμε να κάνουμε κάποιες αλλαγές στον πίνακα. Και σε αυτές τις γραμμές, τις οποίες μπορούμε να χρησιμοποιήσουμε ξανά, γράφουμε νέα δεδομένα. Και με αυτόν τον τρόπο παίρνουμε έναν κύκλο, δηλαδή μερικές νεκρές παλιές γραμμές εμφανίζονται συνέχεια εκεί, αντί για αυτές γράφουμε νέες γραμμές που χρειαζόμαστε. Και αυτή είναι η κανονική κατάσταση για να λειτουργεί η PostgreSQL.
Τι συνέβη κατά τη διάρκεια του ατυχήματος; Πώς έγινε αυτή η διαδικασία;
Είχαμε ένα πιάτο σε κάποια κατάσταση, μερικά ζωντανά, κάποια νεκρά όρια. Η αυτόματη ηλεκτρική σκούπα έφτασε. Ρώτησε τη βάση δεδομένων για το ποια είναι η παλαιότερη συναλλαγή μας, ποιο είναι το αναγνωριστικό της. Πήρα αυτό το id, που μπορεί να είναι πολλές ώρες, ίσως και δέκα λεπτά. Εξαρτάται από το πόσο βαρύ φορτίο έχετε στη βάση δεδομένων. Και πήγε να ψάξει για γραμμές που μπορεί να επισημάνει ως επαναχρησιμοποιημένες. Και δεν βρήκα τέτοιες γραμμές στο τραπέζι μας.
Αλλά αυτή τη στιγμή συνεχίζουμε να δουλεύουμε με το τραπέζι. Κάνουμε κάτι σε αυτό, το ενημερώνουμε, αλλάζουμε τα δεδομένα. Τι πρέπει να κάνει η βάση δεδομένων αυτή τη στιγμή; Δεν έχει άλλη επιλογή από το να προσθέσει νέες γραμμές στο τέλος του υπάρχοντος πίνακα. Και έτσι σε εμάς το μέγεθος του τραπεζιού αρχίζει να φουσκώνει.
Χρειαζόμαστε πραγματικά πράσινες γραμμές για να λειτουργήσουμε. Αλλά κατά τη διάρκεια ενός τέτοιου προβλήματος, αποδεικνύεται ότι το ποσοστό των πράσινων γραμμών είναι εξαιρετικά χαμηλό σε ολόκληρο τον όγκο του πίνακα.
Και όταν εκτελούμε ένα ερώτημα, η βάση δεδομένων πρέπει να περάσει από όλες τις γραμμές, και τις κόκκινες και τις πράσινες, για να βρει τη σωστή γραμμή. Και το αποτέλεσμα του φουσκώματος του τραπεζιού με άχρηστα δεδομένα λέγεται «φουσκώματος», το οποίο μας τρώει και το χώρο στο δίσκο. Θυμάστε, ήταν 2 MB, τώρα είναι 300 MB; Τώρα αλλάξτε τα megabyte σε gigabyte και θα χάσετε όλους τους πόρους του δίσκου σας αρκετά γρήγορα.
Ποιες είναι οι επιπτώσεις για εμάς;
- Στο παράδειγμά μου, ο πίνακας και ο δείκτης έχουν αυξηθεί 150 φορές. Μερικοί από τους πελάτες μας είχαν περισσότερες θανατηφόρες περιπτώσεις όταν ο χώρος στο δίσκο άρχισε απλώς να εξαντλείται.
- Τα τραπέζια δεν θα συρρικνωθούν ποτέ από μόνα τους. Η αυτόματη ηλεκτρική σκούπα σε ορισμένες περιπτώσεις μπορεί να κόψει την ουρά του τραπεζιού εάν υπάρχουν μόνο τελικές γραμμές. Αλλά επειδή υπάρχει μια συνεχής περιστροφή, μια πράσινη γραμμή μπορεί να κρέμεται στο τέλος και να μην ενημερωθεί, και όλα τα υπόλοιπα κάπου στην αρχή της πλάκας θα καταγράφονται. Αλλά αυτό είναι ένα τόσο απίθανο γεγονός που το ίδιο το τραπέζι σας θα μειωθεί σε μέγεθος, επομένως δεν πρέπει να ελπίζετε σε αυτό.
- Η βάση δεδομένων πρέπει να ταξινομήσει ολόκληρο το σωρό των άχρηστων γραμμών. Και σπαταλάμε πόρους δίσκου, σπαταλάμε πόρους επεξεργαστών και ηλεκτρική ενέργεια.
- Και αυτό επηρεάζει άμεσα την αίτησή μας, γιατί αν στην αρχή ξοδέψαμε 10 χιλιοστά του δευτερολέπτου σε ένα αίτημα, 10 χιλιοστά του δευτερολέπτου στον κώδικά μας, τότε κατά τη διάρκεια της συντριβής αρχίσαμε να ξοδεύουμε ένα δευτερόλεπτο σε ένα αίτημα και 10 χιλιοστά του δευτερολέπτου στον κώδικα, δηλ. Η απόδοση της εφαρμογής μεγέθους μειώθηκε. Και όταν το ατύχημα επιλύθηκε, αρχίσαμε να ξοδεύουμε 20 χιλιοστά του δευτερολέπτου ανά αίτημα, 10 χιλιοστά του δευτερολέπτου ανά κωδικό. Αυτό σημαίνει ότι ακόμα βυθιστήκαμε μιάμιση φορά από άποψη απόδοσης. Και όλα αυτά οφείλονται σε μια συναλλαγή που κρεμάστηκε, και, ίσως, από υπαιτιότητά μας.
- Και η ερώτηση: «Πώς μπορώ να τα πάρω όλα πίσω;» Για να είναι όλα καλά μαζί μας και οι αιτήσεις να τρέχουν τόσο γρήγορα όσο πριν από το ατύχημα.
Για αυτό, υπάρχει ένας συγκεκριμένος κύκλος εργασιών που εκτελείται.
Πρώτα πρέπει να βρούμε τα προβληματικά τραπέζια που έχουν φουσκώσει. Καταλαβαίνουμε ότι ορισμένοι πίνακες καταγράφουν πιο ενεργά, άλλοι λιγότερο ενεργά. Και για αυτό χρησιμοποιούμε την επέκταση . Με την εγκατάσταση αυτής της επέκτασης, μπορείτε να γράψετε ερωτήματα που θα σας βοηθήσουν να βρείτε πίνακες που είναι αρκετά φουσκωμένοι.
Μόλις βρείτε αυτούς τους πίνακες, πρέπει να συμπιεστούν. Υπάρχουν ήδη εργαλεία για αυτό. Στην εταιρεία μας χρησιμοποιούμε τρία εργαλεία. Το πρώτο είναι το ενσωματωμένο VACUUM FULL. Είναι σκληρός, σκληρός και ανελέητος, αλλά μερικές φορές είναι πολύ χρήσιμος. и είναι βοηθητικά προγράμματα τρίτων για τη συμπίεση πινάκων. Και είναι πιο προσεκτικοί με τη βάση δεδομένων.
Χρησιμοποιούνται ανάλογα με το τι είναι πιο βολικό για εσάς. Αλλά θα μιλήσω για αυτό στο τέλος. Το κύριο πράγμα είναι ότι υπάρχουν τρία εργαλεία. Υπάρχουν πολλά για να διαλέξετε.
Αφού διορθώσουμε τα πάντα, βεβαιώνοντας ότι όλα είναι καλά, θα πρέπει να ξέρουμε πώς να αποτρέψουμε αυτήν την κατάσταση στο μέλλον:
- Είναι αρκετά εύκολο να αποφευχθεί. Πρέπει να παρακολουθείτε τη διάρκεια των συνεδριών στον κύριο διακομιστή. Ιδιαίτερα επικίνδυνες συνεδρίες σε κατάσταση αδράνειας σε συναλλαγή. Αυτοί είναι εκείνοι που μόλις άνοιξαν μια συναλλαγή, έκαναν κάτι και έφυγαν, ή απλά κρεμάστηκαν, χάθηκαν στον κωδικό.
- Και για εσάς, ως προγραμματιστές, είναι σημαντικό να δοκιμάσετε τον κώδικα τη στιγμή που προκύπτουν αυτές οι καταστάσεις. Δεν είναι δύσκολο να γίνει. Αυτό θα είναι ένας χρήσιμος έλεγχος. Θα αποφύγετε πολλά «παιδικά» προβλήματα που σχετίζονται με πολύωρες συναλλαγές.
Σε αυτά τα γραφήματα, ήθελα να σας δείξω πώς άλλαξε ο πίνακας και η συμπεριφορά της βάσης δεδομένων αφού πέρασα το VACUUM FULL στον πίνακα σε αυτήν την περίπτωση. Δεν είναι δική μου παραγωγή.
Το μέγεθος του πίνακα επέστρεψε αμέσως στην κανονική του κατάσταση λειτουργίας των μερικών megabyte. Αυτό δεν επηρέασε πολύ τον μέσο χρόνο απόκρισης στον διακομιστή.
Όμως, συγκεκριμένα στον πίνακα δοκιμών μας, όπου ενημερώσαμε τα υπόλοιπα των λογαριασμών, βλέπουμε ότι ο μέσος χρόνος απόκρισης σε ένα αίτημα ενημέρωσης των δεδομένων στο tablet μειώθηκε σε επίπεδα πριν από τη συντριβή. Οι πόροι που καταναλώθηκαν από τον επεξεργαστή για την εκτέλεση αυτού του αιτήματος έπεσαν επίσης σε επίπεδα πριν από τη συντριβή. Και το κάτω δεξιά γράφημα δείχνει ότι τώρα βρίσκουμε ακριβώς τη γραμμή που χρειαζόμαστε αμέσως, χωρίς να περάσουμε μέσα από το σωρό των νεκρών γραμμών που υπήρχαν πριν από τη συμπίεση του πίνακα. Και ο μέσος χρόνος ερωτήματος παρέμεινε περίπου στο ίδιο επίπεδο. Αλλά εδώ έχω, μάλλον, το σφάλμα του υλικού μου.
Εδώ τελειώνει η πρώτη ιστορία. Είναι η πιο κοινή. Και συμβαίνει σε όλους, ανεξάρτητα από την εμπειρία του πελάτη, πόσο καταρτισμένοι προγραμματιστές υπάρχουν. Αργά ή γρήγορα συμβαίνει.
Η δεύτερη ιστορία, στην οποία κατανέμουμε το φορτίο και βελτιστοποιούμε τους πόρους του διακομιστή
- Μεγαλώσαμε και γίναμε σοβαροί τύποι. Και καταλαβαίνουμε ότι έχουμε ένα αντίγραφο και θα ήταν καλό για εμάς να ισορροπήσουμε το φορτίο: γράψτε στον Δάσκαλο και διαβάστε από το αντίγραφο. Και συνήθως αυτή η κατάσταση προκύπτει όταν θέλουμε να ετοιμάσουμε κάποιου είδους αναφορές ή ETL. Και οι επιχειρήσεις είναι πολύ χαρούμενες γι' αυτό. Θέλει πραγματικά μια ποικιλία αναφορών με ένα σωρό πολύπλοκα αναλυτικά στοιχεία.
- Οι αναφορές διαρκούν πολλές ώρες, επειδή τα πολύπλοκα αναλυτικά στοιχεία δεν μπορούν να υπολογιστούν σε χιλιοστά του δευτερολέπτου. Εμείς, σαν γενναίοι τύποι, γράφουμε κώδικα. Κάνουμε στην εφαρμογή εισαγωγής που καταγράφουμε στο Master, εκτελούμε αναφορές στο αντίγραφο.
- Κατανέμουμε το φορτίο.
- Όλα λειτουργούν τέλεια. Μια χαρα ειμαστε.
Και πώς μοιάζει αυτή η κατάσταση; Συγκεκριμένα, σε αυτά τα γραφήματα πρόσθεσα και τη διάρκεια των συναλλαγών από το replica για τη διάρκεια της συναλλαγής. Όλα τα άλλα γραφήματα αναφέρονται μόνο στον κύριο διακομιστή.
Μέχρι εκείνη τη στιγμή, ο πίνακας αναφορών μου είχε μεγαλώσει. Υπάρχουν περισσότερα από αυτά. Μπορούμε να δούμε ότι ο μέσος χρόνος απόκρισης διακομιστή είναι σταθερός. Μπορούμε να δούμε ότι έχουμε μια μακροχρόνια συναλλαγή στο αντίγραφο που εκτελείται για 2 ώρες. Βλέπουμε την αθόρυβη δουλειά του αυτόματου κενού, που επεξεργάζεται τα deadlines. Και είμαστε όλοι καλά.
Συγκεκριμένα, σύμφωνα με το δοκιμαστικό tablet, συνεχίζουμε να ενημερώνουμε τα υπόλοιπα στους λογαριασμούς εκεί. Και έχουμε επίσης σταθερό χρόνο απόκρισης κατόπιν αιτήματος, σταθερή κατανάλωση πόρων. Όλα είναι καλά μαζί μας.
Όλα είναι καλά μέχρι τη στιγμή που αυτές οι αναφορές αρχίζουν να μας πυροβολούν σε μια σύγκρουση με την αναπαραγωγή. Και πυροβολούν ανά τακτά χρονικά διαστήματα.
Μπαίνουμε στο διαδίκτυο και αρχίζουμε να διαβάζουμε γιατί συμβαίνει αυτό. Και βρίσκουμε λύση.
Η πρώτη λύση είναι να αυξηθεί η καθυστέρηση αναπαραγωγής. Γνωρίζουμε ότι η αναφορά μας διαρκεί 3 ώρες. Ρυθμίστε την καθυστέρηση αναπαραγωγής σε 3 ώρες. Ξεκινάμε τα πάντα, αλλά εξακολουθούμε να αντιμετωπίζουμε προβλήματα με το γεγονός ότι μερικές φορές ανταποκρίνονται οι αναφορές.
Θέλουμε να είναι όλα τέλεια. Ας πάμε παρακάτω. Και βρίσκουμε μια δροσερή ρύθμιση στο Διαδίκτυο - hot_standby_feedback. Το ανάβουμε. Το Hot_standby_feedback μας επιτρέπει να κρατάμε την αυτόματη σκούπα σε λειτουργία στο Master. Έτσι, απαλλαγούμε εντελώς από τις συγκρούσεις αναπαραγωγής. Και όλοι δουλεύουμε καλά με τις αναφορές.
Και τι συμβαίνει με τον κύριο διακομιστή αυτή τη στιγμή; Και με τον κύριο διακομιστή, έχουμε μια ολοκληρωτική καταστροφή. Τώρα βλέπουμε γραφήματα με ενεργοποιημένες και τις δύο αυτές ρυθμίσεις. Και βλέπουμε ότι η συνεδρία στο αντίγραφο άρχισε να επηρεάζει κατά κάποιο τρόπο την κατάσταση στον κύριο διακομιστή. Έχει αντίκτυπο επειδή έχει αναστείλει την αυτόματη σκούπα που καθαρίζει τις προθεσμίες. Το μέγεθος του τραπεζιού μας έχει εκτοξευθεί ξανά. Ο μέσος χρόνος εκτέλεσης ερωτήματος σε ολόκληρη τη βάση δεδομένων εκτοξεύτηκε επίσης στα ύψη. Οι αυτόματες σκούπες έσφιξαν λίγο.
Συγκεκριμένα, στο πιάτο μας, βλέπουμε ότι η ενημέρωση δεδομένων σε αυτό πήδηξε επίσης στον ουρανό. Η κατανάλωση πόρων επεξεργαστή έχει επίσης αυξηθεί σημαντικά. Επαναλαμβάνουμε ξανά έναν μεγάλο αριθμό νεκρών άχρηστων γραμμών. Και ο χρόνος απόκρισης σε αυτό το tablet, ο αριθμός των συναλλαγών έχει μειωθεί.
Πώς θα μοιάζει αν δεν ξέρουμε για τι μιλούσα πριν;
- Αρχίζουμε να ψάχνουμε για προβλήματα. Εάν αντιμετωπίσαμε προβλήματα στο πρώτο μέρος, ξέρουμε ότι αυτός μπορεί να είναι ο λόγος για μια μακρά συναλλαγή και ανεβαίνουμε στο Master. Το πρόβλημα είναι με τον Δάσκαλο. Λουκάνικα τον. Κάνει ζέσταμα, έχει μέσο όρο φορτίου κάτω από εκατό.
- Τα αιτήματα επιβραδύνονται εκεί, αλλά δεν βλέπουμε μακροπρόθεσμες συναλλαγές εκεί. Και δεν καταλαβαίνουμε τι συμβαίνει. Δεν ξέρουμε πού να κοιτάξουμε.
- Έλεγχος υλικού διακομιστή. Ίσως η επιδρομή μας να έχει καταρρεύσει. Ίσως κάψαμε τη γραμμή μνήμης. Ναι, όλα μπορεί να είναι. Αλλά όχι, οι διακομιστές είναι νέοι, όλα λειτουργούν καλά.
- Όλοι τρέχουν: διαχειριστές, προγραμματιστές και διευθυντής. Τίποτα δεν βοηθάει.
- Και κάποια στιγμή, όλα αρχίζουν ξαφνικά να διορθώνονται.
Στη ρεπλίκα, εκείνη την ώρα, το αίτημα λύθηκε και έφυγε. Λάβαμε αναφορά. Η επιχείρηση είναι ακόμα χαρούμενη. Όπως βλέπετε, το τραπέζι μας μεγάλωσε ξανά και δεν πρόκειται να μειωθεί. Στο γράφημα με τις περιόδους σύνδεσης, άφησα ένα κομμάτι αυτής της μεγάλης συναλλαγής από το αντίγραφο, ώστε να μπορείτε να αξιολογήσετε πόσος χρόνος χρειάζεται μέχρι να σταθεροποιηθεί η κατάσταση.
Η συνεδρία έχει φύγει. Και μόνο μετά από κάποιο χρονικό διάστημα ο διακομιστής έρχεται λίγο πολύ σε τάξη. Και ο μέσος χρόνος απόκρισης για αιτήματα στον κύριο διακομιστή επιστρέφει στο κανονικό. Επειδή, τελικά, η αυτόματη σκούπα είχε την ευκαιρία να καθαρίσει, να σημειώσει αυτές τις προθεσμίες. Και άρχισε να κάνει τη δουλειά του. Και πόσο γρήγορα το κάνει, τόσο γρήγορα θα είμαστε σε τάξη.
Στον πίνακα δοκιμών, όπου ενημερώνουμε τα υπόλοιπα των λογαριασμών, βλέπουμε ακριβώς την ίδια εικόνα. Ο μέσος χρόνος ενημέρωσης λογαριασμού κανονικοποιείται επίσης σταδιακά. Οι πόροι που καταναλώνει ο επεξεργαστής μειώνονται επίσης. Και ο αριθμός των συναλλαγών ανά δευτερόλεπτο επέστρεψε στο κανονικό. Αλλά και πάλι, επιστροφή στο κανονικό, όχι όπως είχαμε πριν το ατύχημα.
Σε κάθε περίπτωση, έχουμε μείωση στην απόδοση, όπως στην πρώτη περίπτωση, μιάμιση έως δύο φορές, και μερικές φορές ακόμη περισσότερο.
Φαίνεται ότι τα έχουμε κάνει όλα σωστά. Κατανείμετε το φορτίο. Ο εξοπλισμός δεν είναι αδρανής. Σύμφωνα με το μυαλό, έσπασαν τα αιτήματα, αλλά και πάλι όλα πήγαν άσχημα.
- Δεν ενεργοποιείτε το hot_standby_feedback; Ναι, δεν συνιστάται να το ενεργοποιήσετε χωρίς ιδιαίτερα ισχυρούς λόγους. Επειδή αυτή η ανατροπή επηρεάζει άμεσα τον κύριο διακομιστή και αναστέλλει τη λειτουργία του αυτόματου κενού εκεί. Ενεργοποιώντας το σε κάποιο αντίγραφο και ξεχνώντας το, μπορείτε να σκοτώσετε τον Master και να αντιμετωπίσετε μεγάλα προβλήματα με την εφαρμογή.
- Αύξηση max_standby_streaming_delay; Ναι, για αναφορές είναι. Εάν έχετε μια αναφορά τριών ωρών και δεν θέλετε να διακοπεί λόγω διενέξεων αναπαραγωγής, τότε απλώς αυξήστε την καθυστέρηση. Μια εκτενής αναφορά δεν απαιτεί ποτέ δεδομένα που έχουν εισέλθει στη βάση δεδομένων αυτήν τη στιγμή. Εάν το έχετε για τρεις ώρες, τότε το χρησιμοποιείτε για κάποια παλιά περίοδο δεδομένων. Και εσείς, αυτές οι τρεις ώρες καθυστέρηση, αυτές οι έξι ώρες καθυστέρηση - δεν θα παίξετε κανένα ρόλο, αλλά θα λαμβάνετε αναφορές με συνέπεια και δεν θα γνωρίζετε τα προβλήματα με την πτώση τους.
- Φυσικά, πρέπει να ελέγχετε μεγάλες περιόδους σύνδεσης σε αντίγραφα, ειδικά εάν αποφασίσετε να ενεργοποιήσετε το hot_standby_feedback σε ένα αντίγραφο. Γιατί μπορεί να είναι οτιδήποτε. Δώσαμε αυτήν την παρατήρηση στον προγραμματιστή για να δοκιμάσει τα αιτήματα. Έγραψε ένα τρελό αίτημα. Ξεκίνησε και πήγε να πιει τσάι, και πήραμε τον καθιερωμένο Δάσκαλο. Ή ξεκινήσαμε τη λάθος εφαρμογή εκεί. Οι καταστάσεις ποικίλλουν. Οι συνεδρίες σε αντίγραφα πρέπει να ελέγχονται τόσο προσεκτικά όσο και στο Master.
- Και αν έχετε γρήγορες και μεγάλες απορίες για αντίγραφα, τότε σε αυτήν την περίπτωση είναι καλύτερο να τα χωρίσετε για να κατανείμετε το φορτίο. Αυτός είναι ένας σύνδεσμος για το streaming_delay. Για γρήγορο να έχετε ένα αντίγραφο με μικρή καθυστέρηση αναπαραγωγής. Για μακροχρόνια αιτήματα αναφοράς, έχετε ένα αντίγραφο που μπορεί να καθυστερήσει κατά 6 ώρες, ανά ημέρα. Αυτή είναι μια απολύτως φυσιολογική κατάσταση.
Εξαλείφουμε τις συνέπειες με τον ίδιο τρόπο:
- Βρίσκουμε φουσκωμένα τραπέζια.
- Και συμπιέζουμε με το πιο βολικό εργαλείο που μας ταιριάζει.
Η δεύτερη ιστορία τελειώνει εδώ. Ας περάσουμε στην τρίτη ιστορία.
Επίσης αρκετά συνηθισμένο για εμάς, στο οποίο κάνουμε τη μετανάστευση.
- Οποιοδήποτε προϊόν λογισμικού μεγαλώνει. Οι απαιτήσεις αλλάζουν. Σε κάθε περίπτωση, θέλουμε να εξελιχθούμε. Και συμβαίνει ότι πρέπει να ενημερώσουμε τα δεδομένα στον πίνακα, δηλαδή να εκτελέσουμε την ενημέρωση όσον αφορά τη μετεγκατάστασή μας στη νέα λειτουργικότητα που υλοποιούμε ως μέρος της ανάπτυξής μας.
- Η παλιά μορφή δεδομένων δεν ταιριάζει. Ας υποθέσουμε ότι τώρα στραφούμε στον δεύτερο πίνακα, όπου έχω πράξεις σε αυτούς τους λογαριασμούς. Και, ας πούμε ότι ήταν σε ρούβλια, και αποφασίσαμε να αυξήσουμε την ακρίβεια και να το κάνουμε σε καπίκια. Και για αυτό πρέπει να κάνουμε μια ενημέρωση: πολλαπλασιάστε το πεδίο με το ποσό της πράξης επί εκατό.
- Στον σημερινό κόσμο, χρησιμοποιούμε αυτοματοποιημένα εργαλεία έκδοσης βάσεων δεδομένων. Ας πούμε . Καταγράφουμε εκεί τη μετανάστευση. Το δοκιμάζουμε στη βάση δοκιμών μας. Ολα ειναι καλά. Η ενημέρωση εκτελείται. Τα μπλοκ λειτουργούν για λίγο, αλλά λαμβάνουμε ενημερωμένα δεδομένα. Και μπορούμε να ξεκινήσουμε νέα λειτουργικότητα σε αυτό. Όλα ελεγμένα και ελεγμένα. Όλα επιβεβαιωμένα.
- Πραγματοποίησε προγραμματισμένες εργασίες, πραγματοποίησε μετανάστευση.
Εδώ είναι η μετεγκατάσταση με την ενημέρωση που παρουσιάζεται μπροστά σας. Εφόσον έχω επεμβάσεις σε λογαριασμούς, το πιάτο ήταν 15 GB. Και δεδομένου ότι ενημερώνουμε κάθε γραμμή, έχουμε διπλασιάσει την πινακίδα με την ενημέρωση, επειδή έχουμε αντικαταστήσει κάθε γραμμή.
Κατά τη διάρκεια της μετεγκατάστασης, δεν μπορούσαμε να κάνουμε τίποτα με αυτήν την ετικέτα, επειδή όλα τα αιτήματα για αυτήν ήταν στην ουρά και περίμεναν να ολοκληρωθεί αυτή η ενημέρωση. Αλλά εδώ θέλω να επιστήσω την προσοχή σας στους αριθμούς που βρίσκονται στον κατακόρυφο άξονα. Δηλαδή, έχουμε ένα μέσο χρόνο αιτήματος πριν από τη μετεγκατάσταση στην περιοχή των 5 χιλιοστών του δευτερολέπτου και ένα φορτίο στον επεξεργαστή, ο αριθμός των λειτουργιών μπλοκ για την ανάγνωση της μνήμης του δίσκου είναι μικρότερος από 7,5.
Μεταναστεύσαμε και αντιμετωπίσαμε ξανά προβλήματα.
Η μετεγκατάσταση ήταν επιτυχής, αλλά:
- Η παλιά λειτουργικότητα άρχισε να λειτουργεί περισσότερο.
- Το τραπέζι μεγάλωσε ξανά σε μέγεθος.
- Το φόρτο στον διακομιστή έγινε ξανά περισσότερο από ό,τι ήταν.
- Και, φυσικά, ακόμα ασχολούμαστε με τη λειτουργικότητα που λειτούργησε καλά, τη βελτιώσαμε λίγο.
Και αυτό είναι πάλι φούσκωμα, που πάλι μας χαλάει τη ζωή.
Εδώ αποδεικνύω ότι ο πίνακας, όπως και οι δύο προηγούμενες περιπτώσεις, δεν πρόκειται να επιστρέψει στα προηγούμενα μεγέθη. Το μέσο φόρτο στον διακομιστή φαίνεται να είναι επαρκές.
Και αν στραφούμε στον πίνακα με τους λογαριασμούς, τότε θα δούμε ότι ο μέσος χρόνος αιτήματος έχει διπλασιαστεί για αυτόν τον πίνακα. Το φορτίο στον επεξεργαστή και ο αριθμός των γραμμών που έπρεπε να ταξινομηθούν στη μνήμη ανέβηκε πάνω από 7,5, αλλά ήταν χαμηλότερος. Και πηδήσαμε στην περίπτωση των επεξεργαστών κατά 2 φορές, στην περίπτωση των λειτουργιών μπλοκ κατά 1,5 φορές, δηλαδή είχαμε υποβάθμιση στην απόδοση του διακομιστή. Και ως αποτέλεσμα - η υποβάθμιση της απόδοσης της εφαρμογής μας. Ταυτόχρονα, ο αριθμός των κλήσεων παρέμεινε περίπου στα ίδια επίπεδα.
Και εδώ το κύριο πράγμα είναι να καταλάβουμε πώς να κάνουμε σωστά τέτοιες μεταναστεύσεις. Και πρέπει να γίνουν. Κάνουμε αυτές τις μεταναστεύσεις αρκετά τακτικά.
- Τέτοιες μεγάλες μεταναστεύσεις δεν γίνονται αυτόματα. Πρέπει πάντα να ελέγχονται.
- Χρειάζεται επίβλεψη από ενημερωμένο άτομο. Εάν έχετε DBA στην ομάδα, αφήστε το DBA να το κάνει. Είναι η δουλειά του. Αν όχι, αφήστε τον πιο έμπειρο να το κάνει, που ξέρει πώς να δουλεύει με βάσεις δεδομένων.
- Το νέο σχήμα βάσης δεδομένων, ακόμα κι αν ενημερώσουμε μία στήλη, προετοιμάζουμε πάντα σταδιακά, δηλαδή εκ των προτέρων πριν κυκλοφορήσει η νέα έκδοση της εφαρμογής:
- Προστίθενται νέα πεδία στα οποία θα γράψουμε μόνο τα ενημερωμένα δεδομένα.
- Μεταφέρουμε δεδομένα από το παλιό πεδίο στο νέο πεδίο σε μικρά κομμάτια. Γιατί το κάνουμε αυτό; Πρώτον, ελέγχουμε πάντα τη διαδικασία αυτής της διαδικασίας. Ξέρουμε ότι έχουμε ήδη μεταφέρει τόσες παρτίδες και μας έχουν μείνει τόσες.
- Και το δεύτερο θετικό αποτέλεσμα είναι ότι μεταξύ κάθε παρτίδας κλείνουμε μια συναλλαγή, ανοίγουμε μια καινούργια, και αυτό καθιστά δυνατό το autovacuum να λειτουργεί σύμφωνα με την πλάκα, να επισημαίνει τις προθεσμίες για επαναχρησιμοποίηση.
- Για τις γραμμές που θα εμφανιστούν κατά τη λειτουργία της εφαρμογής (έχουμε ακόμα την παλιά εφαρμογή), προσθέτουμε ένα έναυσμα που γράφει νέες τιμές σε νέα πεδία. Στην περίπτωσή μας, αυτός είναι πολλαπλασιασμός επί εκατό της παλιάς τιμής.
- Αν είμαστε τελείως πεισματάρηδες και θέλουμε το ίδιο πεδίο, τότε με την ολοκλήρωση όλων των μετεγκατάστασης και πριν βάλουμε τη νέα έκδοση της εφαρμογής, απλά μετονομάζουμε τα πεδία. Τα παλιά σε κάποιο επινοημένο όνομα και μετονομάζουμε τα νέα πεδία στα παλιά.
- Και μόνο μετά από αυτό ξεκινάμε μια νέα έκδοση της εφαρμογής.
Και ταυτόχρονα, δεν θα φουσκώσουμε και δεν θα χαλάσουμε στην απόδοση.
Αυτό είναι το τέλος της τρίτης ιστορίας.
Και τώρα λίγα περισσότερα για τα εργαλεία που ανέφερα στην πρώτη κιόλας ιστορία.
Πριν αναζητήσετε bloat, πρέπει να εγκαταστήσετε την επέκταση .
Για να μην επινοείτε αιτήματα, έχουμε ήδη γράψει αυτά τα αιτήματα στη δουλειά μας. Μπορείτε να τα χρησιμοποιήσετε. Υπάρχουν δύο αιτήματα εδώ.
- Το πρώτο παίρνει πολύ χρόνο, αλλά θα σας δείξει τις ακριβείς τιμές του φουσκώματος σύμφωνα με τον πίνακα.
- Το δεύτερο λειτουργεί πιο γρήγορα και είναι πολύ αποτελεσματικό όταν πρέπει να αξιολογήσετε γρήγορα αν υπάρχει φούσκωμα ή όχι στον πίνακα. Και πρέπει επίσης να καταλάβετε ότι υπάρχει πάντα ένα φούσκωμα σε ένα τραπέζι Postgres. Αυτό είναι ένα χαρακτηριστικό του μοντέλου MVCC του.
- Και το φούσκωμα 20% είναι καλό για τραπέζια στις περισσότερες περιπτώσεις. Δηλαδή, δεν πρέπει να ανησυχείτε και να συμπιέσετε αυτόν τον πίνακα.
Καταλάβαμε πώς να αναγνωρίσουμε τους πίνακες που είναι διογκωμένοι μαζί μας, επιπλέον, όταν είναι διογκωμένοι με άχρηστα δεδομένα.
Τώρα για το πώς να διορθώσετε το φούσκωμα:
- Αν έχουμε ένα μικρό πιάτο και καλούς δίσκους, δηλαδή σε ένα πιάτο μέχρι ένα gigabyte, είναι πολύ πιθανό να χρησιμοποιήσουμε VACUUM FULL. Θα σου πάρει αποκλειστική κλειδαριά για λίγα δευτερόλεπτα και εντάξει, αλλά θα τα κάνει όλα γρήγορα και σκληρά. Τι κάνει το VACUUM FULL; Παίρνει ένα αποκλειστικό κλείδωμα στο τραπέζι και ξαναγράφει τις ζωντανές σειρές από τα παλιά τραπέζια στο νέο τραπέζι. Και στο τέλος τους αντικαθιστά. Διαγράφει παλιά αρχεία, αντικαθιστά νέα με παλιά. Αλλά για τη διάρκεια της δουλειάς του, χρειάζεται αποκλειστική κλειδαριά στο τραπέζι. Αυτό σημαίνει ότι δεν μπορείτε να κάνετε τίποτα με αυτόν τον πίνακα: ούτε να τον γράψετε, ούτε να τον διαβάσετε, ούτε να τον τροποποιήσετε. Και το VACUUM FULL απαιτεί επιπλέον χώρο στο δίσκο για την εγγραφή δεδομένων.
- Επόμενο εργαλείο . Από την αρχή του, μοιάζει πολύ με το VACUUM FULL, γιατί αντικαθιστά επίσης δεδομένα από παλιά αρχεία σε νέα και τα αντικαθιστά στον πίνακα. Αλλά ταυτόχρονα, δεν παίρνει αποκλειστικό κλείδωμα στο τραπέζι στην αρχή της δουλειάς του, αλλά το παίρνει μόνο τη στιγμή που έχει έτοιμα δεδομένα για να αντικαταστήσει τα αρχεία. Έχει τις ίδιες απαιτήσεις σε πόρους δίσκου με το VACUUM FULL. Χρειάζεστε επιπλέον χώρο στο δίσκο και αυτό είναι μερικές φορές κρίσιμο εάν έχετε πίνακες terabyte. Και είναι αρκετά αδηφάγος στον επεξεργαστή, επειδή εργάζεται ενεργά με I/O.
- Η τρίτη χρησιμότητα είναι . Αντιμετωπίζει τους πόρους πιο προσεκτικά, επειδή λειτουργεί με ελαφρώς διαφορετικές αρχές. Η κύρια ουσία του pgcompacttable είναι ότι μετακινεί όλες τις ζωντανές σειρές στην αρχή του πίνακα με ενημερώσεις στον πίνακα. Και τότε ξεκινά το κενό σε αυτό το τραπέζι, γιατί ξέρουμε ότι έχουμε ζωντανές σειρές στην αρχή και νεκρές σειρές στο τέλος. Και το ίδιο το κενό κόβει αυτή την ουρά, δηλαδή δεν απαιτεί πολύ επιπλέον χώρο στο δίσκο. Και ταυτόχρονα, μπορεί ακόμα να συμπιεστεί από πόρους.
Όλα με εργαλεία.
Εάν βρίσκετε ενδιαφέρον το θέμα του bloat από την άποψη της περαιτέρω αναζήτησης προς τα μέσα, τότε εδώ είναι μερικοί χρήσιμοι σύνδεσμοι για εσάς:
- είναι η αναφορά του συναδέλφου μου. Είναι γενικό για το πού πάει η θέση της Postgres στην πορεία της δουλειάς και της ζωής της. Και υπάρχει ένα πολύ μεγάλο και λεπτομερές τεχνικό κομμάτι για DBA σχετικά με το bloat.
- είναι ένας σύνδεσμος προς το αποθετήριο μας, όπου αποθηκεύουμε ένα σωρό χρήσιμα σενάρια για τον έλεγχο της κατάστασης της βάσης δεδομένων. Εκεί μπορείτε να βρείτε σενάρια αναζήτησης bloat.
- и συνδέσμους σε εργαλεία που θα σας βοηθήσουν να συμπιέσετε τις πλάκες.
- Αυτή είναι μια ανάρτηση από τον συνάδελφό μου. Εκεί αναλύει αρκετά σοβαρά και τεχνικά το bloat με λεπτομέρεια ήδη σε επίπεδο κοντά στους διαχειριστές.
Εδώ προσπάθησα να δείξω μια ιστορία τρόμου για προγραμματιστές, επειδή είναι οι άμεσοι πελάτες μας των βάσεων δεδομένων και πρέπει να καταλάβουν σε τι και σε ποιες ενέργειες οδηγούν. Ελπίζω να τα κατάφερα. Σας ευχαριστώ για την προσοχή σας!
ερωτήσεις
Ευχαριστώ για την αναφορά! Μιλήσατε για το πώς μπορούν να εντοπιστούν τα προβλήματα. Πώς μπορούν να προειδοποιηθούν; Δηλαδή, είχα μια κατάσταση όπου τα αιτήματα κολλούσαν όχι μόνο επειδή στράφηκαν σε κάποιες εξωτερικές υπηρεσίες. Ήταν απλώς κάποιες άγριες ενώσεις. Υπήρχαν μερικά μικροσκοπικά, ακίνδυνα αιτήματα που τριγυρνούσαν για μια μέρα και μετά άρχισαν να κάνουν κάποιου είδους ανοησίες. Δηλαδή μοιάζει πολύ με αυτό που περιγράφεις. Πώς να το παρακολουθήσετε; Καθίστε και παρακολουθείτε συνεχώς, ποιο αίτημα έχει κολλήσει; Πώς μπορεί να αποτραπεί αυτό;
Σε αυτήν την περίπτωση, αυτό είναι μια εργασία για τους διαχειριστές της εταιρείας σας, όχι απαραίτητα για το DBA.
Είμαι διαχειριστής.
Η PostgreSQL έχει μια προβολή που ονομάζεται pg_stat_activity που εμφανίζει ερωτήματα σε εκκρεμότητα. Και μπορείτε να δείτε πόσο καιρό κρέμεται εκεί.
Πρέπει να μπαίνω κάθε 5 λεπτά και να κοιτάζω;
Ρυθμίστε το cron και ελέγξτε. Εάν έχετε ένα μεγάλο αίτημα, γράψτε ένα γράμμα και αυτό είναι. Δηλαδή, δεν χρειάζεται να κοιτάτε με τα μάτια σας, αυτό μπορεί να αυτοματοποιηθεί. Θα λάβετε ένα γράμμα, θα απαντήσετε σε αυτό. Ή μπορείτε να πυροβολήσετε αυτόματα.
Υπάρχουν σαφείς λόγοι για τους οποίους συμβαίνει αυτό;
Έχω παραθέσει μερικά. Άλλα πιο σύνθετα παραδείγματα. Και μπορεί να γίνει μια μακρά συζήτηση.
Ευχαριστώ για την αναφορά! Ήθελα να διευκρινίσω το βοηθητικό πρόγραμμα pg_repack. Αν δεν χρειάζεται αποκλειστική κλειδαριά, τότε...
Φτιάχνει αποκλειστική κλειδαριά.
... τότε θα μπορούσα ενδεχομένως να χάσω δεδομένα. Δεν θα έπρεπε η εφαρμογή μου να καταγράφει κάτι αυτήν τη στιγμή;
Όχι, λειτουργεί αθόρυβα με τον πίνακα, δηλαδή το pg_repack μεταφέρει πρώτα όλες τις ζωντανές γραμμές που υπάρχουν εκεί. Φυσικά, υπάρχει κάποιο είδος ρεκόρ στον πίνακα σε εξέλιξη. Απλώς πετάει αυτή την αλογοουρά.
Δηλαδή το κάνει ακόμα στο τέλος;
Στο τέλος, απαιτείται αποκλειστικό κλείδωμα για την ανταλλαγή αυτών των αρχείων.
Θα είναι πιο γρήγορο από το VACUUM FULL;
VACUUM FULL, όπως ξεκίνησε, πήρε αμέσως αποκλειστικό κλείδωμα. Και μέχρι να τα κάνει όλα, δεν θα την αφήσει να φύγει. Και το pg_repack κλειδώνει αποκλειστικά μόνο τη στιγμή της αντικατάστασης των αρχείων. Σε αυτό το σημείο, δεν γράφετε εκεί, αλλά τα δεδομένα δεν θα χαθούν, όλα θα είναι σε τάξη.
Γειά σου! Μιλήσατε για το έργο του autovacuum. Υπήρχε ένα γράφημα με κόκκινα, κίτρινα και πράσινα κελιά του δίσκου. Δηλαδή κίτρινα - τα σημείωσε ως διαγραμμένα. Και ως αποτέλεσμα, μπορείτε να γράψετε κάτι νέο σε αυτά;
Ναί. Το Postgres δεν αφαιρεί σειρές. Έχει μια τέτοια ιδιαιτερότητα. Εάν ενημερώσαμε τη γραμμή, επισημάναμε την παλιά ως διαγραμμένη. Το αναγνωριστικό συναλλαγής που άλλαξε αυτή τη γραμμή εμφανίζεται εκεί και γράφουμε μια νέα γραμμή. Και έχουμε συνεδρίες που μπορούν ενδεχομένως να τις διαβάσουν. Κάποια στιγμή γερνούν αρκετά. Και η ουσία του autovacuum είναι ότι περνά μέσα από αυτές τις γραμμές και τις επισημαίνει ως περιττές. Και εκεί μπορείτε να αντικαταστήσετε τα δεδομένα.
Καταλαβαίνω. Αλλά το ερώτημα δεν αφορά αυτό. Δεν συμφωνούσα. Ας πούμε ότι έχουμε ένα τραπέζι. Διαθέτει πεδία μεταβλητού μεγέθους. Και αν προσπαθήσω να εισάγω κάτι νέο, τότε μπορεί απλά να μην ταιριάζει στο παλιό κελί.
Όχι, σε κάθε περίπτωση, ολόκληρη η γραμμή ενημερώνεται. Η Postgres διαθέτει δύο μοντέλα αποθήκευσης. Επιλέγει από τον τύπο δεδομένων. Υπάρχουν δεδομένα που αποθηκεύονται απευθείας στον πίνακα, και υπάρχουν επίσης δεδομένα tos. Πρόκειται για μεγάλες ποσότητες δεδομένων: κείμενο, json. Αποθηκεύονται σε ξεχωριστά δισκία. Και σύμφωνα με αυτές τις ταμπλέτες, η ίδια ιστορία με το bloat συμβαίνει, δηλαδή όλα είναι ίδια. Απλώς αναφέρονται ξεχωριστά.
Ευχαριστώ για την αναφορά! Πόσο αποδεκτό είναι να χρησιμοποιείτε αιτήματα λήξης χρονικού ορίου δήλωσης για τον περιορισμό της διάρκειας;
Πολύ αποδεκτό. Το χρησιμοποιούμε παντού. Και επειδή δεν έχουμε τις δικές μας υπηρεσίες, παρέχουμε απομακρυσμένη υποστήριξη, υπάρχει μεγάλη ποικιλία πελατών. Και όλοι είναι αρκετά ικανοποιημένοι με αυτό. Δηλαδή, έχουμε δουλειές στο cron that check. Απλώς η διάρκεια των συνεδριών διαπραγματεύεται με τον πελάτη, πριν από την οποία δεν καρφώνουμε. Μπορεί να είναι ένα λεπτό, μπορεί να είναι 10 λεπτά. Εξαρτάται από το φορτίο στη βάση και τον σκοπό της. Αλλά όλοι χρησιμοποιούμε το pg_stat_activity.
Ευχαριστώ για την αναφορά! Προσπαθώ να δοκιμάσω την αναφορά σας για τις εφαρμογές μου. Και φαίνεται ότι ξεκινάμε μια συναλλαγή παντού, και την ολοκληρώνουμε ρητά παντού. Εάν κάποια εξαίρεση, τότε συμβαίνει η ίδια επαναφορά. Και μετά σκέφτηκα. Μετά από όλα, η συναλλαγή μπορεί να ξεκινήσει όχι ρητά. Αυτό είναι μια υπόδειξη για το κορίτσι, υποθέτω. Εάν κάνω απλώς μια ενημέρωση εγγραφής, η συναλλαγή θα ξεκινήσει στην PostgreSQL και θα τελειώσει μόνο όταν αποσυνδεθεί η σύνδεση;
Αν τώρα μιλάτε για το επίπεδο εφαρμογής, τότε εξαρτάται από το πρόγραμμα οδήγησης που χρησιμοποιείτε, από το ORM που χρησιμοποιείται. Υπάρχουν πολλές ρυθμίσεις εκεί. Εάν έχετε ενεργοποιημένη την αυτόματη δέσμευση, τότε μια συναλλαγή ξεκινά εκεί και κλείνει αμέσως.
Δηλαδή κλείνει αμέσως μετά την ενημέρωση;
Εξαρτάται από τις ρυθμίσεις. Ονόμασα μια ρύθμιση. Αυτό είναι αυτόματη δέσμευση. Είναι αρκετά συνηθισμένη. Εάν είναι ενεργοποιημένο, τότε η συναλλαγή άνοιξε και έκλεισε. Εκτός και αν είπατε ρητά "έναρξη συναλλαγής" και "ολοκλήρωση συναλλαγής", αλλά απλά ξεκινήσατε ένα αίτημα στη συνεδρία.
Γειά σου! Ευχαριστώ για την αναφορά! Φανταστείτε ότι έχουμε μια βάση δεδομένων που διογκώνεται και διογκώνεται και μετά εξαντλείται ο χώρος του διακομιστή. Υπάρχουν εργαλεία για να διορθώσετε αυτήν την κατάσταση;
Η θέση στον διακομιστή με καλό τρόπο πρέπει να παρακολουθείται.
Για παράδειγμα, η DBA πήγε να πιει τσάι, ήταν σε ένα θέρετρο κ.λπ.
Όταν δημιουργείται ένα σύστημα αρχείων, δημιουργείται τουλάχιστον ένας αποθεματικός χώρος όπου τα δεδομένα δεν είναι γραμμένα.
Τι γίνεται αν είναι εντελώς μηδέν;
Εκεί λέγεται δεσμευμένος χώρος, δηλαδή μπορεί να ελευθερωθεί και ανάλογα με το πόσο μεγάλος δημιουργήθηκε, πήρες ελεύθερο χώρο. Από προεπιλογή, δεν ξέρω πόσοι είναι. Και σε μια άλλη περίπτωση, παραδώστε δίσκους ώστε να έχετε ένα μέρος για να πραγματοποιήσετε μια λειτουργία ανάκτησης. Μπορείτε να διαγράψετε έναν πίνακα που είναι σίγουρο ότι δεν χρειάζεστε.
Δεν υπάρχουν άλλα εργαλεία;
Είναι πάντα χειροποίητο. Και στον τόπο αποκαλύπτεται τι είναι καλύτερο να κάνουμε εκεί, γιατί υπάρχουν δεδομένα που είναι κρίσιμα, υπάρχουν μη κρίσιμα. Και για κάθε βάση δεδομένων και εφαρμογή που λειτουργεί με αυτήν, εξαρτάται από την επιχείρηση. Πάντα αποφασίζεται επί τόπου.
Ευχαριστώ για την αναφορά! Έχω δύο ερωτήσεις. Αρχικά, δείξατε διαφάνειες όπου φάνηκε ότι στην περίπτωση των αναρτημένων συναλλαγών, τόσο ο χώρος του τραπεζιού όσο και το μέγεθος του ευρετηρίου αυξάνονται. Και περαιτέρω στην αναφορά, υπήρχαν ένα σωρό βοηθητικά προγράμματα που συσκευάζουν το tablet. Και τι γίνεται με τον δείκτη;
Τα πακετάρουν κι αυτά.
Αλλά το κενό δεν επηρεάζει τον δείκτη;
Μερικοί λειτουργούν με ένα ευρετήριο. Για παράδειγμα pg_rapack, pgcompacttable. Το κενό αναδημιουργεί δείκτες, τους επηρεάζει. Το VACUUM FULL έχει την ουσία της αντικατάστασης των πάντων, δηλαδή λειτουργεί με όλους.
Και η δεύτερη ερώτηση. Δεν κατάλαβα γιατί οι αναφορές για τα αντίγραφα εξαρτώνται τόσο πολύ από την ίδια την αναπαραγωγή. Μου φάνηκε ότι οι αναφορές διαβάζουν και η αναπαραγωγή είναι η γραφή.
Τι προκαλεί μια σύγκρουση αναπαραγωγής; Έχουμε έναν Δάσκαλο στον οποίο πραγματοποιούνται διαδικασίες. Έχουμε αυτόματη σκούπα. Αυτόματη σκούπα στην πραγματικότητα, τι κάνει; Κόβει μερικές παλιές γραμμές. Εάν αυτή τη στιγμή έχουμε ένα αίτημα για το αντίγραφο που διαβάζει αυτές τις παλιές γραμμές, και στο Master υπήρχε μια κατάσταση όπου το autovacuum επισήμανε αυτές τις γραμμές ως δυνατές για επανεγγραφή, τότε τις αντικαταστήσαμε. Και λάβαμε ένα πακέτο δεδομένων, όταν πρέπει να ξαναγράψουμε τις γραμμές που χρειάζεται το αίτημα στο αντίγραφο, τότε η διαδικασία αναπαραγωγής θα περιμένει το χρονικό όριο που ρυθμίσατε. Και τότε η PostgreSQL θα αποφασίσει τι είναι πιο σημαντικό για αυτήν. Και η αναπαραγωγή είναι πιο σημαντική γι 'αυτόν από ένα αίτημα, και θα πυροβολήσει το αίτημα για να κάνει αυτές τις αλλαγές στο αντίγραφο.
Ανδρέα, έχω μια ερώτηση. Αυτά τα υπέροχα γραφικά που δείξατε κατά τη διάρκεια της παρουσίασης, είναι αποτέλεσμα κάποιας δουλειάς σας; Πώς φτιάχτηκαν τα charts;
Αυτή είναι μια υπηρεσία .
Αυτό είναι εμπορικό προϊόν;
Ναί. Αυτό είναι ένα εμπορικό προϊόν.
Πηγή: www.habr.com