Αλλάξτε ένα πράγμα, μετρήστε ξανά. Πώς βρίσκετε το πραγματικό bottleneck

Όταν μια πλατφόρμα είναι αργή, η πιο γρήγορη παραγγελία είναι για περισσότερα απ' όλα. Συχνά δουλεύει λίγο, κοστίζει πολύ, και αφήνει την πραγματική αιτία στη θέση της για να δαγκώσει ξανά στην επόμενη κορύφωση κίνησης. Η εναλλακτική είναι λιγότερο συναρπαστική και πολύ πιο αποτελεσματική: βρείτε τον έναν πόρο για τον οποίο περιμένει ο φόρτος εργασίας, αλλάξτε ένα πράγμα σε αυτόν, και μετρήστε ξανά. Να η μέθοδος και τα εργαλεία.

Ξεκινήστε με έναν αριθμό, όχι με μια αίσθηση

Το «το site είναι αργό» δεν μπορεί να ελεγχθεί. Το «το checkout παίρνει τέσσερα δευτερόλεπτα στη βραδινή αιχμή και κάτω από ένα τη νύχτα» μπορεί. Πριν αγγίξετε οτιδήποτε, καρφώστε το σύμπτωμα σε μια μέτρηση που μπορείτε να επαναλάβετε: έναν χρόνο σελίδας από έξω, μια διάρκεια query, τον χρόνο εκτέλεσης μιας batch εργασίας, έναν ρυθμό αιτημάτων στον οποίο ξεκινούν τα σφάλματα. Αυτός ο αριθμός είναι ο τρόπος που θα ξέρετε αν κάτι που αλλάξατε βοήθησε. Χωρίς αυτόν, κάθε αλλαγή μοιάζει με πρόοδο.

Μετά γράψτε τη διαδρομή που ακολουθεί η αργή λειτουργία: client, δίκτυο, load balancer, web server, εφαρμογή, cache, βάση δεδομένων, storage. Το bottleneck είναι κάπου σε αυτή τη διαδρομή, και η διαδρομή σάς λέει πού να κοιτάξετε.

Ελέγξτε κάθε πόρο για χρήση, κορεσμό και σφάλματα

Μια απλή πειθαρχία, που έκανε γνωστή ο Brendan Gregg ως μέθοδο USE, κρατά την αναζήτηση τίμια. Για κάθε πόρο στη διαδρομή, CPU, μνήμη, δίκτυο, storage, κάντε τρεις ερωτήσεις: πόσο απασχολημένος είναι, περιμένει δουλειά σε ουρά γι' αυτόν, και αναφέρει σφάλματα; Ένας πόρος μπορεί να έχει ελαφριά χρήση και πάλι να είναι το πρόβλημα αν τα αιτήματα στοιβάζονται μπροστά του, άρα η δεύτερη ερώτηση μετράει περισσότερο.

CPU.

mpstat -P ALL 1
vmstat 1
pidstat -u 1

Κοιτάξτε τη χρήση ανά πυρήνα, όχι μόνο τον μέσο όρο. Ένας πυρήνας σε πλήρες φορτίο ενώ οι υπόλοιποι αδρανούν δείχνει σε single-threaded bottleneck που περισσότεροι πυρήνες δεν θα διορθώσουν. Στο vmstat, μια run queue (r) επίμονα μεγαλύτερη από τον αριθμό των πυρήνων είναι κορεσμός.

Μνήμη.

free -h
vmstat 1
cat /proc/pressure/memory

Η πίεση μνήμης φαίνεται ως δραστηριότητα reclaim και χρόνος stall στο αρχείο pressure. Σε μια σωστά χτισμένη εικονική μηχανή δεν υπάρχει swap για να κρυφτεί, άρα ένας φόρτος εργασίας που χρειάζεται πραγματικά περισσότερη μνήμη απ' όση έχει αποτυγχάνει ηχηρά, που είναι το τίμιο αποτέλεσμα: η διόρθωση είναι περισσότερη μνήμη ή μια πιο λιτή εφαρμογή.

Storage.

iostat -x 1
pidstat -d 1

Οι στήλες που μετράνε είναι οι μέσοι χρόνοι αναμονής για reads και writes και το μέγεθος της ουράς. Το %util παραπλανά σε flash και SAN volumes, που εξυπηρετούν πολλά αιτήματα παράλληλα και μπορεί να δείχνουν υψηλή χρήση ενώ έχουν ακόμα άφθονο περιθώριο. Αυξανόμενοι χρόνοι αναμονής με ουρά που μεγαλώνει είναι το πραγματικό σήμα.

