sqlschool.gr logo

articles

Articles of SQLschool.gr Team

How to interpreting the results of DMV sys.dm_os_performance_counters

Antonios Chatzipavlis
Friday 08 November 2019

Overview

Η καθημερινότητα ενός DBA μόνο απλή δεν είναι, αν και πολλοί πιστεύουν αυτό.

Καθημερινά πρέπει να φροντίζει ώστε τα instance/databases του να είναι σε εύρυθμη λειτουργία. Για να το πετύχει αυτό παρακολουθεί αυτά στενά ώστε να ενεργεί προληπτικά/προδραστικά στις διάφορες καταστάσεις.

Παράλληλα έχει να φροντίσει για την εξέλιξη όλων αυτών ώστε ο οργανισμός να είναι σε θέση να ακολουθήσει τα κελεύσματα των καιρών μιας και όλοι πλέον μιλάνε για την 4η Βιομηχανική επανάσταση.

Αν λοιπόν βλέπετε ένα DBA να κοιτάζει μια οθόνη με νούμερα ή γραφήματα ή να διαβάζει το sqlschool.gr να είστε σίγουροι ότι είναι αρκετά απασχολημένος και ίσως προβληματισμένος για αυτό να μην τον απασχολείται με θέματα άλλα, το καλύτερο που έχετε να κάνετε είναι να του δώσετε ένα καφέ και πολύ νερό. Πιστέψτε με θα καταλάβετε πότε θα είναι έτοιμος να σας ακούσει.

The sys.dm_os_performance_counters DMV

Πολυαγαπημένε μου DBA,

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

Ένα από τα βασικά εργαλεία που έχεις στην διάθεση σου είναι τα performance counters που έχει ο SQL Server και τα οποία σου δείχνουν πολλά και ενδιαφέροντα πράγματα. Συνήθως για να δεις αυτά χρησιμοποιείς το performance monitor tool των windows.

Φαντάζομαι ότι γνωρίζεις ότι δεν είναι απαραίτητο να χρησιμοποιείς αυτό καθώς εδώ και πολλά χρόνια από την έκδοση του SQL Server 2008 (αν δεν με απατάει η μνήμη μου) υπάρχει ένα αρκετά χρήσιμο DMV το οποίο σου προσφέρει αυτή την πληροφορία εύκολα μέσα από την εκτέλεση ενός απλού query, και αυτό είναι το sys.dm_os_performance_counters.

Τι δεν έχει αυτό; Δεν σου επιστρέφει τα σχετικά με το OS performance counters όπως processor usage, disk activity κ.α. Ναι θέλουμε να τα είχαμε αλλά αυτό δεν σημαίνει ότι επειδή δεν τα έχουμε τώρα δεν θα χρησιμοποιήσουμε αυτό το καλό DMV. Δυστυχώς αυτό είναι το μεγαλύτερο λάθος που όλοι οι DBA κάνουν και μου θυμίζει την ιστορία που κάποιος ήθελε ένα άλογο για μεταφέρει τα ξύλα για το τζάκι του αλλά δεν είχε και κάποια στιγμή κάποιος του χάρισε ένα γάιδαρο και τον κοίταζε στα δόντια για να δει αν είναι γερά.

To συγκεκριμένo DMV εκτελείται εύκολα όπως παρακάτω

select * from sys.dm_os_performance_counters

Επιστρέφει 1663 rows / 46 counter categories / 592 counters (ανάλογα με την έκδοση του SQL Server ίσως φέρει και λιγότερα ή περισσότερα, τα νούμερα αυτά είναι από SQL Server 2017).

Σημείωση

Εάν το παρακάτω query επιστέψει μηδέν σημαίνει ότι οι performance counters έχουν απενεργοποιηθεί

select count(*) from sys.dm_os_performance_counters

Τα αποτελέσματα αποτελούνται από 5 columns οι οποίες είναι οι παρακάτω

οbject_name

