Riepilogo
Quando si utilizza il driver ODBC di SQL Server, il provider OLE DB di SQL Server o il provider gestito System.Data.SqlClient, è possibile disattivare i pool di connessioni utilizzando i rispettivi application programming interface (API). Quando si disattiva il pool, la sollecitazione sulla libreria di rete di SQL Server sottostante può essere aumentata se l'applicazione apre e chiude le connessioni spesso. In questo articolo descrive alcune impostazioni TCP/IP che potrebbe essere necessario regolare in queste condizioni.
Ulteriori informazioni
Se si disattiva il pool può causare il driver di rete di SQL Server sottostante rapidamente aprire e chiudere le connessioni socket di nuovo al computer che esegue SQL Server. Potrebbe essere necessario modificare le impostazioni di socket TCP/IP predefinite per il sistema operativo e il computer che esegue SQL Server per gestire i livelli più elevati di stress.
Si noti che in questo articolo riguarda solo le impostazioni relative alla libreria di rete di SQL Server quando si utilizza il protocollo TCP/IP. Se si disattiva il pool possono causare problemi di stress con altri protocolli di SQL Server, ad esempio named pipe, ma in questo articolo vengono illustrate in questo argomento. Questo articolo è solo per utenti esperti. Se non si comprendono gli argomenti di questo articolo, Microsoft consiglia la consultazione di un manuale sui socket TCP/IP.
Si noti che Microsoft consiglia di utilizzare sempre il pool con i driver di SQL Server. Utilizza il pool notevolmente migliora le prestazioni complessive del lato client e lato SQL Server quando si utilizza il driver di SQL Server. Utilizza il pool anche notevolmente riduce il traffico di rete al computer che esegue SQL Server. Ad esempio, un test di esempio utilizzati 20.000 SQL Server apre e chiude con attivato il pool di connessione utilizzato circa 160 pacchetti di rete TCP/IP, per un totale di byte 23,520 di attività di rete. Con pool disattivato, lo stesso test di esempio generato 225,129 pacchetti di rete TCP/IP, per un totale di byte 27,209,622 di attività di rete.
Si noti che la presenza di questi problemi relativi alla sollecitazione di un socket TCP/IP con le librerie di rete di SQL Server venga visualizzato uno o più dei seguenti messaggi di errore quando si tenta di connettersi a un computer che esegue SQL Server:
SQL Server inesistente o accesso negato
Timeout scaduto
Errore di rete generico
Provider TCP: Un solo utilizzo di ogni indirizzo di socket (indirizzo di rete/protocollo/porta) norma è consentito.
Nota è inoltre possibile ricevere questi messaggi di errore quando si verificano altri problemi con SQL Server; Questi messaggi di errore, ad esempio, si verifichi se il computer remoto che esegue SQL Server viene arrestato, se il computer remoto che esegue SQL Server non è in ascolto su socket TCP/IP, se la connettività di rete al computer che esegue SQL Server è interrotta poiché il cavo di rete è estratta o se si verificano problemi di risoluzione DNS. Fondamentalmente tutto ciò che è possibile che il client a cui non è possibile aprire un socket TCP/IP al computer che esegue SQL Server può inoltre causare messaggi di errore. Tuttavia, con un problema di stress relativi socket, il problema si verifica in modo discontinuo come la sollecitazione raggiunge e rientra. Il computer può eseguire per ore senza errori, quindi l'errore si verifica una o due volte e il computer, quindi viene eseguito per molte altre ore senza errori. Inoltre, quando si dispone di questo problema, connettività generale di SQL Server funziona un istante, ha esito negativo alla successiva, quindi funziona nuovamente nell'istante successivo. In altre parole, i problemi relativi a stress socket in genere si verificano occasionalmente, ma i reali problemi di connettività di rete con SQL Server in genere non si verificano occasionalmente.
Due problemi principali relativi a stress si verificano in genere quando si disattiva il pool mentre si utilizza il protocollo TCP/IP di SQL Server: È possibile eseguire anonimo porte sul computer client o si potrebbe superare l'impostazione WinsockListenBacklog predefinita sul computer che esegue SQL Server.
Per ulteriori informazioni sulle porte anonime, fare clic sul numero dell'articolo per visualizzare l'articolo della Microsoft Knowledge Base:
319502 PRB: messaggio di errore 'WSAEADDRESSINUSE' quando si tenta di connettersi tramite una porta anonima dopo aver aumentato il limite di connessione IMAP
Regolare le impostazioni di MaxUserPort e TcpTimedWaitDelay
Si noti che le impostazioni di MaxUserPort e TcpTimedWaitDelay sono applicabili solo a un computer client che apre e chiude rapidamente delle connessioni a un computer remoto che esegue SQL Server e che non utilizza il pool di connessioni. Ad esempio, queste impostazioni sono applicabili in un server Internet Information Services (IIS) che è un numero elevato di richieste HTTP in ingresso e manutenzione che è l'apertura e chiusura delle connessioni a un computer remoto che esegue SQL Server e che utilizza il protocollo TCP/IP con pool disattivato. Se il pool è attivato, non è necessario modificare le impostazioni di MaxUserPort e TcpTimedWaitDelay .
Quando si utilizza il protocollo TCP/IP per aprire una connessione a un computer che esegue SQL Server, la libreria di rete di SQL Server sottostante viene aperto un socket TCP/IP al computer che esegue SQL Server. Quando si apre questo socket, la libreria di rete di SQL Server non è attiva l'opzione di socket TCP/IP SO_REUSEADDR . Per ulteriori informazioni sull'impostazione SO_REUSEADDR socket, vedere l'argomento "Setsockopt" in Microsoft Developer Network (MSDN).
Si noti che la libreria di rete di SQL Server in modo specifico non attiva l'opzione di socket TCP/IP SO_REUSEADDR per motivi di sicurezza. Quando SO_REUSEADDR è attivata, un utente malintenzionato può assumere una porta del client di SQL Server e utilizzare le credenziali che il client fornisce per accedere al computer che esegue SQL Server. Per impostazione predefinita, in quanto la libreria di rete di SQL Server non attiva l'opzione di socket SO_REUSEADDR , ogni volta che si apre e chiude un socket tramite la libreria di rete di SQL Server sul lato client, il socket passa allo stato TIME_WAIT per quattro minuti. Se si è rapidamente apertura e chiusura connessioni SQL Server tramite TCP/IP con pool disattivato, si sono rapidamente apertura e chiusura socket TCP/IP. In altre parole, ogni connessione di SQL Server dispone di un socket TCP/IP. Se si aprono e si chiudono 4000 socket in meno di quattro minuti, si raggiungerà il massimo predefinito per le porte client anonimi e nuovi tentativi di connessione socket esito negativo fino a quando l'insieme esistente di socket TIME_WAIT timeout.
Sul lato client, è necessario aumentare le impostazioni di MaxUserPort e TcpTimedWaitDelay descritti in Q319502 in presenza di pool disattivato. Le impostazioni relative a tali valori sono determinate da quanti connessione SQL Server aprire e chiudere si verificano sul lato client. È possibile esaminare quante porte client sono nello stato TIME_WAIT utilizzando lo strumento Netstat sul computer client. Eseguire lo strumento Netstat con il flag -n , come indicato di seguito e contare il numero di socket client all'indirizzo IP di SQL Server che sono nello stato TIME_WAIT. In questo esempio, l'indirizzo IP del computer remoto che esegue SQL Server è 10.10.10.20, l'indirizzo IP del computer client è 10.10.10.10 e tre stabilite connessioni e due connessioni sono nello stato TIME_WAIT:
C:\>netstat -n
Active Connections
Proto Local Address Foreign Address State
TCP 10.10.10.10:2000 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2001 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2002 10.10.10.20:1433 ESTABLISHED
TCP 10.10.10.10:2003 10.10.10.20:1433 TIME_WAIT
TCP 10.10.10.10:2004 10.10.10.20:1433 TIME_WAIT
Se si esegue netstat - n e si vede il numero di connessioni vicino a 4000 e l'indirizzo IP del computer di destinazione che esegue SQL Server sono nello stato TIME_WAIT, è possibile aumentare l'impostazione di MaxUserPort predefinito e ridurre l'impostazione TcpTimedWaitDelay in modo da non esaurire le porte client anonimi. Ad esempio, è possibile impostare l'impostazione di MaxUserPort 20000 e impostare TcpTimedWaitDelay a 30. Un'impostazione TcpTimedWaitDelay inferiore significa che il socket attende nello stato TIME_WAIT per meno tempo. Un'impostazione di MaxUserPort superiore significa che è possibile disporre ulteriori socket nello stato TIME_WAIT.
Si noti che se si modifica l'impostazione di MaxUserPort o TcpTimedWaitDelay , è necessario riavviare Microsoft Windows per far si che la nuova impostazione abbia effetto. Le impostazioni di MaxUserPort e TcpTimedWaitDelay sono per i computer client che comunica con un computer che esegue SQL Server tramite socket TCP/IP. Queste impostazioni non hanno alcun effetto se vengono impostate sul computer che esegue SQL Server a meno che non si effettuino connessioni di socket TCP/IP locale sul computer locale che esegue SQL Server.
Nota: Se si modifica l'impostazione di MaxUserPort , si consiglia di in cui si prenota la porta 1434 per l'utilizzo dal servizio SQL Server Browser (sqlbrowser.exe). Per ulteriori informazioni su come effettuare questa operazione, fare clic sul numero riportato di seguito per visualizzare l'articolo della Microsoft Knowledge Base:
812873 come riservare un intervallo di porte effimere in un computer che esegue Windows Server 2003 o Windows 2000 Server
Regolare l'impostazione WinsockListenBacklog
Per ulteriori informazioni su questa impostazione del Registro di sistema specifiche di SQL Server, fare clic sul numero dell'articolo per visualizzare l'articolo della Microsoft Knowledge Base riportato di seguito:
154628 INF: SQL registra 17832 con più richieste di connessione TCP\IP
Quando la libreria di rete di SQL Server in ascolto su socket TCP/IP, la libreria di rete di SQL Server utilizza l' ascolto API Winsock. Il secondo parametro per l' ascolto API è il backlog consentito per il socket. Il backlog rappresenta la lunghezza massima della coda di connessioni per il listener in sospeso. Quando la lunghezza della coda supera la lunghezza massima, la libreria di rete di SQL Server Rifiuta immediatamente ulteriori tentativi di connessione socket TCP/IP. Inoltre, la libreria di rete di SQL Server invia un pacchetto ACK + RESET.
SQL Server 2000 utilizza un' predefinita ascolto impostazione backlog di 5. Ciò significa che il computer che esegue SQL Server passa il valore 5 al parametro backlog ascolto API Winsock quando l'API di ascolto imposta i thread in attesa del protocollo TCP/IP sul computer che esegue SQL Server. È possibile modificare la chiave di registro WinsockListenBacklog per specificare un valore diverso da passare per questo parametro. A partire da SQL Server 2005, la libreria di rete passa un valore di SOMAXCONN come l'impostazione di backlog di ascolto API. SOMAXCONN consente al provider di Winsock impostare un valore massimo accettabile per questa impostazione. Pertanto, la chiave del Registro di sistema di WinsockListenBacklog non è più utilizzata o necessarie in SQL Server 2005.
Il backlog l'impostazione funziona come segue: si supponga che un servizio non autorizzato è in ascolto delle richieste di socket TCP/IP in ingresso. Se l'impostazione di backlog è impostato su 5 e vengono continuamente flussi molte richieste di connessione socket, il servizio non sia grado di rispondere alle richieste in arrivo alla massima veloce che arrivano. A questo punto, il livello di socket TCP/IP Accoda le richieste in arrivo nella coda di backlog e il servizio possa successivamente recuperano la richiesta da questa coda e gestire la richiesta di connessione socket in arrivo. Dopo la coda si riempie, il livello di socket TCP/IP Rifiuta immediatamente le richieste di ulteriori socket disponibili inviando un pacchetto ACK + RESET al client. Aumentare gli aumenti di dimensione coda di backlog che il numero di connessioni socket in sospeso richieste che il livello di socket TCP/IP code prima che le richieste vengono rifiutate.
Si noti che l'impostazione WinsockListenBacklog è specifico di SQL Server. SQL Server tenta di leggere questa impostazione del Registro di sistema al primo avvio del servizio SQL Server. Se l'impostazione non esiste, viene utilizzato il valore predefinito è 5. Se non esiste, l'impostazione del Registro di sistema di SQL Server legge l'impostazione e utilizza il valore fornito come l'impostazione di backlog quando l'API WinSock di ascolto viene chiamata come i thread in attesa di socket TCP/IP sono impostati fino all'interno di SQL Server.
Per determinare se si esegue questo problema, è possibile eseguire una traccia di Network Monitor nel computer che esegue SQL Server o il client e cercare le richieste di connessione socket immediatamente rifiutati con un ACK + RESET. Se si esaminano i pacchetti TCP/IP Network Monitor, quando si verifica questo problema presente un pacchetto simile al seguente:
Frame: Base frame propertiesETHERNET: EType = Internet IP (IPv4)
IP: Protocol = TCP - Transmission Control; Packet ID = 40530; Total IP Length = 40; Options = No Options
TCP: Control Bits: .A.R.., len: 0, seq: 0-0, ack:3409265780, win: 0, src: 1433 dst: 4364
TCP: Source Port = 0x0599
TCP: Destination Port = 0x110C
TCP: Sequence Number = 0 (0x0)
TCP: Acknowledgement Number = 3409265780 (0xCB354474)
TCP: Data Offset = 20 bytes
TCP: Flags = 0x14 : .A.R..
TCP: ..0..... = No urgent data
TCP: ...1.... = Acknowledgement field significant
TCP: ....0... = No Push function
TCP: .....1.. = Reset the connection
TCP: ......0. = No Synchronize
TCP: .......0 = Not the end of the data
TCP: Window = 0 (0x0)
TCP: Checksum = 0xF1E7
TCP: Urgent Pointer = 0 (0x0)
Si noti che la porta di origine 0x599 o 1433 in formato decimale. Ciò significa che il pacchetto proviene da un tipico computer che esegue SQL Server e che è in esecuzione sulla porta predefinita 1433. Si noti inoltre che siano impostati nel campo Conferma significativo e i flag di ripristinare la connessione . Se si ha familiarità con il filtro di una traccia di Network Monitor, è possibile filtrare il valore di flag TCP 0x14 esadecimale per visualizzare solo i pacchetti ACK + RESET nella traccia di Network Monitor.
Nota è inoltre possibile visualizzare i pacchetti ACK + RESET simili se il computer che esegue SQL Server non è affatto o se il computer che esegue SQL Server non è in ascolto per il protocollo TCP/IP, pertanto la visualizzazione di pacchetti ACK + RESET non è definita conferma che si è verificato questo problema. Se il WinsockListenBacklog è troppo bassa, alcune connessione tentativi di ricevano pacchetti di accettazione e alcune connessioni immediatamente la ricezione di pacchetti ACK + RESET stesso intervallo di tempo.
Si noti che in casi molto rari, potrebbe essere necessario modificare questa impostazione, anche se è attivato il pool dei computer client. Ad esempio, se molti computer client sta parlando di un singolo computer che esegue SQL Server, un numero elevato di tentativi di connessione in ingresso simultanee può verificarsi in qualsiasi momento anche se è attivato il pool.
Nota: Se si modifica l'impostazione WinsockListenBacklog , non è necessario riavviare Windows per questa impostazione abbia effetto. È sufficiente arrestare e riavviare il servizio SQL Server per l'impostazione abbia effetto. L'impostazione del Registro di sistema di WinsockListenBacklog è solo per il computer che esegue SQL Server. Non ha alcun effetto su qualsiasi computer client che comunica con SQL Server.
