Αποκριση χρονου

Συζητήσεις για τον Microsoft SQL Server

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
SMILE@
Δημοσιεύσεις: 1
Εγγραφή: 01 Δεκ 2006 21:43

Αποκριση χρονου

Δημοσίευση από SMILE@ » 01 Δεκ 2006 21:52

HELLO!!!
ΜΗΠΩΣ ΓΝΩΡΙΖΕΙ ΚΑΠΟΙΣ ΑΝ Η ΕΝΤΟΛΗ SET STATISTICS TIME ON TOY MS SQL SERVER ΘΑ ΜΟΥ ΕΠΙΣΤΡΕΨΕΙ ΤΟ ΧΡΟΝΟ ΑΠΟΚΡΙΣΗΣ ΜΙΑΣ ΕΡΩΤΗΣΗΣ;
:wink:

Άβαταρ μέλους
GhostShip
Δημοσιεύσεις: 338
Εγγραφή: 30 Σεπ 2003 09:57
Τοποθεσία: Αθήνα

Αποκριση χρονου

Δημοσίευση από GhostShip » 11 Δεκ 2006 03:40

Θα σου επιστρέψει αρκετά πράγματα τα οποία θα πρέπει να γνωρίζεις, και θα προσπαθήσω να τα εξηγήσω.

Επίσης, θα πρέπει να γνωρίζεις οτι ο συγκεκριμένος τρόπος ΔΕΝ είναι απόλυτα αξιόπιστος.

Και αυτό γιατί ο SQL, έχει 2 cache μνήμες. Την Data και την Procedure. Κρατάει δηλαδή στην μνήμη του τόσο στοιχεία όσο και excecution plans για πιο γρήγορη απόκριση και για όσο το δυνατόν λιγότερη κατανάλωση CPU time.

Για να έχεις αξιόπιστα αποτελέσματα, θα πρέπει πρώτα να καθαρίζεις αυτές τις 2 μνήμες. Για αυτό το λόγο, καλό θα ήταν να μην χρησιμοποιήσεις τις εντολές που καθαρίζουν τις cache σε περιβάλλον παραγωγής, αλλά σε περιβάλλον δοκιμής.

Οι δύο εντολές που αναφέρω είναι :

1. DBCC DROPCLEANBUFFERS
2. DBCC FREEPROCCACHE

έχε υπόψη σου οτι ΠΑΝΤΑ, για να έχεις σωστό και αξιόπιστο αποτέλεσμα θα πρέπει να τρέχεις αυτές τις 2 εντολές στον Query Analyzer, πριν τεστάρεις τις εντολές που θες.

Και ας έρθουμε στο θέμα μας.

Χρησιμοποιώντας λοιπόν την εντολή SET STATISTICS TIME ON , όταν θα δίνεις μια εντολή πχ
SELECT * from Table , θα σου έρχεται και ένα report. Καλό θα είναι να δίνεις και την εντολή SET STATISTICS IO ON. Αυτό θα το δεις στην πορεία γιατί το λέω.

To report λοιπόν θα μοιάζει περίπου έτσι:

SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 15 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.

(2155 row(s) affected)

Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9.

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 33 ms.


Τί σημαίνουν όλα αυτά ? Έχουμε και λέμε:

H εντολή SET STATISTICS TIME είναι υπεύθυνη για τα εξής :

SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 15 ms.
SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.


και

SQL Server Execution Times:
CPU time = 0 ms, elapsed time = 33 ms.


To πρώτο "SQL Server parse and compile time", μας δίχνει πόση ώρα χρειάστηκε η CPU ( CPU time ) καθώς και την συνολική ώρα που χρειάστηκε ο SQL να κάνει compile την εντολή που του δώσαμε και για να βάλει το excecution plan του query στην procedure cache του server για μελλοντική χρήση.

Το δεύτερο "SQL Server parse and compile time", μας δείχνει πόση ώρα χρειάστηκε ο SQL για να πάρει το excecution plan του query από την procedure cache. Για αυτό το λόγο και επειδή το συγκεκριμένο task είναι πολύ γρήγορο, οι τιμές είναι 0.

Το "SQL Server Execution Times" είναι αυτό που θα πρέπει να σε ενδιαφέρει πιο πολύ. Και αυτό γιατί σου δίνει το πόση ώρα χρειάστηκε η CPU για να τρέξει το query, και πόση ώρα έτρεχε το query.