Δίκτυο.

sar -n DEV 1
sar -n EDEV 1
ss -s
cat /proc/net/bonding/bond0
ethtool -S <interface> | grep -iE 'drop|err|discard'

Συγκρίνετε την κίνηση ανά μέλος ενός bond: ένα μέλος απασχολημένο ενώ το άλλο αδρανεί είναι πρόβλημα hashing, όχι πρόβλημα bandwidth. Drops και σφάλματα στους μετρητές του interface δείχνουν κάτω από το λειτουργικό σύστημα, σε καλώδια, optics ή στο switch.

Βάση δεδομένων. Πολλές αργές πλατφόρμες είναι μια βάση δεδομένων που διαβάζει από τον δίσκο αυτό που θα έπρεπε να διαβάζει από τη μνήμη. Σε MySQL ή MariaDB, συγκρίνετε τα λογικά reads με τα reads που έπρεπε να πάνε στο storage:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Αν το Innodb_buffer_pool_reads (reads που δεν βρήκαν τη μνήμη) μεγαλώνει γρήγορα σε σχέση με το Innodb_buffer_pool_read_requests, το working set δεν χωρά στο buffer pool. Το slow query log, με λογικό κατώφλι, σας λέει ποια queries το πληρώνουν.

Αλλάξτε ένα πράγμα

Μόλις ένας πόρος ξεχωρίσει, διατυπώστε μια υπόθεση που εξηγεί τον αρχικό αριθμό, και κάντε μία μόνο αλλαγή που την ελέγχει: ένα buffer pool διαστασιολογημένο στο working set, μια πολιτική hash για το bond, μια cache μπροστά από την ακριβή σελίδα, ένα query που παίρνει το index που χρειάζεται, μια VM που αλλάζει μέγεθος για να χωρά σε ένα CPU socket. Μία αλλαγή τη φορά, γιατί αν αλλάξετε τρία πράγματα και ο αριθμός βελτιωθεί, δεν ξέρετε ποιο βοήθησε, και μπορεί να έχετε κρατήσει δύο που έκαναν τα πράγματα χειρότερα.

Μετρήστε ξανά, με τον ίδιο τρόπο

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

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

Πώς μοιάζει στην πράξη

Μερικές από τις πιο αποτελεσματικές ρυθμίσεις είναι μία γραμμή. Διαστασιολογούμε τα buffers μνήμης των βάσεων δεδομένων ώστε τα «καυτά» δεδομένα να ζουν στη RAM και το flash να εξυπηρετεί πραγματική δουλειά, και κάθε server με bond που χτίζουμε κάνει hash σε διευθύνσεις και θύρες ώστε και οι δύο γραμμές να μεταφέρουν κίνηση. Και τα δύο είναι πάγιοι κανόνες σε κάθε πλατφόρμα που διαχειριζόμαστε.

Πώς το κάνουμε εμείς

Η δουλειά επιδόσεων είναι ο τρόπος που λειτουργούμε κάθε πλατφόρμα που διαχειριζόμαστε, όχι ξεχωριστό προϊόν. Μετράμε σε κάθε επίπεδο, από το I/O ανά volume στις συστοιχίες και τους μετρητές ανά θύρα σε bonds και switches μέχρι τα slow logs στις βάσεις δεδομένων και τον χρόνο απ' έξω προς τα μέσα μέσω του CDN, πριν ονομάσουμε μια αιτία. Πάγιοι κανόνες που είναι αξιόπιστα σωστοί, όπως bonds που χρησιμοποιούν και τις δύο γραμμές, flash που αντιμετωπίζεται ως flash και VMs που χωρούν μέσα σε ένα socket, εφαρμόζονται σε κάθε build. Όταν μια πλατφόρμα χρειάζεται όντως περισσότερη χωρητικότητα, σας λέμε ποιον πόρο, πόσο και γιατί.

Αν η πλατφόρμα σας είναι αργή και η μόνη πρόταση μέχρι τώρα ήταν ένας μεγαλύτερος server, αφήστε μας να τη μετρήσουμε πρώτα.

Μιλήστε με έναν μηχανικό

Related

Σχετικά: Μηχανική επιδόσεων και χωρητικότητας · Bare metal servers σε HPE και Dell · Enterprise SAN storage σε HPE 3PAR, all-flash