Résumé
Lorsque vous utilisez le pilote ODBC de SQL Server, le fournisseur OLE DB pour SQL Server ou le fournisseur managé System.Data.SqlClient, vous pouvez désactiver en utilisant les interfaces de programmation d’application respectives (API) de regroupement de connexion. Lorsque vous désactivez le regroupement, la contrainte sur la bibliothèque de réseau sous-jacente de SQL Server peut être augmentée si fréquemment, votre application ouvre et ferme les connexions. Cet article décrit certains paramètres TCP/IP que vous pouvez avoir à ajuster ces conditions.
Plus d'informations
Désactivation de la mise en pool, le pilote de réseau de SQL Server sous-jacent pour rapidement ouvrir et fermer les nouvelles connexions socket à l’ordinateur qui exécute SQL Server peut entraîner. Vous devrez peut-être modifier les paramètres de socket TCP/IP par défaut pour le système d’exploitation et de l’ordinateur qui exécute SQL Server pour traiter les plus hauts niveaux de contrainte.
Notez que cet article traite uniquement des paramètres qui affectent la bibliothèque réseau de SQL Server lorsque vous utilisez le protocole TCP/IP. Si vous désactivez le regroupement peut également provoquer les problèmes liés au stress avec d’autres protocoles de SQL Server, tels que les canaux nommés, mais cet article ne traite pas de cette rubrique. Cet article est destiné aux utilisateurs expérimentés uniquement. Si vous ne comprenez pas les rubriques de cet article, Microsoft recommande que vous consultez un ouvrage sur les sockets TCP/IP.
Notez que Microsoft recommande vivement de toujours utiliser le regroupement avec les pilotes de SQL Server. La mise en pool améliore considérablement les performances globales du côté client et côté SQL Server lorsque vous utilisez les pilotes de SQL Server. À l’aide de la mise en pool également considérablement permet de réduire le trafic réseau à l’ordinateur qui exécute SQL Server. Par exemple, un test de l’exemple utilisé 20 000 de SQL Server connexion s’ouvre et se ferme avec le pool activé utilisé environ 160 paquets de réseau TCP/IP, pour un total de 23,520 octets de l’activité réseau. Regroupement de désactivé, le même test généré 225,129 paquets de réseau TCP/IP, pour un total de 27,209,622 octets de l’activité réseau.
Notez que lorsque vous consultez ces problèmes liées au stress de socket TCP/IP avec les bibliothèques du réseau SQL Server, vous pouvez recevoir un ou plusieurs des messages d’erreur suivants lorsque vous essayez de vous connecter à un ordinateur qui exécute SQL Server :
SQL Server n’existe pas ou l’accès refusé
Délai d’attente expiré
Erreur de réseau générale
Fournisseur TCP : Une seule utilisation de chaque adresse de socket (protocole/adresse réseau/port) est en principe admise.
Notez que vous pouvez recevoir également ces messages d’erreur spécifiques lorsque d’autres problèmes se posent avec les SQL Server ; par exemple, vous pouvez recevoir ces messages d’erreur si l’ordinateur distant qui exécute SQL Server est arrêté, si l’ordinateur distant qui exécute SQL Server n’écoute pas sur les sockets TCP/IP, si la connectivité réseau à l’ordinateur qui exécute SQL Server est interrompue car le câble réseau est retiré, ou si vous rencontrez des problèmes de résolution DNS. En fait tout ce qui peut entraîner le client à échouer à l’ouverture d’un socket TCP/IP à l’ordinateur qui exécute SQL Server peut également provoquer les messages d’erreur. Toutefois, pour un problème de socket de liées au stress, le problème se produit par intermittence comme la contrainte augmente et qu’il se trouve. L’ordinateur peut s’exécuter sans erreurs pour les heures, puis l’erreur produit une ou deux fois et l’ordinateur, puis s’exécute pendant plusieurs heures sans erreurs. Également, lorsque vous rencontrez ce problème, connectivité général pour SQL Server fonctionne un instant, échoue la suivante, puis fonctionne à nouveau la prochaine instantanée. En d’autres termes, les problèmes liées au stress de socket se produisent généralement par intermittence, mais des problèmes de connectivité réseau réel avec SQL Server en général ne se produisent pas sporadique.
Deux principaux problèmes liées au stress se produisent généralement lorsque vous désactivez le regroupement lorsque vous utilisez le protocole TCP/IP de SQL Server : vous pouvez manquer de ports anonymes sur l’ordinateur client, ou vous risquez de dépasser la valeur de WinsockListenBacklog par défaut sur l’ordinateur qui exécute SQL Server.
Pour plus d’informations sur les ports anonymes, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
319502 PRB : Message d’erreur « WSAEADDRESSINUSE » lorsque vous essayez de vous connecter via un Port anonyme après avoir augmenté la limite de connexion IMAP
Réglez les paramètres MaxUserPort et TcpTimedWaitDelay
Notez que les paramètres MaxUserPort et TcpTimedWaitDelay sont uniquement applicables pour un ordinateur client qui est rapidement ouvrir et fermer des connexions à un ordinateur distant qui exécute SQL Server et qui n’utilise pas le regroupement de connexion. Par exemple, ces paramètres s’appliquent à un serveur Internet Information Services (IIS) qui prend en charge un grand nombre de requêtes HTTP entrantes et qui est d’ouvrir et de fermer des connexions à un ordinateur distant qui exécute SQL Server et qui utilise le protocole TCP/IP avec regroupement désactivé. Si le regroupement est activé, vous n’avez pas à ajuster les paramètres MaxUserPort et TcpTimedWaitDelay .
Lorsque vous utilisez le protocole TCP/IP pour ouvrir une connexion à un ordinateur qui exécute SQL Server, la bibliothèque réseau SQL Server sous-jacente ouvre un socket TCP/IP à l’ordinateur qui exécute SQL Server. Lors de l’ouverture de ce socket, la bibliothèque réseau de SQL Server n’active pas l’option de socket TCP/IP SO_REUSEADDR . Pour plus d’informations sur le paramètre de socket SO_REUSEADDR , consultez la rubrique « Setsockopt » dans Microsoft Developer Network (MSDN).
Notez que la bibliothèque réseau de SQL Server ne permet plus particulièrement pas l’option de socket SO_REUSEADDR TCP/IP pour des raisons de sécurité. Lorsque SO_REUSEADDR est activé, un utilisateur malveillant peut détourner un port client à SQL Server et utiliser les informations d’identification que le client fournit pour accéder à l’ordinateur qui exécute SQL Server. Par défaut, car la bibliothèque réseau de SQL Server ne permet pas l’option de socket SO_REUSEADDR , chaque fois que vous ouvrez et fermez un socket par l’intermédiaire de la bibliothèque réseau de SQL Server sur le côté client, le socket passe un état TIME_WAIT pendant quatre minutes. Si vous êtes rapidement d’ouverture et de fermeture des connexions de SQL Server via TCP/IP avec regroupement désactivé, vous êtes rapidement ouverture et fermeture des sockets TCP/IP. En d’autres termes, chaque connexion SQL Server possède un socket TCP/IP. Si vous ouvrez et fermez rapidement de 4000 sockets en moins de quatre minutes, vous allez atteindre le paramètre maximal par défaut pour les ports client anonyme et nouvelles tentatives de connexion socket échouent jusqu'à ce que l’ensemble existant de sockets TIME_WAIT arrive à expiration.
Côté client, il se peut que vous deviez augmenter les paramètres MaxUserPort et TcpTimedWaitDelay décrits dans Q319502 lorsque vous avez pooling désactivée. Les paramètres de ces valeurs sont déterminées par le nombre de connexion de SQL Server s’ouvre et se ferme se produire sur le client. Vous pouvez examiner le nombre de ports client est dans un état TIME_WAIT sur l’ordinateur client à l’aide de l’outil Netstat. Exécutez l’outil de commande Netstat avec l’indicateur -n , comme suit et le nombre de sockets de client à l’adresse IP de SQL Server qui sont dans un état TIME_WAIT. Dans cet exemple, l’adresse IP de l’ordinateur distant qui exécute SQL Server est 10.10.10.20, l’adresse IP de l’ordinateur client est 10.10.10.10 et trois connexions et deux connexions sont dans un état TIME_WAIT d’établir :
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
Si vous exécutez netstat - n , et vous voyez que l’adresse de l’ordinateur cible est en cours d’exécution de SQL Server sont dans un état TIME_WAIT proche de 4000 connexions vers l’adresse IP, vous pouvez augmenter la valeur de MaxUserPort par défaut et réduisez le paramètre TcpTimedWaitDelay afin que vous n’exécutez pas de ports de client anonyme. Par exemple, vous pouvez définir le paramètre MaxUserPort à 20000 et définir le paramètre TcpTimedWaitDelay à 30. Un paramètre TcpTimedWaitDelay plus faible signifie que les sockets attendent dans l’état TIME_WAIT pour moins de temps. Un paramètre MaxUserPort supérieur signifie que vous pouvez avoir plusieurs sockets dans l’état TIME_WAIT.
Notez que si vous ajustez le paramètre MaxUserPort ou TcpTimedWaitDelay , vous devez redémarrer Microsoft Windows pour le nouveau paramètre prenne effet. Les paramètres MaxUserPort et TcpTimedWaitDelay sont pour n’importe quel ordinateur client qui communique avec un ordinateur qui exécute SQL Server sur les sockets TCP/IP. Ces paramètres n’ont aucun effet si elles sont définies sur l’ordinateur qui exécute SQL Server, sauf si vous créez des connexions de socket TCP/IP locales sur l’ordinateur local qui exécute SQL Server.
Remarque Si vous ajustez le paramètre MaxUserPort , nous recommandons que vous réservez le port 1434 pour une utilisation par le service de navigateur de SQL Server (sqlbrowser.exe). Pour plus d’informations sur la procédure à suivre, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
Procédure de réservation d’une plage de ports éphémères sur un ordinateur qui exécute Windows Server 2003 ou Windows 2000 Server de 812873
Réglez le paramètre WinsockListenBacklog
Pour plus d’informations sur ce paramètre de Registre spécifiques à SQL Server, cliquez sur le numéro ci-dessous pour afficher l’article correspondant dans la Base de connaissances Microsoft :
154628 INF : SQL enregistre 17832 avec plusieurs demandes TCP\IP de connexion
Lorsque la bibliothèque réseau de SQL Server est à l’écoute sur les sockets TCP/IP, la bibliothèque réseau de SQL Server utilise l' écouter API Winsock. Le second paramètre pour l' écouter API est la file d’attente qui est autorisé pour le socket. Cette file d’attente représente la longueur maximale de la file d’attente de connexions pour le port d’écoute en attente. Lorsque la longueur de la file d’attente dépasse cette longueur maximale, la bibliothèque réseau SQL Server rejette immédiatement plusieurs tentatives de connexion de socket TCP/IP. En outre, la bibliothèque réseau de SQL Server envoie un paquet d’accusé de réception + RESET.
SQL Server 2000 utilise par défaut écoute les paramètre de file d’attente de 5. Cela signifie que l’ordinateur qui exécute SQL Server passe la valeur 5 au paramètre de file d’attente de l' écouter API Winsock lorsque l’API écouter configure les threads à l’écoute du protocole TCP/IP sur l’ordinateur qui exécute SQL Server. Vous pouvez régler la clé de Registre WinsockListenBacklog pour spécifier une autre valeur à passer pour ce paramètre. À partir de SQL Server 2005, la bibliothèque réseau passe une valeur de SOMAXCONN comme paramètre de la file d’attente pour l' écouter API. SOMAXCONN permet au fournisseur Winsock de valeur maximale raisonnable pour ce paramètre. Par conséquent, la clé de Registre WinsockListenBacklog n’est plus utilisée ni nécessaire dans SQL Server 2005.
La file d’attente définition fonctionne comme suit : supposons qu’un service arbitraire est à l’écoute pour les demandes entrantes du socket TCP/IP. Si vous définissez le paramètre de file d’attente à 5 et de demandes de connexion de socket sont en permanence en flux continu dans, le service n’est peut-être pas en mesure de répondre aux requêtes entrantes aussi rapides qu’ils sont fournis. À ce stade, la couche de socket TCP/IP file d’attente ces demandes entrantes dans la file d’attente de la file d’attente, et le service ultérieurement extraient les requêtes de cette file d’attente et traiter la demande de connexion de socket entrante. Une fois que la file d’attente est pleine, la couche de socket TCP/IP rejette immédiatement toutes les demandes de support supplémentaires venant en envoyant un paquet d’accusé de réception + réinitialisation au client. Augmentation de l’augmentation de taille de file d’attente de file d’attente que le nombre de connexions de socket en attente demande que la couche de socket TCP/IP en file d’attente avant que les demandes sont rejetées.
Notez que le paramètre WinsockListenBacklog est spécifique à SQL Server. SQL Server tente de lire ce paramètre du Registre lorsque le service SQL Server démarre en premier. Si le paramètre n’existe pas, la valeur 5 par défaut est utilisé. Si le paramètre de Registre existe, SQL Server lit le paramètre et utilise la valeur fournie comme le paramètre de file d’attente lors de l’écoute de l’API WinSock n’est appelé que les threads à l’écoute de socket TCP/IP sont définies à l’intérieur de SQL Server à distance.
Pour déterminer si vous exécutez ce problème, vous pouvez exécuter une trace du Moniteur réseau sur le client ou l’ordinateur qui exécute SQL Server et recherchez les demandes de connexion de socket sont immédiatement rejetés avec un accusé de réception + RESET. Si vous examinez les paquets TCP/IP dans le Moniteur réseau, que vous voyiez un paquet semblable à la suivante lorsque ce problème se produit :
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)
Notez que le port source est 0x599 ou 1433 au format décimal. Cela signifie que le paquet provient d’un ordinateur typique qui exécute SQL Server et qui s’exécute sur le port par défaut 1433. Notez également que le champ d’accusé de réception significatif et les indicateurs de réinitialisation de la connexion sont définies. Si vous êtes familiarisé avec le filtrage d’une trace du Moniteur réseau, vous pouvez filtrer la valeur des indicateurs TCP par 0 x 14 hexadécimale à voir uniquement les paquets d’accusé de réception + RESET dans la trace de moniteur réseau.
Notez que vous pouvez également voir des paquets ACK + réinitialisation similaires, si l’ordinateur qui exécute SQL Server ne fonctionne pas du tout ou si l’ordinateur qui exécute SQL Server n’écoute pas sur le protocole TCP/IP, afin de voir les paquets d’accusé de réception + RESET n’est pas confirmation définitive que vous rencontrez ce problème. Si l' WinsockListenBacklog est trop faible, certaines tentatives de réception de connexion accepte les paquets et certaines connexions s’affiche immédiatement les paquets d’accusé de réception + RESET dans la même période.
Notez que dans très rares cas, vous devrez modifier ce paramètre, même si le regroupement est activé sur les ordinateurs clients. Par exemple, si de nombreux ordinateurs clients communiquent avec un seul ordinateur qui exécute SQL Server, un grand nombre de tentatives de connexion entrantes simultanées peut-être se produire à un moment donné même si le regroupement est activé.
Remarque : Si vous ajustez le paramètre WinsockListenBacklog , vous n’avez pas à redémarrer Windows pour que ce paramètre prenne effet. Simplement, arrêtez et redémarrez le service SQL Server pour que le paramètre prenne effet. Le paramètre de Registre WinsockListenBacklog est uniquement pour l’ordinateur qui exécute SQL Server. Il n’a pas d’effet sur tout ordinateur client qui communique avec SQL Server.
