Sammendrag
Når du bruker SQL Server ODBC-driveren, SQL Server OLE DB-leverandøren eller den forvaltede leverandøren System.Data.SqlClient, kan du deaktivere tilkoblingspooling ved hjelp av de respektive programmeringsgrensesnittene (APIer). Når du deaktiverer pooling, kan stress på underliggende SQL Server-nettverksbiblioteket økes Hvis programmet ofte åpner og lukker tilkoblinger. Denne artikkelen beskriver bestemte TCP/IP-innstillinger som du må kanskje justere under disse forholdene.
Hvis du vil ha mer informasjon
Å slå av gruppering kan føre til at den underliggende driveren for SQL Server-nettverk raskt åpne og lukke nye socket-tilkoblinger til datamaskinen som kjører SQL Server. Du må kanskje endre TCP/IP-socket standardinnstillinger for operativsystemet og datamaskinen som kjører SQL Server å forholde seg til de høyere nivåene av stress.
Legg merke til at denne artikkelen omhandler innstillinger som påvirker SQL Server network biblioteket når du bruker TCP/IP-protokollen bare. Slå av gruppering kan også forårsake stress-relaterte problemer med andre SQL Server-protokoller som for eksempel navngitte datakanaler, men denne artikkelen forklarer ikke dette emnet. Denne artikkelen er bare for avanserte brukere. Hvis du ikke forstår emnene i denne artikkelen, anbefaler Microsoft at du ser en god bok om TCP/IP sockets.
Vær oppmerksom på at Microsoft anbefaler på det sterkeste at du alltid bruker samvirke med SQL Server-drivere. Ved hjelp av pooling betydelig forbedrer generell ytelse, både på klientsiden og SQL Server-side når du bruker SQL Server-drivere. Ved hjelp av pooling også betydelig reduserer nettverkstrafikken på datamaskinen som kjører SQL Server. For eksempel brukes en test for eksempel brukt 20 000 SQL Server-tilkobling åpnes og lukkes med pooling aktivert omtrent 160 TCP/IP-nettverkspakker for totalt 23,520 byte nettverksaktivitet. Med pooling deaktivert, genereres den samme testen for eksempel 225,129 TCP/IP-nettverkspakker, for totalt 27,209,622 byte nettverksaktivitet.
Legg merke til at når du ser disse stress-relaterte TCP/IP socket problemer med biblioteker for SQL Server-nettverk, kan du få én eller flere av følgende feilmeldinger når du prøver å koble til en datamaskin som kjører SQL Server:
SQLServer eksisterer ikke eller tilgang
Ventetiden er utløpt
Generell feil på nettverk
TCP-leverandør: Bare ett bruk av hver enkelt kontaktadresse (protokoll/nettverksadresse/port) er vanligvis tillatt.
Vær oppmerksom på at du også kan få disse bestemte feilmeldingene når det oppstår andre problemer med SQL Server. Du kan for eksempel få disse feilmeldingene hvis den eksterne datamaskinen som kjører SQL Server, avsluttes, hvis den eksterne datamaskinen som kjører SQL Server ikke lytter til TCP/IP-socketer i det hele tatt, hvis nettverkstilkoblingen på datamaskinen som kjører SQL Server er brutt fordi nettverkskabelen er trukket ut, eller hvis du har problemer med DNS-oppløsningen. I utgangspunktet noe som kan føre til at klienten ikke kan åpne en TCP/IP-socket på datamaskinen som kjører SQL Server kan også føre til at feilmeldinger. Imidlertid med en stress-relaterte socket-problemet oppstår problemet midlertidig belastningen som stiger og faller. Datamaskinen kan kjøre i timer uten feil og deretter feilen oppstår én eller to ganger, og datamaskinen og har kjørt i flere timer uten feil. Også, når du har dette problemet, generelle tilkobling til SQL Server fungerer én øyeblikkelige, mislykkes neste, og fungerer på nytt neste instant. Med andre ord, stress-relaterte socket problemene vanligvis oppstår av og til, men reelle problemer med nettverkstilkobling med SQL Server vanligvis skjer ikke av og til.
To primære stress-relaterte problemer oppstår vanligvis når du deaktiverer pooling mens du bruker SQL Server TCP/IP-protokoll: du kan gå tom for anonym porter på klienten, eller du kan overskride standardinnstillingen for WinsockListenBacklog på datamaskinen som kjører SQL Server.
Hvis du vil ha mer informasjon om anonym porter, kan du klikke følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:
319502 PRB: "WSAEADDRESSINUSE"-feilmelding når du prøver å koble til via en anonym Port når du øke grensen for IMAP-tilkoblinger
Juster innstillingene for MaxUserPort og TcpTimedWaitDelay
Legg merke til at innstillingen for MaxUserPort og TcpTimedWaitDelay gjelder bare for en klientdatamaskin som er raskt åpne og lukke tilkoblinger til en ekstern datamaskin som kjører SQL Server, og som bruker ikke tilkoblingsutvalg. Disse innstillingene gjelder for eksempel på en server i Internet Information Services (IIS) som behandler et stort antall innkommende HTTP-forespørsler, og som er åpne og lukke tilkoblinger til en ekstern datamaskin som kjører SQL Server, og som bruker TCP/IP-protokollen med pooling deaktivert. Hvis pooling er aktivert, har du ikke justere innstillingen for MaxUserPort og TcpTimedWaitDelay .
Når du bruker TCP/IP-protokollen til å åpne en tilkobling til en datamaskin som kjører SQL Server, åpnes den underliggende SQL Server-nettverksbiblioteket en TCP/IP-socket på datamaskinen som kjører SQL Server. Når du åpner denne socketen, aktiveres ikke i SQL Server network biblioteket SO_REUSEADDR TCP/IP socket-alternativet. Hvis du vil ha mer informasjon om hvordan du kontakter i SO_REUSEADDR , kan du se emnet "Setsockopt" i Microsoft Developer Network (MSDN).
Vær oppmerksom på at SQL Server-nettverksbiblioteket spesielt ikke aktiverer SO_REUSEADDR TCP/IP-socket-alternativet av sikkerhetsgrunner. Når SO_REUSEADDR er aktivert, kan en ondsinnet bruker hijack en Klientport til SQL Server og bruke legitimasjonen klienten strømforsyninger for å få tilgang til datamaskinen som kjører SQL Server. Som standard, fordi SQL Server-nettverksbiblioteket ikke aktiveres socket-alternativet SO_REUSEADDR hver gang du åpner og lukker en socket gjennom SQL Server network biblioteket på klientsiden, socket går inn i TIME_WAIT-tilstanden for fire minutter. Hvis du er raskt åpning og lukking av SQL Server-tilkoblinger via TCP/IP med pooling deaktivert, er du raskt åpner og lukker TCP/IP sockets. Med andre ord er hver SQL Server-tilkobling en TCP/IP-socket. Hvis du raskt åpner og lukker 4000 sockets på mindre enn fire minutter, du vil nå standard maksimumsinnstilling for klienten anonym porter og forsøk på ny socket-tilkobling mislykkes inntil blir det eksisterende settet med TIME_WAIT sockets tidsavbrutt.
På klientsiden må du kanskje øke innstillingene for MaxUserPort og TcpTimedWaitDelay som er omtalt i Q319502 når du har pooling deaktivert. Innstillingene for disse verdiene bestemmes av hvor mange SQL Server-tilkobling åpner og lukker oppstå på klientsiden. Du kan undersøke hvor mange Klientporter er i TIME_WAIT-tilstanden ved hjelp av verktøyet Netstat på klientdatamaskinen. Kjøre Netstat-verktøyet som følger med flagget -n og telle antall klienten sockets til SQL Server-IP-adressen som er i TIME_WAIT-tilstanden. I dette eksemplet er 10.10.10.20 for IP-adressen til den eksterne datamaskinen som kjører SQL Server, IP-adressen til klienten er 10.10.10.10 og tre etablerte tilkoblinger og to tilkoblinger er i TIME_WAIT-tilstanden:
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
Hvis du kjører netstat - n , og du ser at det nesten 4000 tilkoblinger til IP adressen til måldatamaskinen som kjører SQL Server som er i TIME_WAIT-tilstanden, kan både øke MaxUserPort standardinnstillingen og redusere innstillingen for TcpTimedWaitDelay slik at du ikke slipper klient anonym porter. Du kan for eksempel angi innstillingen for MaxUserPort til 20000 og sette innstillingen for TcpTimedWaitDelay til 30. En lavere innstilling for TcpTimedWaitDelay betyr at socketene venter i TIME_WAIT-tilstanden på kortere tid. En høyere innstillingen for MaxUserPort betyr at du kan ha flere kontakter i TIME_WAIT-tilstanden.
Vær oppmerksom på at hvis du endrer innstillingen for MaxUserPort - eller TcpTimedWaitDelay , må du starte Microsoft Windows før de nye innstillingene skal tre i kraft. Innstillingen for MaxUserPort og TcpTimedWaitDelay er for en hvilken som helst klientdatamaskin som snakker med en datamaskin som kjører SQL-Server over TCP/IP sockets. Disse innstillingene har ikke noen innvirkning hvis de er satt på datamaskinen som kjører SQL-Server med mindre du foretar lokal TCP/IP-socket tilkoblinger til den lokale datamaskinen som kjører SQL Server.
Obs! Hvis du endrer innstillingen for MaxUserPort , anbefaler vi at du reserverer porten 1434 for bruk av SQL Server Browser-tjenesten (sqlbrowser.exe). For mer informasjon om hvordan du gjør dette, klikker du følgende artikkelnummer for å vise artikkelen i Microsoft Knowledge Base:
812873 reservere en rekke midlertidige porter på en datamaskin som kjører Windows Server 2003 eller Windows 2000 Server
Justere innstillingen for WinsockListenBacklog
Hvis du vil ha mer informasjon om denne registerinnstillingen for SQL Server-spesifikk, klikker du artikkelnummeret nedenfor for å vise artikkelen i Microsoft Knowledge Base:
154628 INF: SQL logger 17832 med flere TCP\IP tilkoblingsforespørsler
Når nettverksbiblioteket som SQL Server lytter på TCP/IP-socketer, bruker SQL Server-nettverksbiblioteket du lytte Winsock API. Den andre parameteren for på lytte API er restansen som er tillatt for socket. Denne Restanse representerer maksimal lengde på kø for ventende tilkoblinger for lytteobjektet. Når lengden på køen overskrider denne maksimale lengden, avviser nettverksbiblioteket som SQL Server umiddelbart flere forsøk på TCP/IP-socket. Nettverksbiblioteket som SQL Server, i tillegg sender en TILBAKESTILLING av + ACK-pakke.
SQL Server 2000 bruker en standard lytte Restanse innstilling av 5. Dette betyr at datamaskinen som kjører SQL-Server sender verdien 5 til parameteren Restanse av det Lytt Winsock API når APIen lytte konfigurerer TCP/IP-protokollen lyttende trådene på datamaskinen som kjører SQL Server. Du kan justere WinsockListenBacklog registernøkkelen for å angi en annen verdi som skal sendes for denne parameteren. Starter i SQL Server 2005, sender nettverksbiblioteket verdien SOMAXCONN med innstillingen Restanse du lytte API. SOMAXCONN gjør det mulig for Winsock til å angi en fornuftig maksimumsverdien for denne innstillingen. Registernøkkelen WinsockListenBacklog er derfor ikke lenger brukes eller behov i SQL Server 2005.
Restanse innstilling fungerer som følger: La oss si at en tilfeldig tjenesten lytter etter innkommende forespørsler for TCP/IP-socket. Hvis du setter innstillingen Restanse til 5 og mange forespørsler for socket-tilkoblingen er kontinuerlig streaming i, kan tjenesten ikke kunne svare på innkommende forespørsler som er like raskt som de kommer. Nå disse innkommende forespørslene i køen Restanse TCP/IP socket-laget i kø, og tjenesten senere kan trekke forespørsler fra denne køen og håndtere innkommende socket-tilkoblingen. Etter at køen fylles opp, avviser TCP/IP socket-laget umiddelbart eventuelle ekstra socket-forespørsler som kommer inn ved å sende en TILBAKESTILLING av + ACK-pakke tilbake til klienten. Hvis du øker antall ventende socket-tilkoblingen krever at TCP/IP-socket-laget i kø før forespørsler avslås Restanse køen filstørrelsen øker.
Legg merke til at innstillingen for WinsockListenBacklog er spesifikke for SQL Server. SQL Server prøver å lese denne registerinnstillingen når SQL Server-tjenesten starter første gang. Hvis innstillingen ikke finnes, brukes standard 5. Hvis registerinnstillingen finnes, SQL Server leser innstillingen og bruker den angitte verdien som kalles Restanse innstillingen når WinSock API lytte til TCP/IP-socket lyttende trådene er satt opp i SQL Server.
Hvis du vil fastslå om du kjører på dette problemet, kan du kjøre en nettverksovervåkingssporing på klienten eller datamaskinen som kjører SQL Server og se etter socket tilkoblingsforespørsler som avvises umiddelbart med en ACK + TILBAKESTILLING. Hvis du undersøker TCP/IP-pakker i Network Monitor, kan du se en pakke som den nedenfor når dette problemet oppstår:
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)
Vær oppmerksom på at Kildeporten er 0x599 eller 1433 i desimalformat. Dette betyr at pakken kommer fra en vanlig datamaskin som kjører SQL Server, og som kjører på standardporten for 1433. Legg også merke til at bekreftelses-felt som er viktig og tilbakestiller tilkoblingen -flagg er satt. Hvis du er kjent med en nettverksovervåkingssporing-filtrering, kan du filtrere TCP flaggene verdien av 0x14 heksadesimale å se bare ACK + tilbakestillingspakker i Network Monitor-spor.
Vær oppmerksom på at du også kan se lignende ACK + tilbakestillingspakker Hvis datamaskinen som kjører SQL Server ikke kjører i det hele tatt, eller hvis datamaskinen som kjører SQL Server ikke lytter til TCP/IP-protokoll, så ser ACK + tilbakestillingspakker ikke er bestemt bekreftelse på at du har dette problemet. Hvis WinsockListenBacklog er for lav, noen få forsøk på tilkobling godta pakker og noen tilkoblinger får umiddelbart ACK + tilbakestillingspakker innenfor samme tidsramme.
Legg merke til at i svært sjeldne tilfeller, du må kanskje justere denne innstillingen selv om pooling aktiveres på klientdatamaskiner. For eksempel hvis mange klientmaskiner snakker til en enkelt datamaskin som kjører SQL Server, kan et stort antall samtidige innkommende tilkoblingsforsøk oppstå når som helst bestemt selv om pooling er aktivert.
Obs! Hvis du justerer innstillingen for WinsockListenBacklog , har du ikke starte Windows for at denne innstillingen skal tre i kraft. Bare stoppe og starte SQL Server-tjenesten for innstillingen skal tre i kraft. Registerinnstillingen WinsockListenBacklog er bare for datamaskinen som kjører SQL Server. Den har ikke noen innvirkning på en hvilken som helst klientdatamaskin som snakker med SQL Server.
