Το Zabbix είναι ένα σύστημα παρακολούθησης. Όπως κάθε άλλο σύστημα, αντιμετωπίζει τρία κύρια προβλήματα όλων των συστημάτων παρακολούθησης: συλλογή και επεξεργασία δεδομένων, αποθήκευση ιστορικού και εκκαθάριση.
Τα στάδια λήψης, επεξεργασίας και καταγραφής δεδομένων απαιτούν χρόνο. Όχι πολύ, αλλά για ένα μεγάλο σύστημα, αυτό μπορεί να οδηγήσει σε μεγάλες καθυστερήσεις. Το πρόβλημα αποθήκευσης είναι θέμα πρόσβασης δεδομένων. Χρησιμοποιούνται για αναφορές, ελέγχους και ενεργοποιήσεις. Οι καθυστερήσεις πρόσβασης στα δεδομένα επηρεάζουν επίσης την απόδοση. Όταν η βάση δεδομένων μεγαλώνει, άσχετα δεδομένα πρέπει να διαγραφούν. Η διαγραφή είναι μια βαριά λειτουργία που επίσης καταναλώνει κάποιους πόρους.
Τα προβλήματα καθυστέρησης συλλογής και αποθήκευσης στο Zabbix επιλύονται με προσωρινή αποθήκευση: αρκετοί τύποι κρυφής μνήμης, προσωρινή αποθήκευση στη βάση δεδομένων. Για την επίλυση του τρίτου προβλήματος, η προσωρινή αποθήκευση δεν είναι κατάλληλη, επομένως χρησιμοποιήθηκε το TimescaleDB στο Zabbix. Θα πει για αυτό Andrey Gushchin - Μηχανικός Τεχνικής Υποστήριξης . Ο Andrey υποστηρίζει το Zabbix για πάνω από 6 χρόνια και ασχολείται άμεσα με τις επιδόσεις.
Πώς λειτουργεί το TimescaleDB, τι απόδοση μπορεί να δώσει σε σύγκριση με την κανονική PostgreSQL; Τι ρόλο παίζει το Zabbix στο TimescaleDB; Πώς να ξεκινήσετε από το μηδέν και πώς να κάνετε μετεγκατάσταση από το PostgreSQL και ποια απόδοση διαμόρφωσης είναι καλύτερη; Όλα αυτά κάτω από το κόψιμο.
Προκλήσεις απόδοσης
Κάθε σύστημα παρακολούθησης αντιμετωπίζει ορισμένες προκλήσεις απόδοσης. Θα μιλήσω για τρία από αυτά: συλλογή και επεξεργασία δεδομένων, αποθήκευση, καθαρισμός ιστορικού.
Γρήγορη συλλογή και επεξεργασία δεδομένων. Ένα καλό σύστημα παρακολούθησης θα πρέπει να λαμβάνει γρήγορα όλα τα δεδομένα και να τα επεξεργάζεται σύμφωνα με εκφράσεις ενεργοποίησης - σύμφωνα με τα δικά του κριτήρια. Μετά την επεξεργασία, το σύστημα πρέπει επίσης να αποθηκεύσει γρήγορα αυτά τα δεδομένα στη βάση δεδομένων για να τα χρησιμοποιήσει αργότερα.
Αποθήκευση ιστορικού. Ένα καλό σύστημα παρακολούθησης θα πρέπει να αποθηκεύει το ιστορικό σε μια βάση δεδομένων και να παρέχει εύκολη πρόσβαση στις μετρήσεις. Το ιστορικό απαιτείται για χρήση σε αναφορές, γραφήματα, κανόνες ενεργοποίησης, όρια και υπολογισμένα στοιχεία ειδοποίησης.
Εκκαθάριση ιστορικού. Μερικές φορές έρχεται μια μέρα που δεν χρειάζεται να αποθηκεύσετε μετρήσεις. Γιατί χρειάζεστε δεδομένα που συλλέχθηκαν πριν από 5 χρόνια, έναν ή δύο μήνες: ορισμένοι κόμβοι έχουν αφαιρεθεί, ορισμένοι κεντρικοί υπολογιστές ή μετρήσεις δεν χρειάζονται πλέον, επειδή είναι ξεπερασμένοι και δεν συλλέγονται πλέον. Ένα καλό σύστημα παρακολούθησης θα πρέπει να αποθηκεύει ιστορικά δεδομένα και να τα διαγράφει από καιρό σε καιρό, έτσι ώστε η βάση δεδομένων να μην μεγαλώνει.
Η εκκαθάριση των παλιών δεδομένων είναι ένα ακανθώδες ζήτημα που έχει μεγάλο αντίκτυπο στην απόδοση της βάσης δεδομένων.
Προσωρινή αποθήκευση στο Zabbix
Στο Zabbix, η πρώτη και η δεύτερη κλήση επιλύονται με χρήση προσωρινής αποθήκευσης. Η μνήμη RAM χρησιμοποιείται για τη συλλογή και επεξεργασία δεδομένων. Για αποθήκευση - ιστορικό σε κανόνες ενεργοποίησης, γραφήματα και υπολογισμένα στοιχεία. Στην πλευρά του DB, υπάρχει κάποια προσωρινή αποθήκευση για βασικές επιλογές, όπως γραφήματα.
Η προσωρινή αποθήκευση στο πλάι του ίδιου του διακομιστή Zabbix είναι:
- ConfigurationCache;
- ValueCache;
- HistoryCache;
- TrendsCache.
Εξετάστε τα με περισσότερες λεπτομέρειες.
ConfigurationCache
Αυτή είναι η κύρια κρυφή μνήμη στην οποία αποθηκεύουμε μετρήσεις, κεντρικούς υπολογιστές, στοιχεία δεδομένων, κανόνες ενεργοποίησης - όλα όσα χρειάζονται για την Προεπεξεργασία και τη συλλογή δεδομένων.
Όλα αυτά αποθηκεύονται στο ConfigurationCache για να μην δημιουργούνται περιττά ερωτήματα στη βάση δεδομένων. Μετά την εκκίνηση του διακομιστή, ενημερώνουμε αυτήν την προσωρινή μνήμη, δημιουργούμε και ενημερώνουμε περιοδικά τις διαμορφώσεις.
Συλλογή δεδομένων
Το σχέδιο είναι αρκετά μεγάλο, αλλά το κύριο πράγμα σε αυτό είναι συλλέκτες. Πρόκειται για διάφορα "pollers" - διαδικασίες συναρμολόγησης. Είναι υπεύθυνοι για διαφορετικούς τύπους συναρμολόγησης: συλλέγουν δεδομένα μέσω SNMP, IPMI και τα μεταφέρουν όλα στην Προεπεξεργασία.
Οι συλλέκτες είναι κυκλωμένοι σε πορτοκαλί χρώμα.
Το Zabbix έχει υπολογίσει στοιχεία συγκέντρωσης που χρειάζονται για τη συγκέντρωση των επιταγών. Αν τα έχουμε, παίρνουμε τα δεδομένα για αυτά απευθείας από το ValueCache.
Προεπεξεργασία HistoryCache
Όλοι οι συλλέκτες χρησιμοποιούν το ConfigurationCache για να λαμβάνουν εργασίες. Στη συνέχεια τα περνούν στην Προεπεξεργασία.
Η Προεπεξεργασία χρησιμοποιεί το ConfigurationCache για να λάβει τα βήματα Προεπεξεργασίας. Επεξεργάζεται αυτά τα δεδομένα με διάφορους τρόπους.
Αφού επεξεργαστούμε τα δεδομένα με το PreProcessing, τα αποθηκεύουμε στο HistoryCache για να τα επεξεργαστούμε. Αυτό ολοκληρώνει τη συλλογή δεδομένων και προχωράμε στην κύρια διαδικασία στο Zabbix - συγχρονιστής ιστορικού, καθώς πρόκειται για μονολιθική αρχιτεκτονική.
Σημείωση: Η προεπεξεργασία είναι μια αρκετά βαριά λειτουργία. Από την έκδοση 4.2 έχει μετακινηθεί σε διακομιστή μεσολάβησης. Εάν έχετε ένα πολύ μεγάλο Zabbix με μεγάλο αριθμό αντικειμένων και συχνότητα συλλογής, τότε αυτό κάνει τα πράγματα πολύ πιο εύκολα.
Προσωρινή μνήμη ValueCache, ιστορικό και τάσεις
Ο συγχρονισμός ιστορικού είναι η κύρια διαδικασία που επεξεργάζεται ατομικά κάθε στοιχείο δεδομένων, δηλαδή κάθε τιμή.
Ο συγχρονισμός ιστορικού λαμβάνει τιμές από το HistoryCache και ελέγχει τη Διαμόρφωση για ενεργοποιητές για υπολογισμούς. Αν είναι - υπολογίζει.
Ο συγχρονισμός ιστορικού δημιουργεί ένα συμβάν, κλιμακώνεται για τη δημιουργία ειδοποιήσεων εάν απαιτείται από τη διαμόρφωση και καταγράφει. Εάν υπάρχουν ενδείξεις για περαιτέρω επεξεργασία, τότε θυμάται αυτήν την τιμή στο ValueCache ώστε να μην αναφέρεται στον πίνακα ιστορικού. Αυτός είναι ο τρόπος με τον οποίο η ValueCache γεμίζει με τα δεδομένα που απαιτούνται για τον υπολογισμό των ενεργειών, των υπολογισμένων στοιχείων.
Ο συγχρονισμός ιστορικού εγγράφει όλα τα δεδομένα στη βάση δεδομένων και εγγράφει στο δίσκο. Η διαδικασία επεξεργασίας τελειώνει εδώ.
Προσωρινή αποθήκευση DB
Υπάρχουν διάφορες κρυφές μνήμες στην πλευρά του DB όταν θέλετε να δείτε γραφήματα ή αναφορές συμβάντων:
Innodb_buffer_poolστην πλευρά της MySQL.shared_buffersστην πλευρά PostgreSQL.effective_cache_sizeστην πλευρά της Oracle.shared_poolστην πλευρά DB2.
Υπάρχουν πολλές άλλες κρυφές μνήμες, αλλά αυτές είναι οι κύριες για όλες τις βάσεις δεδομένων. Σας επιτρέπουν να διατηρείτε δεδομένα στη μνήμη RAM που χρειάζονται συχνά για ερωτήματα. Έχουν τη δική τους τεχνολογία για αυτό.
Η απόδοση της βάσης δεδομένων είναι κρίσιμη
Ο διακομιστής Zabbix συλλέγει συνεχώς δεδομένα και τα καταγράφει. Κατά την επανεκκίνηση, διαβάζει επίσης από το ιστορικό για να γεμίσει το ValueCache. Χρήσεις σεναρίων και αναφορών Zabbix API, το οποίο είναι χτισμένο με βάση τη διεπαφή Ιστού. Το Zabbix API έχει πρόσβαση στη βάση δεδομένων και ανακτά τα απαραίτητα δεδομένα για γραφήματα, αναφορές, λίστες συμβάντων και πρόσφατα ζητήματα.
Για οπτικοποίηση - Γκράφανα. Αυτή είναι μια δημοφιλής λύση μεταξύ των χρηστών μας. Μπορεί να στείλει απευθείας αιτήματα μέσω του Zabbix API και στη βάση δεδομένων και δημιουργεί μια ορισμένη ταυτόχρονη λήψη δεδομένων. Επομένως, απαιτείται καλύτερος και καλύτερος συντονισμός της βάσης δεδομένων για να ταιριάζει με την ταχεία παράδοση των αποτελεσμάτων και τις δοκιμές.
Οικονόμος
Η τρίτη πρόκληση απόδοσης στο Zabbix είναι το καθάρισμα της ιστορίας με το Housekeeper. Σέβεται όλες τις ρυθμίσεις - τα στοιχεία δεδομένων υποδεικνύουν πόσο χρόνο θα αποθηκευτεί η δυναμική των αλλαγών (τάσεις) σε ημέρες.
TrendsCache υπολογίζουμε εν κινήσει. Όταν έρχονται τα δεδομένα, τα συγκεντρώνουμε σε μία ώρα και τα τοποθετούμε σε πίνακες για τη δυναμική των αλλαγών των τάσεων.
Το Housekeeper ξεκινά και αφαιρεί πληροφορίες από τη βάση δεδομένων με τις συνήθεις "επιλογές". Αυτό δεν είναι πάντα αποτελεσματικό, κάτι που μπορεί να γίνει κατανοητό από τα γραφήματα απόδοσης των εσωτερικών διεργασιών.
Το κόκκινο γράφημα δείχνει ότι ο συγχρονιστής ιστορικού είναι συνεχώς απασχολημένος. Το πορτοκαλί γράφημα στην κορυφή είναι το Housekeeper, το οποίο τρέχει συνεχώς. Περιμένει από τη βάση δεδομένων να διαγράψει όλες τις σειρές που έχει καθορίσει.
Πότε πρέπει να απενεργοποιήσετε το Housekeeper; Για παράδειγμα, υπάρχει ένα "Item ID" και πρέπει να διαγράψετε τις τελευταίες 5 χιλιάδες γραμμές σε ένα συγκεκριμένο χρονικό διάστημα. Φυσικά, αυτό συμβαίνει με ευρετήρια. Αλλά συνήθως το σύνολο δεδομένων είναι πολύ μεγάλο και η βάση δεδομένων εξακολουθεί να διαβάζει από το δίσκο και να το τοποθετεί στην κρυφή μνήμη. Αυτή είναι πάντα μια πολύ δαπανηρή λειτουργία για τη βάση δεδομένων και, ανάλογα με το μέγεθος της βάσης δεδομένων, μπορεί να οδηγήσει σε προβλήματα απόδοσης.
Ο οικονόμος είναι εύκολο να απενεργοποιηθεί. Στη διεπαφή Ιστού, υπάρχει μια ρύθμιση στο "Γενική διαχείριση" για το Housekeeper. Απενεργοποιήστε το εσωτερικό νοικοκυριό για το εσωτερικό ιστορικό τάσεων και δεν το ελέγχει πλέον.
Το Housekeeper έχει απενεργοποιηθεί, τα γραφικά έχουν ισοπεδωθεί - ποια θα μπορούσαν να είναι τα προβλήματα σε αυτήν την περίπτωση και τι μπορεί να βοηθήσει στην επίλυση της τρίτης πρόκλησης απόδοσης;
Διαμέριση - κατάτμηση ή κατάτμηση
Η κατάτμηση συνήθως ρυθμίζεται με διαφορετικό τρόπο σε κάθε σχεσιακή βάση δεδομένων που έχω παραθέσει. Το καθένα έχει τη δική του τεχνολογία, αλλά είναι παρόμοια, γενικά. Η δημιουργία ενός νέου διαμερίσματος οδηγεί συχνά σε ορισμένα προβλήματα.
Συνήθως, τα διαμερίσματα διαμορφώνονται ανάλογα με το "setup" - τον όγκο των δεδομένων που δημιουργείται σε μία ημέρα. Κατά κανόνα, η κατάτμηση ρυθμίζεται σε μία ημέρα, αυτό είναι το ελάχιστο. Για νέες τάσεις διαμερισμάτων — 1 μήνας.
Οι τιμές μπορεί να αλλάξουν σε περίπτωση πολύ μεγάλης "ρύθμισης". Εάν μια μικρή "ρύθμιση" είναι έως 5 nvps (νέες τιμές ανά δευτερόλεπτο), η μέση τιμή είναι από 000 έως 5, τότε μια μεγάλη είναι πάνω από 000 nvps. Πρόκειται για μεγάλες και πολύ μεγάλες εγκαταστάσεις που απαιτούν προσεκτική διαμόρφωση της ίδιας της βάσης δεδομένων.
Σε πολύ μεγάλες εγκαταστάσεις, μια μέρα μπορεί να μην είναι η βέλτιστη. Έχω δει κατατμήσεις MySQL 40 GB ή περισσότερο την ημέρα. Πρόκειται για έναν πολύ μεγάλο όγκο δεδομένων που μπορεί να οδηγήσει σε προβλήματα και πρέπει να μειωθεί.
Τι δίνει το Partitioning;
Πίνακες χωρισμάτων. Συχνά αυτά είναι ξεχωριστά αρχεία στο δίσκο. Το σχέδιο ερωτήματος επιλέγει ένα διαμέρισμα πιο βέλτιστα. Συνήθως η κατάτμηση χρησιμοποιείται ανά περιοχή - αυτό ισχύει και για το Zabbix. Χρησιμοποιούμε εκεί τη "χρονοσήμανση" - τον χρόνο από την αρχή της εποχής. Έχουμε κανονικά νούμερα. Ορίζετε την αρχή και το τέλος της ημέρας - αυτό είναι ένα διαμέρισμα.
Γρήγορη αφαίρεση - DELETE. Επιλέγεται ένα αρχείο/υποπίνακας, όχι μια επιλογή σειρών για διαγραφή.
Επιταχύνει σημαντικά τη δειγματοληψία δεδομένων SELECT - χρησιμοποιεί ένα ή περισσότερα διαμερίσματα, όχι ολόκληρο τον πίνακα. Εάν έχετε πρόσβαση σε δεδομένα δύο ημερών, τα ανακτά από τη βάση δεδομένων πιο γρήγορα, επειδή πρέπει μόνο να τα φορτώσετε στην κρυφή μνήμη και να επιστρέψετε μόνο ένα αρχείο, όχι έναν μεγάλο πίνακα.
Συχνά πολλές βάσεις δεδομένων επιταχύνουν επίσης INSERT - ένθετα στο παιδικό τραπέζι.
TimescaleDB
Για την έκδοση 4.2 στρέψαμε την προσοχή μας στο TimescaleDB. Αυτή είναι μια επέκταση PostgreSQL με εγγενή διεπαφή. Η επέκταση λειτουργεί αποτελεσματικά με δεδομένα χρονοσειρών χωρίς να χάνει τα πλεονεκτήματα των σχεσιακών βάσεων δεδομένων. Το TimescaleDB διαχωρίζει επίσης αυτόματα.
Το TimescaleDB έχει μια ιδέα υπερτραπέζιος (υπερπίνακας) που δημιουργείτε. Σε αυτό είναι κομμάτια - χωρίσματα. Τα κομμάτια είναι τμήματα αυτόματης διαχείρισης ενός υπερπίνακα που δεν επηρεάζουν άλλα τμήματα. Κάθε κομμάτι έχει το δικό του χρονικό εύρος.
TimescaleDB εναντίον PostgreSQL
Το TimescaleDB είναι πραγματικά αποτελεσματικό. Οι παραγωγοί της επέκτασης ισχυρίζονται ότι χρησιμοποιούν έναν πιο σωστό αλγόριθμο επεξεργασίας ερωτημάτων, ιδίως inserts . Καθώς το μέγεθος του ένθετου συνόλου δεδομένων μεγαλώνει, ο αλγόριθμος διατηρεί σταθερή απόδοση.
Μετά από 200 εκατομμύρια σειρές, η PostgreSQL συνήθως αρχίζει να πέφτει πολύ και να χάνει την απόδοση στο 0. Το TimescaleDB σάς επιτρέπει να εισάγετε αποτελεσματικά "εισαγωγές" με οποιοδήποτε όγκο δεδομένων.
Εγκατάσταση
Η εγκατάσταση του TimescaleDB είναι αρκετά εύκολη για οποιαδήποτε πακέτα. ΣΕ όλα είναι λεπτομερή - εξαρτάται από τα επίσημα πακέτα PostgreSQL. Το TimescaleDB μπορεί επίσης να κατασκευαστεί και να μεταγλωττιστεί με το χέρι.
Για τη βάση δεδομένων Zabbix, ενεργοποιούμε απλώς την επέκταση:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
ενεργοποιείτε extension και δημιουργήστε το για τη βάση δεδομένων Zabbix. Το τελευταίο βήμα είναι να δημιουργήσετε έναν υπερπίνακα.
Μετεγκατάσταση πινάκων ιστορικού στο TimescaleDB
Υπάρχει μια ειδική λειτουργία για αυτό. create_hypertable:
SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1
Η συνάρτηση έχει τρεις παραμέτρους. Πρώτα - πίνακα στη βάση δεδομένωνΑυτό για το οποίο θέλετε να δημιουργήσετε έναν υπερπίνακα. Δεύτερο - πεδίο, σύμφωνα με την οποία είναι απαραίτητο να δημιουργηθεί chunk_time_interval — το διάστημα των τμημάτων διαμερισμάτων που θα χρησιμοποιηθούν. Στην περίπτωσή μου, το διάστημα είναι μία ημέρα - 86.
Η τρίτη παράμετρος είναι migrate_data. Εάν έχει οριστεί true, τότε όλα τα τρέχοντα δεδομένα μεταφέρονται σε προδημιουργημένα κομμάτια. Εγώ ο ίδιος έχω χρησιμοποιήσει migrate_data. Είχα περίπου 1 TB που χρειάστηκε πάνω από μία ώρα. Ακόμη και σε ορισμένες περιπτώσεις, κατά τη δοκιμή, διέγραψα τα ιστορικά δεδομένα τύπων χαρακτήρων που είναι προαιρετικά για αποθήκευση, ώστε να μην τα μεταφέρω.
Τελευταίο βήμα - UPDATE: στο db_extension βάζω timescaledbώστε η βάση δεδομένων να καταλάβει ότι υπάρχει αυτή η επέκταση. Το Zabbix το ενεργοποιεί και χρησιμοποιεί σωστά τη σύνταξη και τα ερωτήματα που βρίσκονται ήδη στη βάση δεδομένων - αυτές οι δυνατότητες που είναι απαραίτητες για το TimescaleDB.
Διαμόρφωση υλικού
Χρησιμοποίησα δύο διακομιστές. Πρώτα - Μηχανή VMware. Είναι αρκετά μικρό: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 GHz, 16 GB μνήμης RAM και μονάδα SSD 200 GB.
Εγκατέστησα το PostgreSQL 10.8 σε αυτό με το Debian OS 10.8-1.pgdg90+1 και το σύστημα αρχείων xfs. Ρύθμισα τα πάντα ελάχιστα για να χρησιμοποιήσω τη συγκεκριμένη βάση δεδομένων, μείον αυτό που θα χρησιμοποιήσει το ίδιο το Zabbix.
Στο ίδιο μηχάνημα υπήρχε διακομιστής Zabbix, PostgreSQL και πράκτορες φόρτωσης. Είχα 50 ενεργούς παράγοντες που χρησιμοποιούσαν LoadableModuleγια να δημιουργήσετε διάφορα αποτελέσματα πολύ γρήγορα: αριθμούς, συμβολοσειρές. Γέμισα τη βάση δεδομένων με πολλά δεδομένα.
Αρχικά, η διαμόρφωση περιείχε 5 είδη δεδομένα ανά κεντρικό υπολογιστή. Σχεδόν κάθε στοιχείο περιείχε μια σκανδάλη για να μοιάζει με πραγματικές εγκαταστάσεις. Σε ορισμένες περιπτώσεις υπήρχαν περισσότερες από μία σκανδάλες. Ένας κόμβος δικτύου είχε 3-000 σκανδάλες.
Διάστημα ενημέρωσης αντικειμένου − 4 7-δευτερόλεπτα. Ρύθμισα το ίδιο το φορτίο χρησιμοποιώντας όχι μόνο 50 πράκτορες, αλλά προσθέτοντας περισσότερους. Επίσης, με τη βοήθεια στοιχείων δεδομένων, ρύθμισα δυναμικά το φορτίο και μείωσα το διάστημα ενημέρωσης στα 4 δευτερόλεπτα.
PostgreSQL. 35 nvps
Η πρώτη μου εκτέλεση σε αυτό το υλικό ήταν σε καθαρή PostgreSQL - 35 χιλιάδες τιμές ανά δευτερόλεπτο. Όπως μπορείτε να δείτε, η εισαγωγή δεδομένων διαρκεί κλάσματα του δευτερολέπτου - όλα είναι καλά και γρήγορα. Το μόνο πράγμα είναι ότι η μονάδα SSD των 200 GB γεμίζει γρήγορα.
Αυτός είναι ένας τυπικός πίνακας εργαλείων απόδοσης διακομιστή Zabbix.
Το πρώτο μπλε γράφημα είναι ο αριθμός των τιμών ανά δευτερόλεπτο. Το δεύτερο γράφημα στα δεξιά φορτώνει τις διαδικασίες κατασκευής. Το τρίτο είναι η φόρτωση των εσωτερικών διαδικασιών κατασκευής: ιστορικού συγχρονισμού και Housekeeper, που εκτελείται εδώ και αρκετό καιρό.
Το τέταρτο γράφημα δείχνει τη χρήση του HistoryCache. Αυτό είναι ένα είδος buffer πριν από την εισαγωγή στη βάση δεδομένων. Το πράσινο πέμπτο γράφημα δείχνει τη χρήση του ValueCache, δηλαδή πόσες επισκέψεις ValueCache για κανόνες ετικέτας είναι αρκετές χιλιάδες τιμές ανά δευτερόλεπτο.
PostgreSQL. 50 nvps
Στη συνέχεια αύξησα το φορτίο σε 50 χιλιάδες τιμές ανά δευτερόλεπτο στο ίδιο υλικό.
Κατά τη φόρτωση από το Housekeeper, η εισαγωγή 10 χιλιάδων τιμών χρειάστηκε 2-3 δευτερόλεπτα.
Η οικονόμος έχει ήδη αρχίσει να εμποδίζει.
Το τρίτο γράφημα δείχνει ότι, γενικά, η φόρτωση παγιδευτών και συγχρονιστών ιστορικού εξακολουθεί να είναι στο επίπεδο του 60%. Στο τέταρτο γράφημα, η HistoryCache κατά τη λειτουργία του Housekeeper αρχίζει ήδη να γεμίζει αρκετά ενεργά. Είναι γεμάτο κατά 20% - περίπου 0,5 GB.
PostgreSQL. 80 nvps
Στη συνέχεια αύξησα το φορτίο σε 80 χιλιάδες τιμές ανά δευτερόλεπτο. Πρόκειται για περίπου 400 χιλιάδες στοιχεία δεδομένων και 280 χιλιάδες ενεργοποιητές.
Το ένθετο φόρτωσης των τριάντα συγχρονιστών ιστορικού είναι ήδη αρκετά υψηλό.
Αύξησα επίσης διάφορες παραμέτρους: συγχρονιστές ιστορικού, κρυφές μνήμες.
Στο υλικό μου, η φόρτωση των συγχρονιστών ιστορικού αυξήθηκε στο μέγιστο. Το HistoryCache γέμισε γρήγορα με δεδομένα - το buffer έχει συσσωρεύσει δεδομένα για επεξεργασία.
Όλο αυτό το διάστημα, παρακολουθούσα πώς χρησιμοποιήθηκαν ο επεξεργαστής, η μνήμη RAM και άλλες παράμετροι του συστήματος και διαπίστωσα ότι η χρήση του δίσκου ήταν μέγιστη.
έχω κάνει χρήση μέγιστη χωρητικότητα δίσκου σε αυτό το υλικό και σε αυτήν την εικονική μηχανή. Με τέτοια ένταση, η PostgreSQL άρχισε να απορρίπτει δεδομένα αρκετά ενεργά και ο δίσκος δεν είχε πλέον χρόνο για εγγραφή και ανάγνωση.
Δεύτερος διακομιστής
Πήρα έναν άλλο διακομιστή που είχε ήδη 48 επεξεργαστές και 128 GB μνήμης RAM. Το συντόνισα - ρύθμισα συγχρονισμό ιστορικού 60 και πέτυχα αποδεκτές επιδόσεις.
Στην πραγματικότητα, αυτό είναι ήδη ένα όριο απόδοσης όπου κάτι πρέπει να γίνει.
timescaledb. 80 nvps
Το κύριο καθήκον μου είναι να δοκιμάσω τις δυνατότητες του TimescaleDB έναντι ενός φορτίου Zabbix. 80 χιλιάδες τιμές ανά δευτερόλεπτο είναι πολλές, η συχνότητα συλλογής μετρήσεων (εκτός από το Yandex, φυσικά) και μια αρκετά μεγάλη "ρύθμιση".
Υπάρχει μια βουτιά σε κάθε γράφημα - αυτό είναι απλώς μια μετεγκατάσταση δεδομένων. Μετά τις αποτυχίες στον διακομιστή Zabbix, το προφίλ φόρτωσης του συγχρονιστή ιστορικού έχει αλλάξει πολύ - έπεσε τρεις φορές.
Το TimescaleDB σάς επιτρέπει να εισάγετε δεδομένα σχεδόν 3 φορές πιο γρήγορα και να χρησιμοποιείτε λιγότερο HistoryCache.
Αντίστοιχα, θα λαμβάνετε δεδομένα εγκαίρως.
timescaledb. 120 nvps
Στη συνέχεια αύξησα τον αριθμό των στοιχείων δεδομένων σε 500 χιλιάδες. Το κύριο καθήκον ήταν να ελέγξω τις δυνατότητες του TimescaleDB - έλαβα μια υπολογισμένη τιμή 125 χιλιάδων τιμών ανά δευτερόλεπτο.
Αυτή είναι μια λειτουργική "ρύθμιση" που μπορεί να πάρει πολύ χρόνο για να λειτουργήσει. Αλλά επειδή ο δίσκος μου ήταν μόνο 1,5 TB, τον γέμισα σε μερικές μέρες.
Το πιο σημαντικό, νέες κατατμήσεις TimescaleDB δημιουργούνταν ταυτόχρονα.
Για την απόδοση, αυτό είναι εντελώς απαρατήρητο. Όταν δημιουργούνται κατατμήσεις στη MySQL, για παράδειγμα, τα πράγματα είναι διαφορετικά. Αυτό συμβαίνει συνήθως τη νύχτα, επειδή εμποδίζει τη γενική εισαγωγή, τον χειρισμό του πίνακα και μπορεί να προκαλέσει υποβάθμιση της υπηρεσίας. Αυτό δεν συμβαίνει με το TimescaleDB.
Για παράδειγμα, θα δείξω ένα γράφημα από το σύνολο στην κοινότητα. Στην εικόνα, το TimescaleDB είναι ενεργοποιημένο, χάρη στο οποίο έχει πέσει το φορτίο στη χρήση του io.weight στον επεξεργαστή. Η χρήση στοιχείων εσωτερικών διαδικασιών έχει επίσης μειωθεί. Επιπλέον, αυτή είναι μια συνηθισμένη εικονική μηχανή σε συνηθισμένους δίσκους pancake και όχι SSD.
Ευρήματα
Το TimescaleDB είναι μια καλή λύση για μικρές "ρυθμίσεις", τα οποία βασίζονται στην απόδοση του δίσκου. Θα σας επιτρέψει να συνεχίσετε να εργάζεστε καλά έως ότου η βάση δεδομένων μεταφερθεί ταχύτερα στο υλικό.
Το TimescaleDB είναι εύκολο στη ρύθμιση, δίνει ώθηση στην απόδοση, λειτουργεί καλά με το Zabbix και έχει πλεονεκτήματα σε σχέση με την PostgreSQL.
Εάν χρησιμοποιείτε την PostgreSQL και δεν σκοπεύετε να την αλλάξετε, τότε σας προτείνω χρησιμοποιήστε την PostgreSQL με την επέκταση TimescaleDB σε συνδυασμό με το Zabbix. Αυτή η λύση λειτουργεί αποτελεσματικά μέχρι μεσαίου "setup".
Λέμε «υψηλές επιδόσεις» - εννοούμε . Δεν θα αργήσετε να γνωρίσετε τις τεχνολογίες και τις πρακτικές που επιτρέπουν στις υπηρεσίες να εξυπηρετούν εκατομμύρια χρήστες. Λίστα για τις 7 και 8 Νοεμβρίου έχουμε ήδη συντάξει, αλλά μπορούν να προταθούν περισσότερα.
Εγγραφείτε στο δικό μας и , στο οποίο αποκαλύπτουμε τα χαρακτηριστικά του επερχόμενου συνεδρίου και μαθαίνουμε πώς να αξιοποιήσετε στο έπακρο.
Πηγή: www.habr.com