Sammanfattning
När du använder SQL Server ODBC-drivrutinen eller SQL Server OLE DB-providern System.Data.SqlClient hanterade provider kan inaktivera du anslutningspoolen med respektive application programming interfaces (API). När du inaktiverar poolning ökas stress på underliggande SQL Server-nätverksbibliotek om programmet ofta öppnas och stängs anslutningar. Den här artikeln beskrivs vissa TCP/IP-inställningar som du kan behöva justera dessa villkor.
Mer Information
Stänga av pooler kan orsaka underliggande SQL Server nätverksdrivrutinen att snabbt öppna och stänga nya socketanslutningar på datorn som kör SQL Server. Du kan behöva ändra standardinställningarna TCP/IP-socket för operativsystemet och datorn som kör SQL Server för att hantera högre spänningsnivåer.
Observera att denna artikel endast beskrivs inställningar som påverkar nätverksbibliotek SQL Server när du använder TCP/IP-protokollet. Inaktivera delning kan också orsaka stress-relaterade problem med andra SQL Server-protokoll som namngivna pipes, men i det här avsnittet behandlas inte i denna artikel. Den här artikeln är avsedd för avancerade användare. Om du inte känner till avsnitten i den här artikeln, rekommenderar Microsoft att du ser en bra bok om TCP/IP sockets.
Observera att Microsoft rekommenderar att du alltid använder pooler med drivrutiner för SQL Server. Med pooling avsevärt förbättrar prestanda på både klienten och SQL Server-sida när du använder SQL Server-drivrutinerna. Med pool också avsevärt minskar nätverkstrafiken till datorn som kör SQL Server. Till exempel används ett sampel test som används för 20 000 SQL Server anslutning öppnas och stängs med poolning aktiverad cirka 160 TCP/IP-paket, totalt 23,520 byte av nätverksaktivitet. Samma prov prov genereras med pooling inaktiveras 225,129 TCP/IP-paket, totalt 27,209,622 byte av nätverksaktivitet.
Observera att när du ser dessa stress-TCP/IP-socket problem med SQL Server-nätverksbibliotek du kan få en eller flera av följande felmeddelanden visas när du försöker ansluta till en dator som kör SQL Server:
SQLServer finns inte eller åtkomst nekad
Tidsgränsen har överskridits
Allmänt nätverksfel
TCP-Provider: Tillåts normalt bara en användare för varje socketadress (protokoll/nätverksadress/port).
Observera att du också kan få dessa felmeddelanden när andra problem uppstår i SQL Server. till exempel visas dessa felmeddelanden om den fjärrdator som kör SQL Server stängs, om den fjärrdator som kör SQL Server inte lyssnar på TCP/IP-sockets alls, om nätverksanslutningen till datorn som kör SQL Server har avbrutits eftersom nätverkskabeln dras eller om du har problem med DNS-matchning. I princip kan allt som kan leda till att klienten inte ska öppna en TCP/IP-socket till datorn som kör SQL Server också orsaka felmeddelanden. Men med en socket stress-relaterade problem uppstår problemet periodvis påkänningen stiger och faller. Datorn kan köra i timmar utan fel sedan felet inträffar en eller två gånger och datorn därefter körs flera timmar utan fel. Även när du har det här problemet allmän anslutning till SQL Server fungerar ett ögonblick, misslyckas nästa och fungerar igen nästa ögonblick. Med andra ord socket stress-relaterade problem vanligen sporadiskt, men verkliga problem med nätverksanslutningen med SQL Server normalt förekommer inte sporadiskt.
Två huvudsakliga stress-relaterade problem uppstår vanligtvis när du inaktiverar pool medan du använder protokollet TCP/IP för SQL Server: du kan köra från anonym portar på klientdatorn eller du kan överskrida standardinställningen för WinsockListenBacklog på datorn som kör SQL Server.
Ytterligare information om anonym portar klickar du på artikelnumret nedan och läser artikeln i Microsoft Knowledge Base:
319502 PRB: "WSAEADDRESSINUSE" felmeddelande när du försöker ansluta via en anonym Port när du ökar gränsen för IMAP-anslutning
Ändra inställningarna för MaxUserPort och TcpTimedWaitDelay
Observera att inställningarna MaxUserPort och TcpTimedWaitDelay gäller bara för en klientdator som snabbt öppna och stänga anslutningar till en fjärrdator som kör SQL Server och som använder inte anslutningspool. Dessa inställningar är tillämpliga på en server för Internet Information Services (IIS) som betjänar ett stort antal inkommande HTTP-begäranden och som öppna och stänga anslutningar till en fjärrdator som kör SQL Server och som använder protokollet TCP/IP med pooling inaktiveras. Om poolning används, behöver du inte justera inställningarna MaxUserPort och TcpTimedWaitDelay .
När du använder protokollet TCP/IP för att öppna en anslutning till en dator som kör SQL Server, öppnar det underliggande SQL Server-nätverksbiblioteket en TCP/IP-socket till datorn som kör SQL Server. När det öppnas denna socket kan inte SQL Server-nätverksbibliotek alternativet SO_REUSEADDR TCP/IP-socket. Mer information om inställningen SO_REUSEADDR socket finns i avsnittet "Setsockopt" i Microsoft Developer Network (MSDN).
Observera att SQL Server-nätverksbibliotek specifikt inte aktiverar alternativet SO_REUSEADDR TCP/IP uttag av säkerhetsskäl. När SO_REUSEADDR aktiveras en angripare kapa en klientport till SQL Server och använda autentiseringsuppgifter som klienten ger tillgång till datorn som kör SQL Server. Eftersom SQL Server-nätverksbibliotek inte aktivera alternativet SO_REUSEADDR socket, varje gång du öppnar och stänger en socket via SQL Server network library på klientsidan som standard anger TIME_WAIT-tillståndet för fyra minuter socketen. Om du snabbt öppna och stänga anslutningar till SQL Server över TCP/IP med pooling inaktiveras kan du snabbt öppnar och stänger TCP/IP sockets. Med andra ord har varje SQL Server-anslutning en TCP/IP-socket. Om du snabbt öppna och stänga 4000 sockets på mindre än fyra minuter, uppnår du högsta standardinställningen för anonyma klientportar och nya socket anslutningsförsök misslyckas tills timeout befintlig uppsättning TIME_WAIT sockets.
På klientsidan kanske du öka MaxUserPort och TcpTimedWaitDelay inställningarna som beskrivs i Q319502 när du har pool inaktiveras. Inställningarna för de här värdena bestäms av hur många SQL Server-anslutning öppnas och stängs uppstår på klientsidan. Du kan kontrollera hur många klientportar är i TIME_WAIT-tillståndet med hjälp av Netstat på klientdatorn. Kör Netstat-verktyget på följande sätt med flaggan -n och räkna antalet klient sockets till SQL Server-IP-adress som är i TIME_WAIT-tillståndet. I det här exemplet är 10.10.10.20 för IP-adressen för den fjärrdator som kör SQL Server, IP-adressen till klientdatorn är 10.10.10.10 och tre etablerade anslutningar och två anslutningar är i TIME_WAIT-tillståndet:
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
Om du kör netstat - n och ser att nära 4000 anslutningar till den IP-adressen för datorn som kör SQL Server finns i TIME_WAIT-tillståndet kan du både öka MaxUserPort standardinställningen och minska inställningen TcpTimedWaitDelay så att du inte kör få anonyma klient-portar. Du kan till exempel ange inställningen MaxUserPort till 20000 och ställa TcpTimedWaitDelay till 30. En lägre inställning för TcpTimedWaitDelay betyder att uttaget vänta i TIME_WAIT-tillståndet på kortare tid. En högre inställning MaxUserPort betyder att du kan ha flera sockets i TIME_WAIT-tillståndet.
Observera att om du ändrar inställningen MaxUserPort eller TcpTimedWaitDelay måste du starta om Microsoft Windows för den nya inställningen ska börja gälla. MaxUserPort och TcpTimedWaitDelay inställningar gäller för alla klientdatorer som tala till datorn som kör SQL Server över TCP/IP sockets. Dessa inställningar har inte någon effekt om de är inställda på datorn som kör SQL Server om du gör lokala TCP-socket-anslutningar till den lokala datorn som kör SQL Server.
Obs! Om du ändrar inställningen MaxUserPort rekommenderar vi att du reservera port 1434 för användning av tjänsten SQL Server Browser (sqlbrowser.exe). För mer information om hur du gör detta klickar du på följande artikelnummer och läser artikeln i Microsoft Knowledge Base:
Hur 812873 reservera ett intervall av tillfälliga portar på en dator som kör Windows Server 2003 eller Windows 2000 Server
Justera inställningarna för WinsockListenBacklog
Mer information om SQL Server-specifik registerinställningen klickar du på artikelnumret nedan och läser artikeln i Microsoft Knowledge Base:
154628 INF: SQL-loggar 17832 med flera begäranden för TCP/IP-anslutning
När SQL Server-nätverksbibliotek som lyssnar på TCP/IP-sockets, används SQL Server-nätverksbibliotek den Lyssna Winsock API. Den andra parametern för den Lyssna API är eftersläpning som tillåts för socketen. Denna eftersläpning representerar den maximala längden på kön av väntande anslutningar för lyssnaren. När längden på kön överskrider denna maximala längd, avvisar SQL Server-nätverksbibliotek omedelbart mer anslutningsförsök för TCP/IP-socket. Dessutom skickar SQL Server-nätverksbibliotek ett ACK + Återställ paket.
SQL Server 2000 använder en standard lyssna eftersläpning inställning av 5. Detta innebär att datorn som kör SQL Server skickar värdet 5 till parametern eftersläpning för de Lyssna Winsock API när Lyssna API konfigurerar TCP/IP-protokollet lyssnande trådar på datorn som kör SQL Server. Du kan justera registernyckeln WinsockListenBacklog om du vill ange ett annat värde som ska skickas för den här parametern. Starta i SQL Server 2005 skickar nätverksbiblioteket värdet SOMAXCONN som inställningen eftersläpning på Lyssna API. SOMAXCONN gör att Winsock-provider att ange ett rimligt maximalt värde för inställningen. Registernyckeln WinsockListenBacklog är därför inte längre används eller behövs i SQL Server 2005.
Orderstocken för att ändringen på följande sätt: Anta att en valfri tjänst lyssnar efter inkommande begäranden för TCP/IP-socket. Om eftersläpning ställa till 5 och många anslutningsbegäranden för socket kontinuerligt direktuppspelning i kanske tjänsten inte svarar lika snabbt som de kommer inkommande förfrågningar. I detta skede TCP/IP-socket layer köer dessa inkommande begäranden i kön eftersläpning och tjänsten senare hämtar förfrågningarna från kön och hantera inkommande sockenanslutningsbegäran. När kön fylls avvisar TCP/IP-socket layer omedelbart alla ytterligare socket-begäranden som kommer genom att skicka ett paket ACK + Återställ tillbaka till klienten. Öka antalet väntande socketanslutning begär att TCP/IP-socket layer köer innan begäran avvisas eftersläpning kön storlek ökar.
Observera att inställningen för WinsockListenBacklog är specifika för SQL Server. SQL Server försöker läsa denna registerinställning när SQL Server-tjänsten startar. Om inställningen inte finns, används standardvärdet på 5. Om registerinställningen SQL Server läser inställningen och använder värdet som inställningen eftersläpning när WinSock API lyssna kallas som TCP/IP-socket lyssnande trådar ställs upp i SQL Server.
Ta reda på om du kör till problemet du kör Network Monitor-spår på klienten eller den dator som kör SQL Server och leta efter uttag anslutningsbegäranden som avvisas omedelbart med en ACK + återställning. Om du kontrollera TCP/IP-paket i Network Monitor visas ett paket följande när problemet uppstå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)
Observera att källporten är 0x599 eller 1433 i det decimala talsystemet. Detta innebär att paketet kommer från en vanlig dator som kör SQL Server och som körs på standardporten 1433. Tänk också på att fältet för bekräftelse och återställa anslutningen flaggor är inställda. Om du är bekant med filtrering Network Monitor-spår kan filtrera du TCP flaggor värde av 0x14 hexadecimala Se ACK + Återställ paket i Network Monitor-spår.
Observera att du också kan se liknande ACK + återställningspaket om den dator där SQL Server inte körs alls eller om datorn som kör SQL Server inte lyssnar till TCP/IP-protokoll, så se ACK + återställningspaket inte är definitiva bekräftelse på att du har det här problemet. Om WinsockListenBacklog är för låg, vissa anslutning försöker få accepterar paket och vissa anslutningar får omedelbart ACK + återställningspaket i samma tidsram.
Observera att i mycket sällsynta fall kan du behöva justera inställningen även om poolning används på klientdatorerna. Till exempel om många klientdatorer talar till en dator som kör SQL Server, kan ett stort antal samtidiga inkommande anslutningsförsök uppstå vid en viss tidpunkt även om poolning används.
Obs! Om du ändrar inställningen för WinsockListenBacklog behöver du inte starta om Windows för att inställningen ska börja gälla. Bara stoppa och starta om tjänsten SQL Server för att inställningen ska börja gälla. Registerinställningen WinsockListenBacklog är endast för datorn som kör SQL Server. Det har inte någon effekt på alla klientdatorer som tala till SQL Server.