Tα νούμερα αυτά θα δεις οτι γενικά θα παίζουν ανάλογα και με το φορτίο που θα έχει ο server εκείνη την στιγμή, αλλά γενικά το CPU time, είναι μια πολύ αξιόπιστη μονάδα μέτρησης.

H εντολή SET STATISTICS ΙΟ είναι υπεύθυνη για τα εξής :

Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9.

Εδώ βλέπουμε μερικά ενδιαφέροντα στοιχεία.

Έχουμε φυσικά το όνομα του πίνακα στον οποίο έτρεξε το query.

Έχουμε το Scan Count.
Σημαίνει το πόσες φορές ο πίνακας ή οι πίνακες που αναφέρονται στο query, προσβάστηκαν κατά την εκτέλεση του query. Αυτό δεν λέει και πολλά όταν έχουμε ένα απλό query, αλλά όταν τρέχουμε joins, τότε αυτός ο αριθμός θα μας φανεί χρήσιμος, εφόσον θέλουμε να βελτιώσουμε τις εντολές.

Έχουμε το Logical Reads.
Αυτό είναι το πιο σημαντικό στοιχείο πληροφορίας. Πρέπει να πώ σε αυτό το σημείο οτι ο SQL, πρίν κάνει οτιδήποτε με τα δεδομένα, αυτά αποθηκεύονται στην data cache. Επίσης είναι πολυ σημαντικό να ξέρουμε οτι την μνήμη αυτή ο SQL την διαβάζει σε "σελίδες" μεγέθους 8Κ.

Αυτός ο αριθμός λοιπόν μας δείχνει πόσες σελίδες της μνήμης αυτής πρέπει να διαβάσει ο SQL για να παράγει τα αποτελέσματα του query. Αυτό το νούμερο είναι το πιο σημαντικό, γιατί πρέπει να ξέρεις οτι ο SQL ΑΠΟΚΛΕΙΕΤΑΙ να διαβάσει παραπάνω ή λιγότερες σελίδες για να παράγει τα ίδια αποτελέσματα για την ίδια εντολή. Έτσι λοιπόν όταν εκτελούμε σύνθετες εντολές και δούμε τον αριθμό αυτόν να πέφτει τότε κάνουμε καλή δουλειά με την βελτιστοποίηση των εντολών μας.

Έχουμε το Physical Reads.
Το Physical Read, είναι το πόσες φορές ο SQL πρέπει να χρησιμοποιήσει τον σκληρό δίσκο για να διαβάσει τις σελίδες που λέγαμε παραπάνω, για να τις βάλει στην data cache, ώστε να μπορεί να τις χρησιμοποιήσει. Ο μηχανισμός του SQL απαιτεί το να βρίσκονται τα data στην data cache ΑΠΑΡΑΙΤΗΤΩΣ. Οταν τρέχουμε λοιπόν ένα query, ο SQL, κοιτάει να δεί αν τα data είναι στην data cache. Aν είναι δεν υπάρχει πρόβλημα. Αν ΔΕΝ είναι τότε πρέπει να καταφύγει στον δίσκο και να πάρει τα δεδομένα αυτά.

Έτσι λοιπόν τα Physical Reads είναι πολύ πιο απαιτητικά σε κατανάλωση των πόρων του συστήματος. Το παράδοξο είναι οτι δεν μας ενδιαφέρουν. Και δεν μας ενδιαφέρουν, γιατί ΔΕΝ μπορούμε να έχουμε ΚΑΝΕΝΑΝ απολύτως έλεγχο για το αν τα δεδομένα βρίσκονται στην cache ή όχι.

Έχουμε και το Read-Ahead Reads.
Η τιμή αυτή μας δίχνει τον αριθμό των Physical Reads που πραγματοποίησε o SQL, λόγω του μηχανισμού read-ahead που διαθέτει. Αυτό που κάνει δηλαδή ο SQL, για να βελτιστοποιήσει την απόδσή του, διαβάζει εκ των προτέρων physical data pages, προτού αυτά του ζητηθούν, όταν νομίζει οτι πιθανον να τα χρειαστούν τα queries. Αυτά τα δεδομένα, μπορεί και μπορεί να μην χρησιμοποιηθούν, και εξαρτάται κατά πόσο ο SQL μάντεψε σωστά.

