Προτείνω να εξοικειωθείτε με το αντίγραφο της αναφοράς του Alexey Lesovsky από το Data Egret "Basics of PostgreSQL Monitoring"
Σε αυτήν την έκθεση, ο Alexey Lesovsky θα μιλήσει για τα βασικά σημεία των στατιστικών postgres, τι σημαίνουν και γιατί πρέπει να περιλαμβάνονται στην παρακολούθηση. σχετικά με τα διαγράμματα που πρέπει να υπάρχουν στην παρακολούθηση, πώς να τα προσθέσετε και πώς να ερμηνεύσετε. Η αναφορά θα είναι χρήσιμη για διαχειριστές βάσεων δεδομένων, διαχειριστές συστήματος και προγραμματιστές που ενδιαφέρονται για την αντιμετώπιση προβλημάτων Postgres.
Το όνομά μου είναι Alexey Lesovsky, εκπροσωπώ την Data Egret.
Λίγα λόγια για τον εαυτό μου. Ξεκίνησα εδώ και πολύ καιρό ως διαχειριστής συστήματος.
Διαχειριζόμουν κάθε λογής διαφορετικά Linux, έκανα διάφορα πράγματα σχετικά με το Linux, δηλαδή εικονικοποίηση, παρακολούθηση, δούλεψα με proxies κλπ. Αλλά κάποια στιγμή ασχολήθηκα περισσότερο με βάσεις δεδομένων, PostgreSQL. Μου άρεσε πολύ. Και κάποια στιγμή, άρχισα να ασχολούμαι με την PostgreSQL το μεγαλύτερο μέρος του χρόνου εργασίας μου. Και έτσι σταδιακά έγινα PostgreSQL DBA.
Και σε όλη τη διάρκεια της καριέρας μου, πάντα με ενδιέφεραν τα θέματα της στατιστικής, της παρακολούθησης, της τηλεμετρίας. Και όταν ήμουν διαχειριστής συστήματος, δούλευα πολύ σκληρά στο Zabbix. Και έγραψε ένα μικρό σύνολο σεναρίων όπως . Ήταν αρκετά δημοφιλής στην εποχή του. Και εκεί ήταν δυνατή η παρακολούθηση πολύ διαφορετικών σημαντικών πραγμάτων, όχι μόνο Linux, αλλά και διαφόρων στοιχείων.
Τώρα κάνω ήδη PostgreSQL. Γράφω ήδη ένα άλλο πράγμα που σας επιτρέπει να εργαστείτε με στατιστικά PostgreSQL. Ονομάζεται (άρθρο στο Habré - ).
Μια μικρή εισαγωγή. Ποιες είναι οι καταστάσεις με τους πελάτες μας, με τους πελάτες μας; Υπάρχει κάποιο είδος ατυχήματος που σχετίζεται με τη βάση δεδομένων. Και όταν η βάση δεδομένων έχει ήδη αποκατασταθεί, έρχεται ο επικεφαλής του τμήματος ή ο υπεύθυνος ανάπτυξης και λέει: «Φίλοι, πρέπει να παρακολουθούμε τη βάση δεδομένων, γιατί συνέβη κάτι κακό και είναι απαραίτητο να μην συμβεί αυτό στο μέλλον». Και εδώ ξεκινά η ενδιαφέρουσα διαδικασία επιλογής ενός συστήματος παρακολούθησης ή προσαρμογής ενός υπάρχοντος συστήματος παρακολούθησης, ώστε να μπορείτε να παρακολουθείτε τη βάση δεδομένων σας - PostgreSQL, MySQL ή κάποια άλλα. Και οι συνάδελφοι αρχίζουν να προσφέρουν: «Άκουσα ότι υπάρχει τέτοια και τέτοια βάση δεδομένων. Ας το χρησιμοποιήσουμε». Οι συνάδελφοι αρχίζουν να μαλώνουν μεταξύ τους. Και στο τέλος, αποδεικνύεται ότι επιλέγουμε κάποιο είδος βάσης δεδομένων, αλλά η παρακολούθηση PostgreSQL εκπροσωπείται μάλλον ελάχιστα σε αυτήν και πρέπει πάντα να τελειώνουμε κάτι. Πάρτε μερικά αποθετήρια από το GitHub, κλωνοποιήστε τα, προσαρμόστε σενάρια, συντονίστε τα με κάποιο τρόπο. Και στο τέλος πέφτει έξω σε κάποιου είδους χειρωνακτική εργασία.
Επομένως, σε αυτήν την αναφορά, θα προσπαθήσω να σας δώσω κάποιες γνώσεις για το πώς να επιλέξετε παρακολούθηση όχι μόνο για την PostgreSQL, αλλά και για τη βάση δεδομένων. Και για να δώσετε τη γνώση που θα σας επιτρέψει να ολοκληρώσετε την παρακολούθησή σας για να επωφεληθείτε από αυτήν, ώστε να μπορείτε να παρακολουθείτε τη βάση δεδομένων σας με όφελος προκειμένου να αποτρέψετε τυχόν επερχόμενες καταστάσεις έκτακτης ανάγκης που μπορεί να προκύψουν εγκαίρως.
Και αυτές οι ιδέες που θα περιλαμβάνονται σε αυτήν την αναφορά, μπορούν να προσαρμοστούν απευθείας σε οποιαδήποτε βάση δεδομένων, είτε πρόκειται για DBMS είτε για noSQL. Επομένως, όχι μόνο η PostgreSQL εδώ, αλλά θα υπάρχουν πολλές συνταγές για το πώς να το κάνετε αυτό στο PostgreSQL. Θα υπάρχουν παραδείγματα ερωτημάτων, παραδείγματα οντοτήτων που έχει η PostgreSQL για παρακολούθηση. Και αν το DBMS σας έχει τα ίδια πράγματα που σας επιτρέπουν να τα βάλετε σε παρακολούθηση, μπορείτε επίσης να τα προσαρμόσετε, να τα προσθέσετε και θα είναι εντάξει.
Δεν θα αναφέρω
μιλήστε για τον τρόπο παράδοσης και αποθήκευσης μετρήσεων. Δεν θα πω τίποτα για τα δεδομένα μετά την επεξεργασία και την παροχή τους στον χρήστη. Και δεν θα πω τίποτα για ειδοποίηση.
Αλλά στην πορεία της ιστορίας, θα δείξω διαφορετικά στιγμιότυπα από υπάρχουσες παρακολουθήσεις, με κάποιο τρόπο θα τις επικρίνω. Παρόλα αυτά, θα προσπαθήσω να μην αναφέρω επωνυμίες για να μην δημιουργήσω διαφήμιση ή αντιδιαφήμιση για αυτά τα προϊόντα. Επομένως, όλες οι συμπτώσεις είναι τυχαίες και παραμένουν στη φαντασία σας.
Αρχικά, ας καταλάβουμε τι είναι η παρακολούθηση. Η παρακολούθηση είναι πολύ σημαντικό πράγμα. Αυτό το καταλαβαίνουν όλοι. Ταυτόχρονα, όμως, η παρακολούθηση δεν σχετίζεται με ένα επιχειρηματικό προϊόν και δεν επηρεάζει άμεσα τα κέρδη της εταιρείας, επομένως δίνεται πάντα χρόνος στην παρακολούθηση σε υπολειπόμενη βάση. Αν έχουμε χρόνο, τότε ασχολούμαστε με την παρακολούθηση, αν δεν υπάρχει χρόνος, τότε ΟΚ, θα το βάλουμε στο υστέρημα και κάποια μέρα θα επιστρέψουμε σε αυτές τις εργασίες.
Επομένως, από την πρακτική μας, όταν ερχόμαστε σε πελάτες, η παρακολούθηση είναι συχνά ανεπαρκώς ανεπτυγμένη και δεν έχει ενδιαφέροντα πράγματα που θα μας βοηθούσαν να κάνουμε καλύτερη δουλειά με τη βάση δεδομένων. Και επομένως η παρακολούθηση πρέπει πάντα να ολοκληρώνεται.
Οι βάσεις δεδομένων είναι τόσο περίπλοκα πράγματα που πρέπει επίσης να παρακολουθείτε, επειδή οι βάσεις δεδομένων είναι μια αποθήκη πληροφοριών. Και οι πληροφορίες είναι πολύ σημαντικές για την εταιρεία, δεν μπορούν να χαθούν με κανέναν τρόπο. Αλλά ταυτόχρονα, οι βάσεις δεδομένων είναι πολύ περίπλοκα κομμάτια λογισμικού. Αποτελούνται από πολλά εξαρτήματα. Και πολλά από αυτά τα στοιχεία πρέπει να παρακολουθούνται.
Εάν μιλάμε συγκεκριμένα για το PostgreSQL, τότε μπορεί να αναπαρασταθεί ως ένα τέτοιο σχήμα, το οποίο αποτελείται από μεγάλο αριθμό στοιχείων. Αυτά τα συστατικά αλληλεπιδρούν μεταξύ τους. Ταυτόχρονα, η PostgreSQL διαθέτει το λεγόμενο υποσύστημα Stats Collector, το οποίο σας επιτρέπει να συλλέγετε στατιστικά στοιχεία σχετικά με τη λειτουργία αυτών των υποσυστημάτων και να παρέχετε μια διεπαφή στον διαχειριστή ή τον χρήστη ώστε να μπορεί να δει αυτά τα στατιστικά στοιχεία.
Αυτά τα στατιστικά στοιχεία παρουσιάζονται με τη μορφή ορισμένου συνόλου συναρτήσεων και προβολών (προβολή). Μπορούν επίσης να ονομαστούν τραπέζια. Δηλαδή, χρησιμοποιώντας έναν κανονικό πελάτη psql, μπορείτε να συνδεθείτε στη βάση δεδομένων, να επιλέξετε αυτές τις λειτουργίες και προβολές και να λάβετε ορισμένους συγκεκριμένους αριθμούς σχετικά με τη λειτουργία των υποσυστημάτων PostgreSQL.
Μπορείτε να προσθέσετε αυτούς τους αριθμούς στο αγαπημένο σας σύστημα παρακολούθησης, να σχεδιάσετε γραφήματα, να προσθέσετε λειτουργίες και να λάβετε αναλυτικά στοιχεία μακροπρόθεσμα.
Αλλά σε αυτήν την αναφορά, δεν θα καλύψω όλες αυτές τις λειτουργίες χωρίς εξαίρεση, γιατί μπορεί να διαρκέσει μια ολόκληρη μέρα. Θα αναφερθώ κυριολεκτικά σε δύο, τρία ή τέσσερα πράγματα και θα σας πω πώς βοηθούν στην καλύτερη παρακολούθηση.
Και αν μιλάμε για παρακολούθηση της βάσης δεδομένων, τότε τι πρέπει να παρακολουθείται; Πρώτα απ 'όλα, πρέπει να παρακολουθούμε τη διαθεσιμότητα, επειδή η βάση δεδομένων είναι μια υπηρεσία που παρέχει πρόσβαση στα δεδομένα στους πελάτες και πρέπει να παρακολουθούμε τη διαθεσιμότητα, καθώς και να παρέχουμε ορισμένα από τα ποιοτικά και ποσοτικά χαρακτηριστικά της.
Πρέπει επίσης να παρακολουθούμε τους πελάτες που συνδέονται με τη βάση δεδομένων μας, επειδή μπορεί να είναι τόσο κανονικοί πελάτες όσο και επιβλαβείς πελάτες που μπορεί να βλάψουν τη βάση δεδομένων. Πρέπει επίσης να παρακολουθούνται και να παρακολουθούνται.
Όταν οι πελάτες συνδέονται στη βάση δεδομένων, είναι προφανές ότι αρχίζουν να εργάζονται με τα δεδομένα μας, επομένως πρέπει να παρακολουθούμε πώς λειτουργούν οι πελάτες με δεδομένα: με ποιους πίνακες, σε μικρότερο βαθμό με ποιους ευρετήρια. Δηλαδή, πρέπει να αξιολογήσουμε τον φόρτο εργασίας που δημιουργείται από τους πελάτες μας.
Αλλά και ο φόρτος εργασίας συνίσταται, φυσικά, σε αιτήματα. Οι εφαρμογές συνδέονται με τη βάση δεδομένων, έχουν πρόσβαση σε δεδομένα χρησιμοποιώντας ερωτήματα, επομένως είναι σημαντικό να αξιολογήσουμε ποια ερωτήματα έχουμε στη βάση δεδομένων, να παρακολουθήσουμε την επάρκειά τους, ότι δεν είναι στραβά, ότι ορισμένες επιλογές πρέπει να ξαναγραφτούν και να γίνουν ώστε να λειτουργούν πιο γρήγορα και με καλύτερη απόδοση.
Και αφού μιλάμε για τη βάση δεδομένων, η βάση δεδομένων είναι πάντα διεργασίες παρασκηνίου. Οι διεργασίες παρασκηνίου διατηρούν την απόδοση της βάσης δεδομένων σε καλό επίπεδο, επομένως απαιτούν έναν ορισμένο αριθμό πόρων για την εκτέλεση τους. Ταυτόχρονα, μπορούν να επικαλύπτονται με πόρους αιτημάτων πελάτη, έτσι η άπληστη εργασία των διαδικασιών παρασκηνίου μπορεί να επηρεάσει άμεσα την απόδοση των αιτημάτων πελατών. Ως εκ τούτου, πρέπει επίσης να παρακολουθούνται και να παρακολουθούνται, ώστε να μην υπάρχουν στρεβλώσεις όσον αφορά τις διαδικασίες του παρασκηνίου.
Και αυτό είναι όλο όσον αφορά την παρακολούθηση της βάσης δεδομένων που παραμένει στη μέτρηση του συστήματος. Αλλά δεδομένου ότι ως επί το πλείστον ολόκληρη η υποδομή μας πηγαίνει στα σύννεφα, οι μετρήσεις συστήματος ενός μεμονωμένου κεντρικού υπολογιστή πάντα σβήνουν στο παρασκήνιο. Αλλά στις βάσεις δεδομένων, εξακολουθούν να είναι σχετικές και, φυσικά, είναι επίσης απαραίτητο να παρακολουθούνται οι μετρήσεις του συστήματος.
Με τις μετρήσεις συστήματος, όλα είναι λίγο πολύ καλά, όλα τα σύγχρονα συστήματα παρακολούθησης υποστηρίζουν ήδη αυτές τις μετρήσεις, αλλά γενικά, ορισμένα στοιχεία εξακολουθούν να μην είναι αρκετά και κάποια πράγματα πρέπει να προστεθούν. Θα τους αγγίξω επίσης, αρκετές διαφάνειες θα είναι για αυτές.
Το πρώτο σημείο του σχεδίου είναι η προσβασιμότητα. Τι είναι η προσβασιμότητα; Η διαθεσιμότητα κατά την κατανόηση μου είναι η ικανότητα της βάσης να εξυπηρετεί συνδέσεις, δηλαδή, η βάση ανυψώνεται, ως υπηρεσία δέχεται συνδέσεις από πελάτες. Και αυτή η προσβασιμότητα μπορεί να αξιολογηθεί από ορισμένα χαρακτηριστικά. Αυτά τα χαρακτηριστικά είναι πολύ βολικά για εμφάνιση στους πίνακες εργαλείων.
Όλοι γνωρίζουν τι είναι τα ταμπλό. Τότε ήταν που ρίξατε μια ματιά στην οθόνη, η οποία συνόψιζε τις απαραίτητες πληροφορίες. Και μπορείτε ήδη να προσδιορίσετε αμέσως εάν υπάρχει πρόβλημα στη βάση δεδομένων ή όχι.
Αντίστοιχα, η διαθεσιμότητα της βάσης δεδομένων και άλλα βασικά χαρακτηριστικά θα πρέπει πάντα να τοποθετούνται στους πίνακες εργαλείων, ώστε αυτές οι πληροφορίες να είναι πάντα κοντά σας. Ορισμένες πρόσθετες λεπτομέρειες που ήδη βοηθούν στη διερεύνηση περιστατικών, στη διερεύνηση κάποιων καταστάσεων έκτακτης ανάγκης, πρέπει ήδη να τοποθετηθούν σε δευτερεύοντες πίνακες εργαλείων ή να κρυφτούν σε συνδέσμους ανάλυσης που οδηγούν σε συστήματα παρακολούθησης τρίτων.
Ένα παράδειγμα ενός γνωστού συστήματος παρακολούθησης. Αυτό είναι ένα πολύ ωραίο σύστημα παρακολούθησης. Συλλέγει πολλά δεδομένα, αλλά από την άποψή μου, έχει μια περίεργη έννοια των ταμπλό. Υπάρχει ένας σύνδεσμος "Δημιουργία πίνακα ελέγχου". Αλλά όταν δημιουργείτε έναν πίνακα ελέγχου, δημιουργείτε μια λίστα δύο στηλών, μια λίστα γραφημάτων. Και όταν χρειάζεται να κοιτάξετε κάτι, αρχίζετε να κάνετε κλικ, να κάνετε κύλιση, να αναζητάτε το επιθυμητό γράφημα με το ποντίκι. Και αυτό απαιτεί χρόνο, δηλαδή δεν υπάρχουν πίνακες εργαλείων ως τέτοιοι. Υπάρχουν μόνο λίστες διαγραμμάτων.
Τι πρέπει να προστεθεί σε αυτούς τους πίνακες εργαλείων; Μπορείτε να ξεκινήσετε με ένα τέτοιο χαρακτηριστικό όπως ο χρόνος απόκρισης. Η PostgreSQL έχει την προβολή pg_stat_statements. Είναι απενεργοποιημένο από προεπιλογή, αλλά είναι μία από τις σημαντικές προβολές συστήματος που θα πρέπει πάντα να ενεργοποιείται και να χρησιμοποιείται. Αποθηκεύει πληροφορίες για όλα τα εκτελούμενα ερωτήματα που εκτελέστηκαν στη βάση δεδομένων.
Αντίστοιχα, μπορούμε να ξεκινήσουμε από το γεγονός ότι μπορούμε να πάρουμε τον συνολικό χρόνο εκτέλεσης όλων των αιτημάτων και να διαιρέσουμε με τον αριθμό των αιτημάτων χρησιμοποιώντας τα παραπάνω πεδία. Αλλά αυτή είναι μια τέτοια μέση θερμοκρασία στο νοσοκομείο. Μπορούμε να βασιστούμε σε άλλα πεδία - τον ελάχιστο χρόνο εκτέλεσης του ερωτήματος, τον μέγιστο και τον διάμεσο. Και μπορούμε ακόμη και να δημιουργήσουμε εκατοστημόρια, η PostgreSQL έχει τις αντίστοιχες λειτουργίες για αυτό. Και μπορούμε να πάρουμε μερικούς αριθμούς που χαρακτηρίζουν τον χρόνο απόκρισης της βάσης δεδομένων μας για ήδη ολοκληρωμένα αιτήματα, δηλαδή δεν εκτελούμε το ψεύτικο αίτημα "επιλογή 1" και παρακολουθούμε τον χρόνο απόκρισης, αλλά αναλύουμε τον χρόνο απόκρισης για ήδη ολοκληρωμένα αιτήματα και κληρώνουμε είτε ένα ξεχωριστό σχήμα ή χτίζουμε ένα γράφημα με βάση αυτό.
Είναι επίσης σημαντικό να παρακολουθείτε τον αριθμό των σφαλμάτων που δημιουργεί αυτήν τη στιγμή το σύστημα. Και για αυτό μπορείτε να χρησιμοποιήσετε την προβολή pg_stat_database. Στοχεύουμε το πεδίο xact_rollback. Αυτό το πεδίο όχι μόνο εμφανίζει τον αριθμό των επαναλήψεων που συμβαίνουν στη βάση δεδομένων, αλλά λαμβάνει επίσης υπόψη τον αριθμό των σφαλμάτων. Σχετικά μιλώντας, μπορούμε να εμφανίσουμε αυτόν τον αριθμό στο ταμπλό μας και να δούμε πόσα σφάλματα έχουμε αυτή τη στιγμή. Εάν υπάρχουν πολλά σφάλματα, τότε αυτός είναι ήδη ένας καλός λόγος για να εξετάσετε τα αρχεία καταγραφής και να δείτε τι είδους σφάλματα είναι και γιατί εμφανίζονται, και στη συνέχεια να επενδύσετε και να τα λύσετε.
Μπορείτε να προσθέσετε κάτι σαν στροφόμετρο. Αυτοί είναι ο αριθμός των συναλλαγών ανά δευτερόλεπτο και ο αριθμός των αιτημάτων ανά δευτερόλεπτο. Σχετικά μιλώντας, μπορείτε να χρησιμοποιήσετε αυτούς τους αριθμούς ως την τρέχουσα απόδοση της βάσης δεδομένων σας και να παρατηρήσετε εάν υπάρχουν κορυφές σε αιτήματα, κορυφές στις συναλλαγές ή, αντίθετα, η βάση δεδομένων είναι υποφορτωμένη επειδή κάποιο είδος backend έπεσε. Είναι σημαντικό να κοιτάμε πάντα αυτό το σχήμα και να θυμόμαστε ότι για το έργο μας μια τέτοια απόδοση είναι φυσιολογική και οι τιμές πάνω και κάτω είναι ήδη κάποιου είδους προβληματικές και ακατανόητες, πράγμα που σημαίνει ότι πρέπει να δούμε γιατί τέτοιοι αριθμοί .
Για να υπολογίσουμε τον αριθμό των συναλλαγών, μπορούμε και πάλι να ανατρέξουμε στην προβολή pg_stat_database. Μπορούμε να προσθέσουμε τον αριθμό των δεσμεύσεων και τον αριθμό των rollbacks για να πάρουμε τον αριθμό των συναλλαγών ανά δευτερόλεπτο.
Όλοι καταλαβαίνουν ότι πολλά αιτήματα μπορούν να χωρέσουν σε μία συναλλαγή; Επομένως, το TPS και το QPS είναι ελαφρώς διαφορετικά.
Ο αριθμός των αιτημάτων ανά δευτερόλεπτο μπορεί να ληφθεί από το pg_stat_statements και απλά να υπολογίσετε το άθροισμα όλων των εκτελούμενων αιτημάτων. Είναι σαφές ότι συγκρίνουμε την τρέχουσα τιμή με την προηγούμενη, αφαιρούμε, παίρνουμε το δέλτα, παίρνουμε το ποσό.
Μπορείτε να προσθέσετε πρόσθετες μετρήσεις εάν το επιθυμείτε, οι οποίες βοηθούν επίσης στην αξιολόγηση της διαθεσιμότητας της βάσης δεδομένων μας και στην παρακολούθηση εάν υπήρξαν διακοπές λειτουργίας.
Μία από αυτές τις μετρήσεις είναι ο χρόνος λειτουργίας. Αλλά ο χρόνος λειτουργίας στο PostgreSQL είναι λίγο δύσκολος. Θα σου πω γιατί. Όταν ξεκινά η PostgreSQL, αρχίζει να αναφέρει χρόνο λειτουργίας. Αλλά αν κάποια στιγμή, για παράδειγμα, κάποια εργασία εκτελούνταν τη νύχτα, ήρθε ένας OOM-killer και τερματίζει αναγκαστικά τη θυγατρική διαδικασία PostgreSQL, τότε σε αυτήν την περίπτωση η PostgreSQL τερματίζει τη σύνδεση όλων των πελατών, επαναφέρει την περιοχή μοιρασμένης μνήμης και ξεκινά την ανάκτηση από το τελευταίο σημείο ελέγχου. Και ενώ διαρκεί αυτή η ανάκτηση από το σημείο ελέγχου, η βάση δεδομένων δεν δέχεται συνδέσεις, δηλαδή, αυτή η κατάσταση μπορεί να αξιολογηθεί ως χρόνος διακοπής λειτουργίας. Αλλά αυτό δεν θα επαναφέρει τον μετρητή χρόνου λειτουργίας, επειδή λαμβάνει υπόψη τον χρόνο έναρξης του ταχυδρομείου από την πρώτη στιγμή. Επομένως, τέτοιες καταστάσεις μπορούν να παραλειφθούν.
Θα πρέπει επίσης να παρακολουθείτε τον αριθμό των εργαζομένων σε ηλεκτρική σκούπα. Όλοι γνωρίζουν τι είναι το autovacuum στην PostgreSQL; Αυτό είναι ένα ενδιαφέρον υποσύστημα στην PostgreSQL. Πολλά άρθρα έχουν γραφτεί γι' αυτό, πολλές αναφορές έχουν γίνει. Πολλές συζητήσεις για το κενό, πώς πρέπει να λειτουργεί. Πολλοί το θεωρούν αναγκαίο κακό. Αλλά είναι. Αυτό είναι ένα είδος συλλογής σκουπιδιών που καθαρίζει παρωχημένες εκδόσεις σειρών που δεν χρειάζονται σε καμία από τις συναλλαγές και ελευθερώνει χώρο σε πίνακες και ευρετήρια για νέες σειρές.
Γιατί πρέπει να παρακολουθείται; Γιατί το κενό μερικές φορές πονάει πολύ. Καταναλώνει μεγάλο όγκο πόρων και τα αιτήματα των πελατών αρχίζουν να υποφέρουν από αυτό.
Και θα πρέπει να παρακολουθείται μέσω της προβολής pg_stat_activity, για την οποία θα μιλήσω στην επόμενη ενότητα. Αυτή η προβολή δείχνει την τρέχουσα δραστηριότητα στη βάση δεδομένων. Και μέσω αυτής της δραστηριότητας, μπορούμε να παρακολουθήσουμε τον αριθμό των κενού που λειτουργούν αυτήν τη στιγμή. Μπορούμε να παρακολουθήσουμε τα vacuums και να δούμε ότι αν έχουμε ξεπεράσει το όριο, τότε αυτή είναι μια ευκαιρία να εξετάσουμε τις ρυθμίσεις PostgreSQL και να βελτιστοποιήσουμε κατά κάποιο τρόπο τη λειτουργία του vacuum.
Ένα άλλο χαρακτηριστικό της PostgreSQL είναι ότι η PostgreSQL έχει βαρεθεί πολύ τις μεγάλες συναλλαγές. Ειδικά, από συναλλαγές που κολλάνε για πολύ καιρό και δεν κάνουν τίποτα. Αυτά είναι τα λεγόμενα stat idle-in-transaction. Μια τέτοια συναλλαγή κρατά κλειδαριές, εμποδίζει το κενό να λειτουργήσει. Και ως αποτέλεσμα - τα τραπέζια διογκώνονται, αυξάνονται σε μέγεθος. Και τα ερωτήματα που λειτουργούν με αυτούς τους πίνακες, αρχίζουν να λειτουργούν πιο αργά, επειδή πρέπει να φτυαρίσετε όλες τις παλιές εκδόσεις σειρών από τη μνήμη στον δίσκο και πίσω. Επομένως, ο χρόνος, η διάρκεια των μεγαλύτερων συναλλαγών, τα μεγαλύτερα αιτήματα κενού πρέπει επίσης να παρακολουθούνται. Και αν δούμε κάποιες διεργασίες που εκτελούνται για πολύ μεγάλο χρονικό διάστημα, για περισσότερα από 10-20-30 λεπτά για φόρτωση OLTP, τότε πρέπει να τις προσέξουμε και να τις αναγκάσουμε να τερματίσουν ή να βελτιστοποιήσουμε την εφαρμογή έτσι ώστε δεν καλούνται και δεν κολλάνε τόσο καιρό. Για αναλυτικό φορτίο, 10-20-30 λεπτά είναι φυσιολογικά, υπάρχουν και μεγαλύτερα.
Στη συνέχεια έχουμε την επιλογή με συνδεδεμένους πελάτες. Όταν έχουμε ήδη σχηματίσει έναν πίνακα ελέγχου, έχουμε δημοσιεύσει βασικές μετρήσεις προσβασιμότητας σε αυτόν, μπορούμε επίσης να προσθέσουμε επιπλέον πληροφορίες σχετικά με τους συνδεδεμένους πελάτες εκεί.
Οι πληροφορίες σχετικά με τους συνδεδεμένους πελάτες είναι σημαντικές επειδή, από την άποψη της PostgreSQL, υπάρχουν διαφορετικοί τύποι πελατών. Υπάρχουν καλοί πελάτες και υπάρχουν κακοί πελάτες.
Ένα απλό παράδειγμα. Με τον όρο πελάτη, εννοώ την εφαρμογή. Η εφαρμογή έχει συνδεθεί στη βάση δεδομένων και ξεκινά αμέσως να στέλνει τα αιτήματά της εκεί, η βάση τα επεξεργάζεται και τα εκτελεί και επιστρέφει τα αποτελέσματα στον πελάτη. Αυτοί είναι καλοί και σωστοί πελάτες.
Υπάρχουν περιπτώσεις που ο πελάτης είναι συνδεδεμένος, διατηρεί τη σύνδεση, αλλά δεν κάνει τίποτα. Είναι σε κατάσταση αδράνειας.
Υπάρχουν όμως κακοί πελάτες. Για παράδειγμα, ο ίδιος πελάτης συνδέθηκε, άνοιξε μια συναλλαγή, έκανε κάτι στη βάση δεδομένων και, στη συνέχεια, μπήκε στον κώδικα, για παράδειγμα, για πρόσβαση σε μια εξωτερική πηγή ή για επεξεργασία των δεδομένων που ελήφθησαν εκεί. Ταυτόχρονα όμως δεν έκλεισε τη συναλλαγή. Και η συναλλαγή κρέμεται στη βάση δεδομένων και κρατά το κλείδωμα στη γραμμή. Αυτή είναι μια κακή κατάσταση. Και αν ξαφνικά η εφαρμογή κάπου μέσα της πέσει κατά μια εξαίρεση (Εξαίρεση), τότε η συναλλαγή μπορεί να παραμείνει ανοιχτή για πολύ μεγάλο χρονικό διάστημα. Και αυτό επηρεάζει άμεσα την απόδοση της PostgreSQL. Το PostgreSQL θα τρέχει πιο αργά. Επομένως, είναι σημαντικό να παρακολουθείτε έγκαιρα τέτοιους πελάτες και να τερματίζετε την εργασία τους αναγκαστικά. Και πρέπει να βελτιστοποιήσετε την εφαρμογή σας ώστε να μην υπάρχουν τέτοιες καταστάσεις.
Άλλοι κακοί πελάτες είναι πελάτες σε αναμονή. Αλλά γίνονται κακοί λόγω των συνθηκών. Για παράδειγμα, μια απλή αδράνεια συναλλαγή: μπορεί να ανοίξει μια συναλλαγή, να πάρει λουκέτα σε ορισμένες γραμμές, μετά θα πέσει κάπου στον κωδικό, αφήνοντας μια συναλλαγή που εκκρεμεί. Ένας άλλος πελάτης θα έρθει, θα ζητήσει τα ίδια δεδομένα, αλλά θα συναντήσει ένα κλείδωμα, επειδή αυτή η αναρτημένη συναλλαγή έχει ήδη κλειδώματα σε ορισμένες απαραίτητες σειρές. Και η δεύτερη συναλλαγή θα κρεμάσει εν αναμονή όταν ολοκληρωθεί η πρώτη συναλλαγή ή ο διαχειριστής της την κλείσει αναγκαστικά. Έτσι, οι εκκρεμείς συναλλαγές μπορούν να συσσωρευτούν και να υπερχειλίσουν το όριο σύνδεσης της βάσης δεδομένων. Και όταν το όριο είναι γεμάτο, η εφαρμογή δεν μπορεί πλέον να λειτουργήσει με τη βάση δεδομένων. Αυτή είναι ήδη μια κατάσταση έκτακτης ανάγκης για το έργο. Επομένως, οι κακοί πελάτες πρέπει να παρακολουθούνται και να ανταποκρίνονται έγκαιρα.
Άλλο ένα παράδειγμα παρακολούθησης. Και εδώ είναι ένα αξιοπρεπές ταμπλό. Υπάρχουν πληροφορίες για συνδέσεις από πάνω. Σύνδεση DB - 8 τεμάχια. Και είναι όλο. Δεν έχουμε πληροφορίες σχετικά με το ποιοι πελάτες είναι ενεργοί, ποιοι πελάτες είναι απλώς αδρανείς, δεν κάνουν τίποτα. Δεν υπάρχουν πληροφορίες σχετικά με τις εκκρεμείς συναλλαγές και τις εκκρεμείς συνδέσεις, δηλαδή αυτό είναι ένα τέτοιο σχήμα που δείχνει τον αριθμό των συνδέσεων και τέλος. Και μετά μαντέψτε μόνοι σας.
Συνεπώς, για να προσθέσετε αυτές τις πληροφορίες στην παρακολούθηση, πρέπει να ανατρέξετε στην προβολή συστήματος pg_stat_activity. Εάν περνάτε πολύ χρόνο στη PostgreSQL, τότε αυτή είναι μια πολύ καλή προβολή που θα πρέπει να γίνει φίλος σας, γιατί δείχνει την τρέχουσα δραστηριότητα στην PostgreSQL, δηλαδή τι συμβαίνει σε αυτήν. Υπάρχει μια ξεχωριστή γραμμή για κάθε διεργασία που δείχνει πληροφορίες για αυτήν τη διαδικασία: από ποιον κεντρικό υπολογιστή έγινε η σύνδεση, με ποιο χρήστη, με ποιο όνομα, πότε ξεκίνησε η συναλλαγή, ποια αίτηση εκτελείται αυτήν τη στιγμή, ποια αίτηση εκτελέστηκε τελευταία. Και, κατά συνέπεια, μπορούμε να αξιολογήσουμε την κατάσταση του πελάτη από το πεδίο stat. Σχετικά μιλώντας, μπορούμε να ομαδοποιήσουμε με βάση αυτό το πεδίο και να πάρουμε τα στατιστικά που βρίσκονται τώρα στη βάση δεδομένων και τον αριθμό των συνδέσεων που υπάρχουν με αυτό το στατιστικό στοιχείο στη βάση δεδομένων. Και μπορούμε να στείλουμε τους ήδη ληφθέντες αριθμούς στην παρακολούθησή μας και να σχεδιάσουμε γραφήματα πάνω τους.
Είναι επίσης σημαντικό να αξιολογήσετε τη διάρκεια της συναλλαγής. Έχω ήδη πει ότι είναι σημαντικό να αξιολογείται η διάρκεια των κενού, αλλά και οι συναλλαγές αξιολογούνται με τον ίδιο τρόπο. Υπάρχουν τα πεδία xact_start και query_start. Μιλώντας σχετικά, δείχνουν την ώρα έναρξης της συναλλαγής και την ώρα έναρξης του αιτήματος. Παίρνουμε τη συνάρτηση now() που δείχνει την τρέχουσα χρονική σήμανση και αφαιρούμε τη συναλλαγή και ζητάμε χρονικές σημάνσεις. Και παίρνουμε τη διάρκεια της συναλλαγής, τη διάρκεια του αιτήματος.
Αν δούμε μεγάλες συναλλαγές, θα πρέπει να τις ολοκληρώσουμε ήδη. Για ένα φορτίο OLTP, οι μεγάλες συναλλαγές είναι ήδη περισσότερες από 1-2-3 λεπτά. Για ένα φορτίο OLAP, οι μεγάλες συναλλαγές είναι φυσιολογικές, αλλά αν εκτελούνται για περισσότερες από δύο ώρες, τότε αυτό είναι επίσης ένα σημάδι ότι έχουμε κάπου μια λοξή.
Μόλις οι πελάτες συνδεθούν στη βάση δεδομένων, αρχίζουν να εργάζονται με τα δεδομένα μας. Έχουν πρόσβαση σε πίνακες, έχουν πρόσβαση σε ευρετήρια για να λάβουν δεδομένα από έναν πίνακα. Και είναι σημαντικό να αξιολογήσουμε τον τρόπο με τον οποίο οι πελάτες εργάζονται με αυτά τα δεδομένα.
Αυτό είναι απαραίτητο για να αξιολογήσουμε τον φόρτο εργασίας μας και να κατανοήσουμε χονδρικά ποιους πίνακες έχουμε τα πιο «καυτά». Για παράδειγμα, αυτό είναι απαραίτητο σε περιπτώσεις όπου θέλουμε να τοποθετήσουμε «καυτά» τραπέζια σε κάποιο είδος γρήγορης αποθήκευσης SSD. Για παράδειγμα, ορισμένοι πίνακες αρχειοθέτησης που δεν έχουμε χρησιμοποιήσει για πολύ καιρό μπορούν να μεταφερθούν σε κάποιο είδος «ψυχρού» αρχείου, σε δίσκους SATA και να τους αφήσουμε να ζήσουν εκεί, θα προσπελαστούν όπως απαιτείται.
Είναι επίσης χρήσιμο για τον εντοπισμό ανωμαλιών μετά από οποιεσδήποτε εκδόσεις και αναπτύξεις. Ας υποθέσουμε ότι το έργο παρουσίασε κάποια νέα δυνατότητα. Για παράδειγμα, προσθέσαμε νέα λειτουργικότητα για την εργασία με τη βάση δεδομένων. Και αν δημιουργήσουμε γραφήματα για τη χρήση πινάκων, μπορούμε εύκολα να εντοπίσουμε αυτές τις ανωμαλίες σε αυτά τα γραφήματα. Για παράδειγμα, ενημερώστε τις ριπές ή διαγράψτε τις ριπές. Θα είναι πολύ ορατό.
Είναι επίσης δυνατός ο εντοπισμός ανωμαλιών στα στατιστικά στοιχεία "επιπλέον". Τι σημαίνει? Η PostgreSQL έχει ένα πολύ δυνατό και πολύ καλό πρόγραμμα σχεδιασμού ερωτημάτων. Και οι προγραμματιστές αφιερώνουν πολύ χρόνο στην ανάπτυξή του. Πώς λειτουργεί; Για να δημιουργήσει καλά σχέδια, η PostgreSQL συλλέγει στατιστικά στοιχεία σχετικά με την κατανομή των δεδομένων σε πίνακες με ένα ορισμένο χρονικό διάστημα, με κάποια περιοδικότητα. Αυτές είναι οι πιο συχνές τιμές: ο αριθμός των μοναδικών τιμών, πληροφορίες για το NULL στον πίνακα, πολλές πληροφορίες.
Με βάση αυτά τα στατιστικά στοιχεία, ο σχεδιαστής δημιουργεί πολλά ερωτήματα, επιλέγει το βέλτιστο και χρησιμοποιεί αυτό το σχέδιο ερωτημάτων για να εκτελέσει το ίδιο το ερώτημα και να επιστρέψει δεδομένα.
Και συμβαίνει ότι τα στατιστικά «επιπλέουν». Τα ποιοτικά και ποσοτικά δεδομένα άλλαξαν κατά κάποιο τρόπο στον πίνακα, αλλά τα στατιστικά στοιχεία δεν συλλέχθηκαν. Και τα σχέδια που σχηματίζονται μπορεί να μην είναι βέλτιστα. Και αν τα σχέδιά μας αποδειχθούν μη βέλτιστα όσον αφορά την παρακολούθηση που συλλέγεται, σύμφωνα με τους πίνακες, θα μπορέσουμε να δούμε αυτές τις ανωμαλίες. Για παράδειγμα, κάπου άλλαξαν ποιοτικά τα δεδομένα και αντί για το ευρετήριο άρχισε να χρησιμοποιείται ένα διαδοχικό πέρασμα από τον πίνακα, δηλ. εάν το ερώτημα πρέπει να επιστρέψει μόνο 100 σειρές (υπάρχει όριο 100), τότε θα πραγματοποιηθεί πλήρης απαρίθμηση για αυτό το ερώτημα. Και αυτό έχει πάντα πολύ άσχημη επίδραση στην απόδοση.
Και μπορούμε να το δούμε στην παρακολούθηση. Και κοιτάξτε ήδη αυτό το ερώτημα, εκτελέστε εξήγηση για αυτό, συλλέξτε στατιστικά στοιχεία, δημιουργήστε ένα νέο πρόσθετο ευρετήριο. Και απαντήστε ήδη σε αυτό το πρόβλημα. Επομένως είναι σημαντικό.
Άλλο ένα παράδειγμα παρακολούθησης. Νομίζω ότι πολλοί τον αναγνωρίζουν γιατί είναι πολύ δημοφιλής. Ποιοι χρησιμοποιούν στα έργα τους ? Και ποιος χρησιμοποιεί αυτό το προϊόν σε συνδυασμό με τον Προμηθέα; Το γεγονός είναι ότι στο τυπικό αποθετήριο αυτής της παρακολούθησης υπάρχει ένας πίνακας εργαλείων για εργασία με PostgreSQL - Προμηθέας. Αλλά υπάρχει μια κακή λεπτομέρεια εδώ.
Υπάρχουν πολλά διαγράμματα. Και τα byte καθορίζονται ως ενότητα, δηλαδή υπάρχουν 5 γραφήματα. Αυτά είναι Εισαγωγή δεδομένων, Ενημέρωση δεδομένων, Διαγραφή δεδομένων, Λήψη δεδομένων και Επιστροφή δεδομένων. Τα byte καθορίζονται ως η διάσταση μονάδας. Αλλά το γεγονός είναι ότι τα στατιστικά στοιχεία στην PostgreSQL επιστρέφουν δεδομένα σε πλειάδες (σειρές). Και, κατά συνέπεια, αυτά τα γραφήματα είναι ένας πολύ καλός τρόπος για να υποτιμήσετε τον φόρτο εργασίας σας πολλές φορές, δεκάδες φορές, επειδή μια πλειάδα δεν είναι byte, μια πλειάδα είναι μια συμβολοσειρά, είναι πολλά byte και έχει πάντα μεταβλητό μήκος. Δηλαδή, ο υπολογισμός του φόρτου εργασίας σε byte χρησιμοποιώντας πλειάδες είναι μια μη ρεαλιστική εργασία ή πολύ δύσκολη. Επομένως, όταν χρησιμοποιείτε έναν πίνακα εργαλείων ή μια ενσωματωμένη παρακολούθηση, είναι πάντα σημαντικό να κατανοείτε ότι λειτουργεί σωστά και σας επιστρέφει σωστά αξιολογημένα δεδομένα.
Πώς να λάβετε στατιστικά στοιχεία σε αυτούς τους πίνακες; Για να γίνει αυτό, η PostgreSQL έχει μια οικογένεια προβολών. Και η κύρια άποψη είναι . User_tables - αυτό σημαίνει ότι οι πίνακες δημιουργούνται για λογαριασμό του χρήστη. Αντίθετα, υπάρχουν προβολές συστήματος, οι οποίες χρησιμοποιούνται από την ίδια την PostgreSQL. Και υπάρχει ένας συνοπτικός πίνακας Alltables, ο οποίος περιλαμβάνει σύστημα και χρήστη. Μπορείτε να ξεκινήσετε από οποιοδήποτε από αυτά που σας αρέσει περισσότερο.
Τα παραπάνω πεδία μπορούν να χρησιμοποιηθούν για την εκτίμηση του αριθμού των εισαγωγών, ενημερώσεων και διαγραφών. Το παράδειγμα πίνακα εργαλείων που χρησιμοποίησα χρησιμοποιεί αυτά τα πεδία για να αξιολογήσει τα χαρακτηριστικά του φόρτου εργασίας. Επομένως, μπορούμε επίσης να βασιστούμε σε αυτά. Αξίζει όμως να θυμόμαστε ότι πρόκειται για πλειάδες, όχι bytes, επομένως δεν μπορούμε να το πάρουμε και να το κάνουμε byte.
Με βάση αυτά τα δεδομένα, μπορούμε να δημιουργήσουμε τους λεγόμενους TopN-tables. Για παράδειγμα, Top-5, Top-10. Και μπορείτε να παρακολουθείτε αυτά τα ζεστά τραπέζια που χρησιμοποιούνται περισσότερο από άλλα. Για παράδειγμα, 5 «καυτά» τραπέζια για εισαγωγή. Και σύμφωνα με αυτούς τους πίνακες TopN, αξιολογούμε τον φόρτο εργασίας μας και μπορούμε να αξιολογήσουμε εκρήξεις φόρτου εργασίας μετά από οποιεσδήποτε εκδόσεις και ενημερώσεις και αναπτύξεις.
Είναι επίσης σημαντικό να αξιολογήσουμε το μέγεθος του πίνακα, επειδή μερικές φορές οι προγραμματιστές παρουσιάζουν μια νέα δυνατότητα και οι πίνακές μας αρχίζουν να διογκώνονται στα μεγάλα μεγέθη τους, επειδή αποφάσισαν να προσθέσουν έναν επιπλέον όγκο δεδομένων, αλλά δεν προέβλεψαν πώς θα επηρεάζουν το μέγεθος της βάσης δεδομένων. Τέτοιες περιπτώσεις μας προκαλούν και εκπλήξεις.
Και τώρα μια μικρή ερώτηση για εσάς. Ποια είναι η ερώτηση όταν παρατηρείτε το φορτίο στον διακομιστή βάσης δεδομένων; Ποια είναι η επόμενη ερώτησή σας;
Το πραγματικό ερώτημα όμως είναι το εξής. Τι αιτήματα προκαλεί το φορτίο; Δηλαδή, δεν έχει ενδιαφέρον να παρακολουθείς τις διεργασίες που προκαλεί το φορτίο. Είναι σαφές ότι εάν ο κεντρικός υπολογιστής είναι με βάση δεδομένων, τότε η βάση δεδομένων εκτελείται εκεί και είναι σαφές ότι μόνο οι βάσεις δεδομένων θα διατίθενται εκεί. Αν ανοίξουμε το Top, θα δούμε εκεί μια λίστα με διεργασίες PostgreSQL που κάνουν κάτι. Από το Top δεν θα είναι ξεκάθαρο τι κάνουν.
Αντίστοιχα, πρέπει να βρείτε εκείνα τα ερωτήματα που προκαλούν το μεγαλύτερο φορτίο, επειδή ο συντονισμός ερωτημάτων, κατά κανόνα, αποφέρει μεγαλύτερο κέρδος από τη ρύθμιση παραμέτρων PostgreSQL ή τον συντονισμό του λειτουργικού συστήματος ή ακόμα και τον συντονισμό υλικού. Σύμφωνα με την εκτίμησή μου, αυτό είναι περίπου 80-85-90%. Και αυτό γίνεται πολύ πιο γρήγορα. Είναι πιο γρήγορο να διορθώσετε το αίτημα παρά να διορθώσετε τη διαμόρφωση, να προγραμματίσετε μια επανεκκίνηση, ειδικά εάν δεν είναι δυνατή η επανεκκίνηση της βάσης δεδομένων ή να προσθέσετε υλικό. Είναι πιο εύκολο να ξαναγράψετε το ερώτημα κάπου ή να προσθέσετε ένα ευρετήριο για να έχετε καλύτερο αποτέλεσμα από αυτό το ερώτημα.
Κατά συνέπεια, είναι απαραίτητο να παρακολουθούνται τα αιτήματα και η επάρκειά τους. Ας πάρουμε ένα άλλο παράδειγμα παρακολούθησης. Και εδώ, επίσης, φαίνεται να υπάρχει εξαιρετική παρακολούθηση. Υπάρχουν πληροφορίες για την αναπαραγωγή, υπάρχουν πληροφορίες για την απόδοση, τον αποκλεισμό, τη χρήση πόρων. Όλα είναι καλά, αλλά δεν υπάρχουν πληροφορίες για αιτήματα. Δεν είναι σαφές ποια ερωτήματα εκτελούνται στη βάση δεδομένων μας, πόσο καιρό εκτελούνται, πόσα από αυτά τα ερωτήματα. Πρέπει να έχουμε πάντα αυτές τις πληροφορίες στην παρακολούθηση.
Και για να λάβουμε αυτές τις πληροφορίες, μπορούμε να χρησιμοποιήσουμε την ενότητα pg_stat_statements. Στη βάση του, μπορείτε να δημιουργήσετε μια ποικιλία γραφικών. Για παράδειγμα, μπορείτε να λάβετε πληροφορίες για τα πιο συχνά αιτήματα, δηλαδή για εκείνα τα αιτήματα που εκτελούνται πιο συχνά. Ναι, μετά την ανάπτυξη είναι επίσης πολύ χρήσιμο να το κοιτάξετε και να καταλάβετε εάν υπάρχει αύξηση των αιτημάτων.
Μπορείτε να παρακολουθείτε τα μεγαλύτερα αιτήματα, δηλαδή τα αιτήματα που χρειάζονται περισσότερο για να ολοκληρωθούν. Τρέχουν στον επεξεργαστή, καταναλώνουν I/O. Μπορούμε επίσης να το αξιολογήσουμε με τα πεδία total_time, mean_time, blk_write_time και blk_read_time.
Μπορούμε να αξιολογήσουμε και να παρακολουθήσουμε τα πιο βαριά αιτήματα όσον αφορά τη χρήση πόρων, αυτά που διαβάζουν από δίσκο, αυτά που λειτουργούν με μνήμη ή, αντίθετα, δημιουργούν κάποιο είδος φόρτου εγγραφής.
Μπορούμε να αξιολογήσουμε τα πιο γενναιόδωρα αιτήματα. Αυτά είναι τα ερωτήματα που επιστρέφουν μεγάλο αριθμό σειρών. Για παράδειγμα, μπορεί να είναι κάποιο είδος αιτήματος όπου ξέχασαν να ορίσουν ένα όριο. Και απλώς επιστρέφει ολόκληρο το περιεχόμενο του πίνακα ή του ερωτήματος στους πίνακες που ζητήσατε.
Και μπορείτε επίσης να παρακολουθείτε ερωτήματα που χρησιμοποιούν προσωρινά αρχεία ή προσωρινούς πίνακες.
Και έχουμε ακόμα διαδικασίες παρασκηνίου. Οι διεργασίες παρασκηνίου είναι κατά κύριο λόγο σημεία ελέγχου ή ονομάζονται επίσης σημεία ελέγχου, αυτές είναι η αυτόματη σκούπα και η αναπαραγωγή.
Άλλο ένα παράδειγμα παρακολούθησης. Υπάρχει μια καρτέλα Συντήρηση στα αριστερά, μεταβείτε σε αυτήν και ελπίζετε να δείτε κάτι χρήσιμο. Εδώ όμως, μόνο η ώρα του κενού και η συλλογή στατιστικών, τίποτα άλλο. Πρόκειται για πολύ κακές πληροφορίες, επομένως πρέπει πάντα να έχετε πληροφορίες σχετικά με το πώς λειτουργούν οι διαδικασίες παρασκηνίου στη βάση δεδομένων μας και εάν υπάρχουν προβλήματα από τη δουλειά τους.
Όταν εξετάζουμε τα σημεία ελέγχου, θα πρέπει να θυμόμαστε ότι τα σημεία ελέγχου μας ξεπλένουν τις "βρώμικες" σελίδες από την περιοχή της θραυσμένης μνήμης στο δίσκο και στη συνέχεια δημιουργούν ένα σημείο ελέγχου. Και αυτό το σημείο ελέγχου μπορεί ήδη να χρησιμοποιηθεί ως μέρος κατά την ανάκτηση, εάν η PostgreSQL τερματίστηκε ξαφνικά σε περίπτωση έκτακτης ανάγκης.
Αντίστοιχα, για να ξεπλύνετε όλες τις "βρώμικες" σελίδες στο δίσκο, πρέπει να κάνετε μια συγκεκριμένη ποσότητα γραφής. Και, κατά κανόνα, σε συστήματα με μεγάλη ποσότητα μνήμης, αυτό είναι πολύ. Και αν κάνουμε σημεία ελέγχου πολύ συχνά σε κάποιο σύντομο διάστημα, τότε η απόδοση του δίσκου θα πέσει πολύ. Και τα αιτήματα πελατών θα υποφέρουν από έλλειψη πόρων. Θα ανταγωνίζονται για πόρους και θα στερούνται παραγωγικότητας.
Αντίστοιχα, μέσω του pg_stat_bgwriter στα καθορισμένα πεδία, μπορούμε να παρακολουθούμε τον αριθμό των σημείων ελέγχου που εμφανίζονται. Και αν έχουμε πολλά σημεία ελέγχου για ένα ορισμένο χρονικό διάστημα (για 10-15-20 λεπτά, για μισή ώρα), για παράδειγμα, 3-4-5, τότε αυτό μπορεί ήδη να είναι πρόβλημα. Και πρέπει ήδη να κοιτάξετε στη βάση δεδομένων, να κοιτάξετε στη διαμόρφωση, τι προκαλεί μια τέτοια αφθονία σημείων ελέγχου. Ίσως έρχεται κάποιος μεγάλος δίσκος. Μπορούμε ήδη να αξιολογήσουμε τον φόρτο εργασίας, επειδή έχουμε ήδη προσθέσει γραφήματα φόρτου εργασίας. Μπορούμε ήδη να τροποποιήσουμε τις παραμέτρους του σημείου διακοπής και να βεβαιωθούμε ότι δεν επηρεάζουν πολύ την απόδοση του ερωτήματος.
Επιστρέφω ξανά στην αυτόματη αναρρόφηση επειδή είναι κάτι που, όπως είπα, μπορεί εύκολα να προσθέσει την απόδοση τόσο του δίσκου όσο και των ερωτημάτων, επομένως είναι πάντα σημαντικό να μετράτε την ποσότητα του αυτόματου κενού.
Ο αριθμός των εργαζομένων στην αυτόματη σκούπα στη βάση δεδομένων είναι περιορισμένος. Από προεπιλογή, υπάρχουν τρεις από αυτούς, οπότε αν έχουμε τρεις εργαζόμενους που εργάζονται συνεχώς στη βάση δεδομένων, τότε αυτό σημαίνει ότι το autovacuum μας δεν έχει ρυθμιστεί σωστά, πρέπει να αυξήσουμε τα όρια, να αναθεωρήσουμε τις ρυθμίσεις αυτόματης σκούπας και να αναρριχθούμε ήδη στη διαμόρφωση.
Είναι σημαντικό να αξιολογήσουμε ποιοι εργάτες κενού εργάζονται για εμάς. Είτε εκτοξεύτηκε από τον χρήστη, μπήκε το DBA και εκτόξευσε κάποιο είδος κενού με τα χέρια του, και αυτό δημιούργησε ένα φορτίο. Έχουμε κάποιο πρόβλημα. Ή αυτός είναι ο αριθμός των κενού που ξεβιδώνουν τον μετρητή συναλλαγών. Για ορισμένες εκδόσεις της PostgreSQL, αυτές είναι πολύ βαριές σκούπες. Και μπορούν εύκολα να προσθέσουν απόδοση επειδή αφαιρούν ολόκληρο τον πίνακα, σαρώνοντας όλα τα μπλοκ σε αυτόν τον πίνακα.
Και, φυσικά, η διάρκεια των κενού. Εάν έχουμε μεγάλες κενά που λειτουργούν για πολύ μεγάλο χρονικό διάστημα, τότε αυτό σημαίνει ότι θα πρέπει να προσέξουμε ξανά τη διαμόρφωση του κενού και ίσως να επανεξετάσουμε τις ρυθμίσεις του. Επειδή μπορεί να προκύψει μια κατάσταση όταν το κενό λειτουργεί στο τραπέζι για μεγάλο χρονικό διάστημα (3-4 ώρες), αλλά κατά τη διάρκεια του χρόνου που λειτουργούσε το κενό, μια μεγάλη ποσότητα νεκρών σειρών κατάφερε και πάλι να συσσωρευτεί στον πίνακα. Και μόλις τελειώσει το κενό, πρέπει να σκουπίσει ξανά αυτό το τραπέζι. Και ερχόμαστε σε μια κατάσταση - ένα άπειρο κενό. Και σε αυτή την περίπτωση, το κενό δεν αντιμετωπίζει τη δουλειά του και οι πίνακες αρχίζουν να διογκώνονται σταδιακά σε μέγεθος, αν και ο όγκος των χρήσιμων δεδομένων σε αυτό παραμένει ο ίδιος. Επομένως, σε μεγάλα κενά, κοιτάμε πάντα τη διαμόρφωση και προσπαθούμε να τη βελτιστοποιήσουμε, αλλά ταυτόχρονα, έτσι ώστε να μην υποφέρει η απόδοση των αιτημάτων πελατών.
Τώρα πρακτικά δεν υπάρχει εγκατάσταση PostgreSQL όπου δεν υπήρχε αναπαραγωγή ροής. Η αναπαραγωγή είναι η διαδικασία μεταφοράς δεδομένων από ένα κύριο σε ένα αντίγραφο.
Η αναπαραγωγή στο PostgreSQL οργανώνεται μέσω ενός αρχείου καταγραφής συναλλαγών. Ο κύριος δημιουργεί ένα αρχείο καταγραφής συναλλαγών. Το αρχείο καταγραφής συναλλαγών στη σύνδεση δικτύου πηγαίνει στο αντίγραφο και, στη συνέχεια, αναπαράγεται στο αντίγραφο. Όλα είναι απλά.
Αντίστοιχα, η προβολή pg_stat_replication χρησιμοποιείται για την παρακολούθηση της καθυστέρησης αναπαραγωγής. Αλλά δεν της είναι εύκολο. Στην έκδοση 10, η προβολή έχει υποστεί αρκετές αλλαγές. Πρώτον, μερικά από τα πεδία έχουν μετονομαστεί. Και μερικά από τα πεδία έχουν προστεθεί. Στη 10η έκδοση, εμφανίστηκαν πεδία που σας επιτρέπουν να αξιολογήσετε την καθυστέρηση αναπαραγωγής σε δευτερόλεπτα. Είναι πολύ άνετο. Πριν από την έκδοση 10, ήταν δυνατό να εκτιμηθεί η καθυστέρηση αναπαραγωγής σε byte. Αυτή η δυνατότητα παρέμεινε στη 10η έκδοση, δηλαδή μπορείτε να επιλέξετε τι είναι πιο βολικό για εσάς - αξιολογήστε την καθυστέρηση σε byte ή αξιολογήστε την καθυστέρηση σε δευτερόλεπτα. Πολλοί κάνουν και τα δύο.
Ωστόσο, για να αξιολογήσετε την καθυστέρηση αναπαραγωγής, πρέπει να γνωρίζετε τη θέση του αρχείου καταγραφής στη συναλλαγή. Και αυτές οι θέσεις του αρχείου καταγραφής συναλλαγών βρίσκονται μόνο στην προβολή pg_stat_replication. Σχετικά μιλώντας, μπορούμε να χρησιμοποιήσουμε τη συνάρτηση pg_xlog_location_diff() για να πάρουμε δύο σημεία στο αρχείο καταγραφής συναλλαγών. Υπολογίστε το δέλτα μεταξύ τους και λάβετε την καθυστέρηση αναπαραγωγής σε byte. Είναι πολύ βολικό και απλό.
Στην έκδοση 10 αυτή η συνάρτηση μετονομάστηκε σε pg_wal_lsn_diff(). Γενικά, σε όλες τις συναρτήσεις, προβολές, βοηθητικά προγράμματα, όπου συναντήθηκε η λέξη "xlog", αντικαταστάθηκε με την τιμή "wal". Αυτό είναι τόσο σε προβολές όσο και σε λειτουργίες. Αυτή είναι μια τέτοια καινοτομία.
Επιπλέον, στη 10η έκδοση, προστέθηκαν γραμμές που δείχνουν συγκεκριμένα την καθυστέρηση. Αυτά είναι καθυστέρηση εγγραφής, καθυστέρηση έκπλυσης, καθυστέρηση επανάληψης. Δηλαδή, είναι σημαντικό να παρακολουθούμε αυτά τα πράγματα. Αν δούμε ότι έχουμε καθυστέρηση αναπαραγωγής, τότε πρέπει να διερευνήσουμε γιατί εμφανίστηκε, από πού προήλθε και να διορθώσουμε το πρόβλημα.
Με τις μετρήσεις συστήματος, σχεδόν όλα είναι εντάξει. Όταν γεννιέται οποιαδήποτε παρακολούθηση, ξεκινά με τις μετρήσεις του συστήματος. Αυτή είναι η χρήση επεξεργαστών, μνήμης, ανταλλαγής, δικτύου και δίσκου. Ωστόσο, πολλές παράμετροι δεν υπάρχουν από προεπιλογή.
Εάν όλα είναι εντάξει με την απόρριψη της διαδικασίας, τότε υπάρχουν προβλήματα με την απόρριψη του δίσκου. Κατά κανόνα, οι προγραμματιστές παρακολούθησης προσθέτουν πληροφορίες εύρους ζώνης. Μπορεί να είναι σε iops ή byte. Ξεχνούν όμως τον λανθάνοντα χρόνο και τη χρήση συσκευών δίσκου. Αυτές είναι πιο σημαντικές παράμετροι που μας επιτρέπουν να αξιολογήσουμε πόσο φορτωμένοι είναι οι δίσκοι μας και πόσο επιβραδύνουν. Αν έχουμε υψηλή καθυστέρηση, τότε αυτό σημαίνει ότι υπάρχουν κάποια προβλήματα με τους δίσκους. Αν έχουμε υψηλή αξιοποίηση, τότε αυτό σημαίνει ότι οι δίσκοι δεν μπορούν να αντεπεξέλθουν. Αυτά είναι πιο ποιοτικά χαρακτηριστικά από το εύρος ζώνης.
Ωστόσο, αυτά τα στατιστικά στοιχεία μπορούν επίσης να ληφθούν από το σύστημα αρχείων /proc, όπως γίνεται για την ανακύκλωση επεξεργαστή. Γιατί αυτές οι πληροφορίες δεν προστίθενται στην παρακολούθηση, δεν το γνωρίζω. Αλλά είναι ακόμα σημαντικό να το έχετε στην παρακολούθησή σας.
Το ίδιο ισχύει και για τις διεπαφές δικτύου. Υπάρχουν πληροφορίες σχετικά με το εύρος ζώνης του δικτύου σε πακέτα, σε byte, αλλά παρόλα αυτά δεν υπάρχουν πληροφορίες σχετικά με την καθυστέρηση και καμία πληροφορία σχετικά με τη χρήση, αν και αυτές είναι επίσης χρήσιμες πληροφορίες.
Οποιαδήποτε παρακολούθηση έχει τα μειονεκτήματά της. Και ανεξάρτητα από το είδος της παρακολούθησης που κάνετε, πάντα θα αποτυγχάνει να πληροί ορισμένα κριτήρια. Ωστόσο, αναπτύσσονται, προστίθενται νέα χαρακτηριστικά, νέα πράγματα, οπότε επιλέξτε κάτι και ολοκληρώστε το.
Και για να ολοκληρώσετε, πρέπει πάντα να έχετε μια ιδέα τι σημαίνουν τα δεδομένα στατιστικά στοιχεία και πώς μπορείτε να λύσετε προβλήματα με αυτά.
Και μερικά βασικά σημεία:
- Πρέπει πάντα να παρακολουθείτε τη διαθεσιμότητα, να έχετε πίνακες εργαλείων ώστε να μπορείτε γρήγορα να αξιολογήσετε ότι όλα είναι εντάξει με τη βάση.
- Πρέπει πάντα να έχετε μια ιδέα για το τι συνεργάζονται οι πελάτες με τη βάση δεδομένων σας για να εξαλείψετε τους κακούς πελάτες και να τους πυροβολήσετε.
- Είναι σημαντικό να αξιολογηθεί ο τρόπος με τον οποίο αυτοί οι πελάτες λειτουργούν με δεδομένα. Πρέπει να έχετε μια ιδέα για τον φόρτο εργασίας σας.
- Είναι σημαντικό να αξιολογήσουμε πώς σχηματίζεται αυτός ο φόρτος εργασίας, με τη βοήθεια ποιων ερωτημάτων. Μπορείτε να αξιολογήσετε τα ερωτήματα, να τα βελτιστοποιήσετε, να τα αναδιαμορφώσετε, να δημιουργήσετε ευρετήρια για αυτά. Είναι πολύ σημαντικό.
- Οι διαδικασίες παρασκηνίου μπορούν να επηρεάσουν αρνητικά τα αιτήματα των πελατών, επομένως είναι σημαντικό να βεβαιωθείτε ότι δεν χρησιμοποιούν πάρα πολλούς πόρους.
- Οι μετρήσεις συστήματος σάς επιτρέπουν να κάνετε σχέδια για κλιμάκωση, για αύξηση της χωρητικότητας των διακομιστών σας, επομένως είναι σημαντικό να τις παρακολουθείτε και να τις αξιολογείτε επίσης.
Εάν ενδιαφέρεστε για αυτό το θέμα, μπορείτε να ακολουθήσετε αυτούς τους συνδέσμους.
είναι η επίσημη τεκμηρίωση από τη συλλογή στατιστικών στοιχείων. Υπάρχει περιγραφή όλων των στατιστικών προβολών και περιγραφή όλων των πεδίων. Μπορείτε να τα διαβάσετε, να τα κατανοήσετε και να τα αναλύσετε. Και με βάση αυτά, δημιουργήστε τα δικά σας γραφήματα, προσθέστε στην παρακολούθησή σας.
Ζητήστε παραδείγματα:
Αυτό είναι το εταιρικό μας αποθετήριο και το δικό μου. Έχουν δείγματα αιτημάτων. Δεν υπάρχουν ερωτήματα από την επιλεγμένη* από τη σειρά, κάτι εκεί. Υπάρχουν ήδη έτοιμα αιτήματα με συνδέσεις, χρησιμοποιώντας ενδιαφέρουσες συναρτήσεις που σας επιτρέπουν να κάνετε ευανάγνωστες, βολικές τιμές από ακατέργαστους αριθμούς, δηλαδή, αυτά είναι byte, χρόνος. Μπορείτε να τα επιλέξετε, να τα παρακολουθήσετε, να τα αναλύσετε, να τα προσθέσετε στις παρακολουθήσεις σας, να δημιουργήσετε τις δικές σας παρακολουθήσεις βάσει αυτών.
ερωτήσεις
Ερώτηση: Είπατε ότι δεν θα διαφημίζατε επωνυμίες, αλλά εξακολουθώ να αναρωτιέμαι - τι είδους ταμπλό χρησιμοποιείτε στα έργα σας;
Απάντηση: Με διαφορετικούς τρόπους. Συμβαίνει να ερχόμαστε στον πελάτη και να έχει ήδη τη δική του παρακολούθηση. Και συμβουλεύουμε τον πελάτη για το τι πρέπει να προστεθεί στην παρακολούθησή του. Η χειρότερη κατάσταση είναι με το Zabbix. Επειδή δεν έχει τη δυνατότητα κατασκευής γραφικών TopN. Εμείς οι ίδιοι χρησιμοποιούμε γιατί συμβουλευτήκαμε αυτούς τους τύπους για την παρακολούθηση. Έκαναν παρακολούθηση PostgreSQL βάσει του TOR μας. Γράφω το δικό μου pet-project, το οποίο συλλέγει δεδομένα μέσω του Prometheus και τα αντλεί . Το καθήκον μου είναι να φτιάξω τον δικό μου εξαγωγέα στον Προμηθέα και μετά να σχεδιάσω τα πάντα στη Γραφάνα.
Ερώτηση: Υπάρχουν ανάλογα των αναφορών AWR ή ... συναθροίσεις; Γνωρίζετε κάτι τέτοιο;
Απάντηση: Ναι, ξέρω τι είναι το AWR, είναι ωραίο πράγμα. Αυτή τη στιγμή, υπάρχει μια ποικιλία ποδηλάτων που εφαρμόζουν περίπου το παρακάτω μοντέλο. Σε κάποιο χρονικό διάστημα, ορισμένες γραμμές βάσης εγγράφονται στην ίδια PostgreSQL ή σε ξεχωριστό χώρο αποθήκευσης. Μπορείτε να τα γκουγκλάρετε στο Διαδίκτυο, είναι. Ένας από τους προγραμματιστές ενός τέτοιου πράγματος κάθεται στο φόρουμ sql.ru στο νήμα PostgreSQL. Μπορείτε να τον πιάσετε εκεί. Ναι, υπάρχουν τέτοια πράγματα, μπορούν να χρησιμοποιηθούν. συν μέσα του Γράφω επίσης ένα πράγμα που σας επιτρέπει να κάνετε το ίδιο.
Υ.Γ.1 Εάν χρησιμοποιείτε το postgres_exporter, ποιον πίνακα ελέγχου χρησιμοποιείτε; Υπάρχουν αρκετά από αυτά. Είναι ήδη ξεπερασμένα. Μπορεί η κοινότητα να δημιουργήσει ένα ενημερωμένο πρότυπο;
Το PS2 αφαιρέθηκε το pganalyze καθώς είναι μια ιδιόκτητη προσφορά SaaS που εστιάζει στην παρακολούθηση της απόδοσης και τις αυτοματοποιημένες προτάσεις συντονισμού.
Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. , Σας παρακαλούμε.
Ποια αυτο-φιλοξενούμενη παρακολούθηση postgresql (με πίνακα ελέγχου) πιστεύετε ότι είναι η καλύτερη;
-
30,0%Zabbix + προσθήκες από τον Alexey Lesovsky ή zabbix 4.4 ή libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%Το pganalyze είναι ένα αποκλειστικό SaaS - δεν μπορεί να διαγραφεί1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
Ψήφισαν 10 χρήστες. 26 χρήστες απείχαν.
Πηγή: www.habr.com