Η κατηγορία που ο συγκεκριμένος counter ανήκει

counter_name

Το όνομα του counter

instance_name

To counter instance name, σε κάποιους είναι το instance σε άλλους το database name ή _Τotal και υποδεικνύει το σημείο αναφοράς του

cntr_value

Είναι η τρέχουσα τιμή του counter κατά την εκτέλεση του query. Ανάλογα με τον τον counter αυτή μπορεί να είναι cumulative όπως πχ για τους counters που είναι ανά second.

cntr_type

Η τιμή σε αυτή την κολώνα είναι η σημαντικότερη που πρέπει να γνωρίζει ένας DBA καθώς από αυτή θα καταλάβει το πως θα ερμηνεύσει την τιμή που διαβάζει στην προηγούμενη κολώνα.

Σε όλες τις εκδόσεις μέχρι τώρα στην κολώνα αυτή υπάρχουν 6 διακριτές τιμές που στην ουσία ορίζουν τον τύπο του counter όπως αυτός ορίζεται στο Windows performance architecture

Οι τιμές αυτές μαζί με τη ονομασία τους και την χρήση τους είναι οι παρακάτω:

65792 - PERF_COUNTER_LARGE_RAWCOUNT

Οι counters αυτοί επιστρέφουν την τελευταία παρατήρηση της τιμής και είναι decimal data type. Δεν είναι μέσος όρος. Συνήθως χρησιμοποιείται για count monitoring πχ

Στο object_name SQLServer:General Statistics και ο counter User Connections δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 4 που σημαίνει 4 χρήστες είναι αυτή την στιγμή συνδεδεμένοι στο instance

ή

Στο object_name SQLServer:Buffer Manager και ο counter Database Pages δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 4965 που σημαίνει 4965 page είναι αυτή την στιγμή στην Buffer pool

272696320 - PERF_COUNTER_COUNTER

Οι counters αυτοί επιστρέφουν το ΜΟ των διαδικασιών που υποδεικνύει ο κάθε ένας από αυτούς ανά δευτερόλεπτο και είναι decimal data type.

Συνήθως χρησιμοποιούνται για count monitoring πχ.

Στο object_name SQL Server 2017 XTP Transactions και ο counter Transactions created/sec δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 466 που σημαίνει έχω κατά μ.ο. 466 in-memory Transactions / sec

272696576 - PERF_COUNTER_BULK_COUNT

Οι counters αυτοί επιστρέφουν πληροφορίες που είναι cumulative από την στιγμή που ξεκίνησε το instance και είναι decimal data type.

Αυτό σημαίνει ότι δεν θέλει προσοχή στο διάβασμα τους όταν αυτό γίνεται με την εκτέλεση του dmv αυτού και για να γίνω ξεκάθαρος ας πάρουμε ένα παράδειγμα

Aς επιλέξουμε από το object name το SQLServer:Databases και τον counter Transactions/sec για μια συγκεκριμένη database (Τ για το παραδειγμα μου) που είναι στο instance name. Σε αυτό θα προσθέσουμε και το ms_ticks field από ένα ακόμα dmv το sys.dm_os_sys_info το οποίο δείχνει σε milliseconds το χρόνο που ο server είναι ξεκινημένος. Το query αυτό είναι όπως το παρακάτω.

select i.ms_ticks, c.* from sys.dm_os_performance_counters as c cross join sys.dm_os_sys_info as i where c.object_name='SQLServer:Databases' and c.counter_name='Transactions/sec' and c.instance_name='T'

Εκτελώντας το query αυτό θα μου δείξει μια τιμή Α.

Η τιμή αυτή είναι ο αριθμός των transactions/sec συνολικά από την στιγμή που ξεκίνησε το instance και όχι πόσα transactions έχω ανά δευτερόλεπτο.

Μπέρδεμα ε; Να το κάνω ακόμα χειρότερο ;

