|
Συνδέσεις χρηστών SQLSERVER Τα Γενικά στατιστικά στοιχεία Συνδέσεις χρήστη της παρουσίας SQL στον μετρητή επιδόσεων αντιστοιχούν σε αυτό Μπορείτε επίσης να ανατρέξετε στο TCPv4Connections Established στον μετρητή επιδόσεων
Σε έναν υπολογιστή με μόνο την υπηρεσία SQLSERVER,Δημιουργήθηκαν συνδέσεις TCPV4 && Συνδέσεις χρηστών MssqlΑυτές οι δύο παράμετροι είναι βασικά συγχρονισμένες και αναφέρονται ως ο αριθμός των συνδέσεων στο ακόλουθο περιεχόμενο δοκιμής
Αυτός ο αριθμός συνδέσεων είναι περιορισμένος, παρόμοιος με τον μέγιστο αριθμό ορίων ταυτοχρονισμού. Όταν συμπληρωθεί αυτό το όριο, τα ερωτήματα δεν θα ανταποκρίνονται ακόμα και αν υπάρχουν ελεύθεροι πόροι CPU, IO και MEM (ορισμένα, δεν επηρεάζονται όλα τα ερωτήματα)
Η μέγιστη τιμή των TCPV4 Connections Established &&& Mssql UserConnections εξαρτάται από τους ακόλουθους παράγοντες
α. Η πολυπλοκότητα της δήλωσης εκτέλεσης σχετίζεται, όσο πιο περίπλοκη είναι η δήλωση, τόσο μικρότερος είναι ο μέγιστος αριθμός συνδέσεων (αυτό το αποτέλεσμα είναι πολύ σημαντικό)
β. Σχετίζεται με τον συγχρονισμό νήματος του αιτήματος,
10 διεργασίες, κάθε διεργασία ανοίγει 5.000 νήματα για να ζητήσει,ΕΠΙΛΟΓΗ getdate()Η δήλωση έχει ήδη εγκαταλειφθεί όταν φτάσει περίπου τα 4000 (καταλαβαίνω ότι αν και πολλά νήματα δεν έχουν ζητήσει πόρους, ο αριθμός των αιτημάτων είναι μεγάλος, κάτι που έχει επίσης αντίκτυπο).
10 διεργασίες, κάθε διαδικασία ανοίγει 1000 νήματα για να ζητήσει, ΕΠΙΛΟΓΗ getdate()Οι δηλώσεις μπορούν να φτάσουν σε περισσότερες από 10.000.
γ. Σχετίζεται με τη συχνότητα των αιτημάτων νημάτων
Εάν κάθε νήμα εκτελεί ένα ερώτημα και κάνει παύση για 0-10.000 χιλιοστά του δευτερολέπτου, θα καταλαμβάνει λιγότερες συνδέσεις από ό,τι αν δεν έχει ανασταλεί
δ. Στη δοκιμή, διαπιστώθηκε επίσης ότι ορισμένες μη κλειστές συνδέσεις θα προκαλούσαν φούσκωμα του μετρητή, κάτι που δεν συζητήθηκε
10 διεργασίες, κάθε διαδικασία ανοίγει 1000 νήματα αιτημάτων, διακόπτεται τυχαία (0 έως 10 δευτερόλεπτα) μετά από κάθε ερώτημα στον διακομιστή Τα αποτελέσματα των δοκιμών είναι τα εξής:
Εκτέλεση:ΕΠΙΛΕΞΤΕ * ΑΠΟ [σύστημα]. [dbo]. [DBA_alert](αυτό το ερώτημα επιστρέφει 200 γραμμές και ο μέγιστος αριθμός συνδέσεων είναι 700 και το πρόβλημα αρχίζει να εκδίδεται)
Όταν ο αριθμός των συνδέσεων φτάσει τις 700, αρχίζουν να αναφέρονται ορισμένα σφάλματα και στις 1200, αρχίζει να εμφανίζεται ένας μεγάλος αριθμός σφαλμάτων και ο αριθμός των συνδέσεων γύρω στις 1800 έχει κολλήσει και δεν αυξάνεται πλέον. Τα σφάλματα και οι υποτονικές συνδέσεις είναι άφθονα
Εκτέλεση:ΕΠΙΛΟΓΗ getdate()Χρόνος πρότασης(Ο μέγιστος αριθμός συνδέσεων είναι 3500 και το πρόβλημα ξεκινά)
Όταν ο αριθμός των συνδέσεων φτάσει τις 3500, ορισμένες από αυτές αρχίζουν να αναφέρουν σφάλματα και η υψηλότερη πίεση φτάνει περίπου τις 11000 και ο αριθμός των συνδέσεων εξακολουθεί να αυξάνεται αργά. Σφάλματα και αργές εκρήξεις σύνδεσης
Το συμπέρασμα είναι: υπό δεδομένες συνθήκες πίεσης: το πιο απλό στην εκτέλεσηΟ μέγιστος αριθμός συνδέσεων μπορεί να είναι έως και 3500 όταν επιλέγετε getdate() και εκτελείτε SELECT * FROM [σύστημα]. [dbo]. [DBA_alert], ο μέγιστος αριθμός συνδέσεων μπορεί να είναι μόνο έως 700. Το χρονικό όριο ερωτήματος προκύπτει όταν η CPU, η IO και η MEM έχουν μεγάλο αριθμό αδρανών πόρων.
Στο περιβάλλον παραγωγής, η πίεση των 10*1000 νημάτων δεν μπορεί να επιτευχθεί, αλλά η SQL θα είναι πιο περίπλοκη από το περιβάλλον δοκιμής.
Παράλληλος αριθμόςΤο σημείο συμφόρησης δεν προκαλείται από το εύρος ζώνης της κάρτας δικτύου του υπολογιστή ή του διακομιστή μου
Για να αποδείξουμε τα παραπάνω. Έκανα τις ακόλουθες δοκιμές, exec dbo.run2 στην περίπτωση μεγάλου συγχρονισμού.
ALTER proc [dbo]. [τρέξιμο2]
Όπως
Ορίστε το nocount στο
επιλέξτε getdate()
δηλώστε @i int
Ορισμός @i=0
ενώ @i<1000 Όταν αυτή η τιμή είναι 1000, ο μέγιστος αριθμός συνδέσεων είναι περίπου 1300 και όταν αυτή η τιμή είναι 10, είναι φυσιολογικό να φτάσει τις 5000.
αρχίζω
ΕΙΣΑΓΩΓΗ ΣΕ [παμπ]. [dbo]. [tb_test] Τιμές ([όνομα]) (newid())
ορισμός @i=@i+1
Τέλος
Μετάβαση
Ο αριθμός των κύκλων αλλαγής δεν θα επηρεάσει το αποτέλεσμα επιστροφής, δηλαδή, η πίεση στην κίνηση της κάρτας δικτύου είναι η ίδια, αλλά ο ένας θα λήξει γρήγορα και ο άλλος μπορεί πάντα να ελεγχθεί, επομένως ο αντίκτυπος του εύρους ζώνης των καρτών δικτύου και στις δύο πλευρές μπορεί να εξαλειφθεί.
Περιεχόμενο σφάλματος όταν καθυστερεί ο μέγιστος αριθμός συνδέσεων:
netstat-ένα αποτέλεσμα όταν ο μέγιστος αριθμός συνδέσεων έχει κολλήσει (έχει καθοριστεί σε μεγάλο βαθμό):
Διάγραμμα εκτέλεσης προγράμματος δοκιμής όταν ο μέγιστος αριθμός συνδέσεων έχει σταματήσει:
Αξίζει να σημειωθεί:Η σύνδεση με σφάλματα ή χρονικά όρια δεν είναι ομοιόμορφη και θα συγκεντρωθεί σε ορισμένες διεργασίες, δηλαδή, ορισμένες διεργασίες μπορούν πάντα να εκτελούνται κανονικά και το άλλο μέρος θα αναφέρει σφάλματα για μεγάλο χρονικό διάστημα (δεν έχει καμία σχέση με τη σειρά έναρξης των διεργασιών, η κατανόησή μου είναι ότι ορισμένες διεργασίες έχουν πόρους, μπορούν να συνεχίσουν να λειτουργούν κανονικά, ενώ άλλες διεργασίες στα νήματα στους αρχικούς πόρους προλαμβάνονται και δεν μπορούν να υποβάλουν αίτηση για νέους πόρους, θα συνεχίσουν να αναφέρουν επανειλημμένα σφάλματα) Όπως φαίνεται στο παραπάνω σχήμα, η 2η και η 7η διαδικασία άρχισαν να έχουν μεγάλο αριθμό χρονικών ορίων και άλλες διαδικασίες συνέχισαν να λειτουργούν. Στο διακομιστή, τα ερωτήματα μπορεί να εμφανίζονται ως ανεπηρέαστα ή λιγότερο επηρεασμένα από ορισμένα μηχανήματα και ορισμένα μηχανήματα επηρεάζονται σημαντικά.
Συμπέρασμα: Παρόλο που το ανώτατο όριο των συνδέσεων χρήστη SQLSERVER σχετίζεται με μια σειρά συνθηκών, εξακολουθεί να είναι δυνατή η εκτίμηση και η πρόβλεψη του σημείου συμφόρησης, όταν επιτευχθεί αυτό το ανώτατο όριο, θα υπάρχει μεγάλος αριθμός ερωτημάτων αργά και χρονικά όρια (αν και CPU, IO. MEM, η κυκλοφορία μπορεί επίσης να προκύψει όταν υπάρχουν αδρανείς πόροι). Στην πραγματικότητα, η αλλαγή ορισμένων παραμέτρων TCP θα αυξήσει αυτό το ανώτατο όριο και μπορεί να γράψω συμπληρώματα αργότερα
|
Δημοσιεύτηκε στις 26/11/2014 3:11:08 μ.μ.
|
|
|
|