Υπενθυμίζω το αποτέλεσμα της γραμμής που αναλύω εδώ:

Table 'Order Details'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 9.

Στην συγκεκριμένη περίπτωση, ο SQL μάντεψε πολύ σωστά. Τα logical reads ήταν 10, τα physical reads 1 και τα read-ahead reads 9. Αυτά τα νούμερα προστίθενται και θα δείξω το πως.

Πρώτα από όλα, ο SQL, ξεκινά να ελέγχει αν οι data pages που χρειάζεται, βρίσκονται στην data cache. Ταυτόχρονα, ο SQL κατάλαβε, πρίν ολοκληρωθεί η διαδικασία ότι δεν βρίσκονται, και έτσι ξεκινά την διαδικασία του μηχανισμού read-ahead, η οποία διαβάζει τις πρώτες 9 σελίδες από τις 10 που χρειάστηκε από τον δίσκο και τις βάζει στην data cache. Όταν λοιπόν ο SQL ολοκλήρωσε την διαδικασία, είδε οτι οι 9 από τις 10 σελίδες που χρειάζεται είναι ήδη στην μνήμη ( λόγω του μηχανισμού του read-ahead) αλλά φυσικά μία λείπει. Και έτσι είδε οτι έπρεπε να καλέσει μόνο μία για να την βάλει και αυτή στην data cache. Mόλις και οι 10 σελίδες βρέθηκαν στην data cache, ο SQL ήταν ικανός να επεξεργαστεί το query.

Ετσι , από τις 10 συνολικά σελίδες που έπρεπε να διαβάσει ο SQL, είχε μαντέψει σωστά τις 9 και κατέφυγε στον δίσκο 1 φορά για να διαβάσει και την τελευταία σελίδα, πριν μπορέσει να επεξεργαστεί το query.

Τελικά είναι αρκετά έξυπνος ο SQL... :)

Ελπίζω να βοήθησα αρκετά με αυτό που θές να κάνεις.

Nantia
Δημοσιεύσεις: 12
Εγγραφή: 16 Ιαν 2008 13:39

Αποκριση χρονου

Δημοσίευση από Nantia » 31 Ιαν 2008 15:25

Κάθε φορά όμως οι χρόνοι που εμφανίζονται διαφέρουν.

Ποιον πρέπει να χρησιμοποιήσω ως χρόνο απόκρισης? Αυτόν μετά την πρώτη εκτέλεση μετά τις εντολές DBCC DROPCLEANBUFFERS και DBCC FREEPROCCACHE ?

Τα στοιχεία που εμφανίζονται στα Client Statistics δεν με εξυπηρετούν όταν θέλω να βρω το χρόνο απόκρισης?

Άβαταρ μέλους
GhostShip
Δημοσιεύσεις: 338
Εγγραφή: 30 Σεπ 2003 09:57
Τοποθεσία: Αθήνα

Αποκριση χρονου

Δημοσίευση από GhostShip » 31 Ιαν 2008 18:53

Οπως είπα και στο προηγούμενο post μου, αυτό που σε ενδιαφέρει, ειναι το "SQL Server Execution Times".

Το να διαφέρουν οι τιμες είναι λογικό γιατί το φορτίο του server είναι διαφορετικό κάθε φορα.

Τις 2 εντολές που αναφέρεις, τις χρησιμοποιείς για να "καθαρίσεις" τον sever και να σου δώσει όσο το δυνατόν τους πραγματικούς χρόνους.

Εχε υπόψη σου οτι οπως έχω ηδη πει, αυτο πο περιέγραψα ΔΕΝ ειναι και οτι πιο αξιόπιστο αλλά ενδεικτικό...

Τωρα τα client stats, παιζουν ρόλο, αλλα και παλι εξαρτώνται από πολλές παραμέτρους...το φόρτο του δικτύου, ειδικά ανο server ειναι απομακρυσμένος, σε τι γραμμή είναι ο server, σε τι γραμμή είναι το client....πολλά
Εικόνα

Nantia
Δημοσιεύσεις: 12
Εγγραφή: 16 Ιαν 2008 13:39

Αποκριση χρονου

Δημοσίευση από Nantia » 01 Φεβ 2008 12:28

Εγινε!! Ευχαριστώ!!!!

Απάντηση

Επιστροφή στο “MS SQL Server”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 0 επισκέπτες