Όταν χρησιμοποιείς το performance monitor για να δεις το συγκεκριμένο counter δείχνει σωστά αυτό που λέει. Άρα εύκολα θα πει κάποιος ότι υπάρχει bug, αλλά δεν υπάρχει κανένα, απλά το performance monitor κάνει αυτό που θα περιγράψω παρακάτω.

'Εστω ότι την χρονική στιγμή Τ1 εκτελώ το παραπάνω query και έχω την τιμή Α για το cntr_value και την τιμή Α' για την τιμή ms_ticks

Tην χρονική στιγμή Τ2 εκτελώ το παραπάνω query και έχω την τιμή B για το cntr_value και την τιμή B' για την τιμή ms_ticks

Άρα η τιμή των Τransactions/sec για το διάστημα Τ1-Τ2 είναι ίση με (Α-Β)/((Α'-Β')/1000)

1073939712 - PERF_LARGE_RAW_BASE

Οι τιμές στους counter αυτούς είναι ακατέργαστα δεδομένα που χρησιμοποιούνται ως παρονομαστής ενός counter που απεικονίζει ένα στιγμιαίο αριθμητικό κλάσμα. Συνδυάζονται με τους PERF_LARGE_RAW_FRACTION που ακολουθούν.

537003264 - PERF_LARGE_RAW_FRACTION

Οι counters αυτοί είναι κλασματικές τιμές αναλογίας του αντίστοιχου PERF_LARGE_RAW_BASE.

Επειδή καταλαβαίνω την σύγχυση που έχει δημιουργηθεί ας το εξηγήσω με ένα παράδειγμα

Στο counter object SQLServer:Buffer Manager έχω τους counter Buffer cache hit ratio που είναι PERF_LARGE_RAW_FRACTION και Buffer cache hit ratio base που είναι PERF_LARGE_RAW_BASE

Για να βρω το Hit ratio % = (100 * Buffer cache hit ratio) / Buffer cache hit ratio base

1073874176 - PERF_AVERAGE_BULK

Οι counters αυτοί είναι cumulative και απεικονίζουν ένα M.O. Αυτό σημαίνει ότι για να πάρουμε την πραγματική τιμή του counter θα πρέπει να δούμε εκτός από την τιμή αυτή και την τιμή του αντίστοιχου PERF_LARGE_RAW_BASE counter και να κάνουμε τις πράξεις αφού πρώτα έχουμε τα δεδομένα δύο διαδοχικών τιμών πχ

Αν εκτελέσουμε το συγκεκριμένο query θα πάρουμε τα ζευγάρια που μας ενδιαφέρουν

select * from sys.dm_os_performance_counters where cntr_type in (1073939712,1073874176) order by 3,2

Για παράδειγμα το πρώτο ζευγάρι που αυτό το query επιστρέφει είναι το SQLServer:Latches-Average Latch Wait Time (ms) και SQLServer:Latches-Average Latch Wait Time base, PERF_AVERAGE_BULK & PERF_LARGE_RAW_BASE counter types αντίστοιχα.

Ας κρατήσουμε τις τιμές των δύο αυτών μετρητών σαν Α για τον πρώτο και Β για τον δεύτερο και ας εκτελέσουμε ξανά το ίδιο και να καταγράψουμε τις νέες τιμές σαν Α' και Β' αντίστοιχα.

Για να υπολογίσουμε το Average Latch Wait time (ms) μεταξύ των δύο αυτών διαδοχικών χρονικών στιγμών εφαρμόζουμε τον τύπο (Α'-Α) / (Β'-Β)

Conclusion

Δεν είναι δύσκολο να κάνεις όλα αυτά αγαπητέ DBA απλά θέλει λίγο προπόνηση και όρεξη


//antonch

Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.

Tip

What's New in SQL Server 2022 - Episodes

More Tips...

Become a member

If you want to receive updates from us become a member to our community.

Connect

Explore

Learn


sqlschool.gr © 2010-2024 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.