|
Connessioni utente SQLSERVER Le Connessioni General StatisticsUser dell'istanza SQL nel contatore performance corrispondono a essa Puoi anche consultare TCPv4Connections Established nel contatore delle prestazioni
Su una macchina con solo il servizio SQLSERVER,Connessioni TCPV4 stabilite & Collegamenti utente MssqlQuesti due parametri sono fondamentalmente sincronizzati e sono indicati come numero di connessioni nel seguente contenuto di test
Questo numero di connessioni è limitato, simile al numero massimo di limiti di concorrenza. Quando questo limite viene raggiunto, le query diventano non responsive anche se ci sono risorse libere di CPU, IO e MEM (alcune, non tutte le query sono interessate)
Il valore massimo di TCPV4 Connections Established & Mssql UserConnections dipende dai seguenti fattori
a. La complessità dell'istruzione di esecuzione è correlata: più complessa è l'affermazione, minore è il numero massimo di connessioni (questo effetto è molto importante)
b. È collegata alla concorrenza dei thread della richiesta,
10 processi, ciascuno apre 5.000 thread da richiedere,SELECT getdate()La dichiarazione è già abbandonata quando arriva a circa 4000 (da quello che ho capito è che, sebbene molti thread non abbiano richiesto risorse, il numero di richieste è elevato, il che ha un impatto).
10 processi, ciascuno apre 1000 thread per richiedere, SELECT getdate()Le dichiarazioni possono superare le 10.000.
c. È collegata alla frequenza delle richieste di thread
Se ogni thread esegue una query e si ferma per 0-10.000 millisecondi, occuperà meno connessioni rispetto a se non viene sospeso
d. Nel test, si è anche riscontrato che alcune connessioni non chiuse avrebbero causato il gonfio del contatore, cosa non discussa
10 processi, ciascuno apre 1000 thread di richiesta, pausa casualmente (da 0 a 10 secondi) dopo ogni query sul server. I risultati del test sono i seguenti:
Esecuzione:SELEZIONA * DA [sistema]. [dbo]. [DBA_alert](questa query restituisce 200 linee, il numero massimo di connessioni è 700 e il problema inizia a essere emesso)
Quando il numero di connessioni raggiunge 700, iniziano a essere segnalati alcuni errori e a 12:00 cominciano ad apparire molti errori, e il numero di connessioni intorno a 18:00 rimane bloccato e non aumenta più. Errori e connessioni lente sono abbondanti
Esecuzione:SELECT getdate()Tempo della pena(Il numero massimo di connessioni è 3500 e il problema inizia)
Quando il numero di connessioni raggiunge 3500, alcune iniziano a segnalare errori, e la pressione massima raggiunge circa 11000, e il numero di connessioni continua a crescere lentamente. Errori e interruzioni di connessione lente
La conclusione è: in date condizioni di pressione: la più semplice da eseguireIl numero massimo di connessioni può arrivare fino a 3500 quando SELECT getdate() ed esegui SELECT * FROM [sistema]. [dbo]. [DBA_alert], il numero massimo di connessioni può arrivare fino a 700. Il timeout della query si verifica quando CPU, IO e MEM hanno tutti un gran numero di risorse inattive.
Nell'ambiente di produzione, la pressione di 10*1000 thread non può essere raggiunta, ma SQL sarà più complesso dell'ambiente di test.
Numero concorrenteIl collo di bottiglia non è causato dalla larghezza di banda del mio computer o della scheda di rete del server
Per dimostrare quanto sopra. Ho fatto i seguenti test: exec dbo.run2 in caso di grande concorrenza;
ALTER proc [dbo]. [run2]
come
imposta nocount su
seleziona getdate()
dichiara @i int
Set @i=0
mentre @i<1000 Quando questo valore è 1000, il numero massimo di connessioni è circa 1300, e quando questo valore è 10, è normale raggiungere 5000.
inizio
INSERIRE IN [pub]. [dbo]. [tb_test] ([nome]) valori (newid())
set @i=@i+1
fine
Vai
Il numero di cicli di cambiamento non influenzerà il risultato di ritorno, cioè la pressione sul traffico della scheda di rete è la stessa, ma uno scadrà rapidamente e l'altro potrà sempre essere controllato, così l'impatto della larghezza di banda delle schede di rete su entrambi i lati può essere eliminato.
Contenuto di errore quando il numero massimo di connessioni è bloccato:
netstat-un risultato quando il numero massimo di connessioni è bloccato (fortemente consolidato):
Diagramma di esecuzione del programma di prova quando il numero massimo di connessioni è bloccato:
Vale la pena notare:La connessione con errori o timeout non è uniforme, e sarà concentrata in alcuni processi, cioè alcuni processi possono sempre funzionare normalmente e l'altra parte riporterà errori per molto tempo (non ha nulla a che fare con l'ordine di inizio dei processi, da quanto ho capito alcuni processi hanno risorse, possono continuare a funzionare normalmente, mentre altri processi nei thread delle risorse originali sono preemptati e non possono applicarsi a nuove risorse, continueranno a segnalare errori ripetutamente). Come mostrato nella figura sopra, il secondo e il settimo processo hanno iniziato ad avere un gran numero di timeout e altri processi hanno continuato a funzionare. Sul server, le query possono apparire come non influenzate o meno influenzate da alcune macchine, e alcune macchine sono significativamente colpite.
Conclusione: Sebbene il limite superiore delle Connessioni Utente SQLSERVER sia legato a una serie di condizioni, è comunque possibile stimare e prevedere il collo di bottiglia; quando questo limite superiore sarà raggiunto, ci saranno un gran numero di query lente e timeout (anche se CPU, IO. MEM, traffico può verificarsi anche quando ci sono risorse inattive). Infatti, modificare alcuni parametri TCP aumenterà questo limite superiore, e potrei scrivere supplementi in seguito
|
Pubblicato su 26/11/2014 15:11:08
|
|
|
|
