Rezumat
Când utilizați driverul de SQL Server ODBC, SQL Server OLE DB provider sau furnizorul de System.Data.SqlClient gestionate, aveți posibilitatea să dezactivați conexiunea soclurilor utilizând interfețe de programare a aplicațiilor respective (API). Când dezactivați soclurilor, stres în biblioteca de rețea bază SQL Server poate fi crescut dacă aplicația frecvent se deschide și se închide conexiunile. Acest articol descrie anumite setări TCP/IP, care poate fi necesar să ajustați în aceste condiții.
Mai multe informații
Dezactivarea soclurilor poate provoca driverul de rețea SQL Server bază la rapid deschideți și închideți nou soclu conexiuni pe computerul care execută SQL Server. Trebuie să modificați setările implicite TCP/IP socket pentru sistemul de operare și computerul care execută SQL Server să se ocupe mai mare nivelul de stres.
Rețineți că acest articol prezintă numai setările care afectează Biblioteca SQL Server de rețea atunci când utilizați protocolul TCP/IP. Dezactivarea soclurilor poate cauza probleme legate de stres cu alte protocoale de SQL Server, cum ar fi canale denumite pentru, dar acest articol nu discuta despre acest subiect. Acest articol este doar pentru utilizatorii avansați. Dacă nu înțelegeți subiecte în acest articol, Microsoft recomandă să vedeți o carte bună despre TCP/IP sockets.
Rețineți că Microsoft recomandă insistent să utilizați întotdeauna soclurilor cu driverele de SQL Server. Utilizarea grupării mult îmbunătățește performanța generală atât pe partea de client şi partea SQL Server atunci când utilizați drivere de SQL Server. Utilizarea grupării, de asemenea, considerabil reduce traficul de rețea pe computerul care execută SQL Server. De exemplu, o probă care utilizează 20 000 SQL Server conexiunea se deschide și se închide cu soclurilor activat utilizează aproximativ 160 pachete de rețea TCP/IP, pentru un total de octeţi 23,520 de activitate de rețea. Cu soclurilor dezactivat, aceeași probă generat 225,129 pachete de rețea TCP/IP, pentru un total de octeţi 27,209,622 de activitate de rețea.
Rețineți că atunci când vedeți aceste stres TCP/IP socket probleme asociate cu bibliotecile de SQL Server de rețea, este posibil să primiți unul sau mai multe dintre următoarele mesaje de eroare când încercați să vă conectați la un computer care execută SQL Server:
SQL Server nu există sau acces refuzat
Timp de aşteptare expirat
Eroare de rețea generală
Furnizor TCP: Numai o singură utilizare a fiecărei adrese de soclu (protocol/reţea adresă/port) este permis în mod normal.
Rețineți că, de asemenea, puteţi primi aceste mesaje de eroare specific atunci când alte probleme se produc cu SQL Server; de exemplu, este posibil să primiți aceste mesaje de eroare dacă se închide computerul la distanță care execută SQL Server, în cazul în care computerul la distanță care execută SQL Server nu ascultă la TCP/IP sockets deloc, dacă conectivitate în rețea pe computerul care execută SQL Server se întrerupe, deoarece este scos cablul de rețea sau dacă aveți probleme de rezolvare DNS. Practic orice element care pot provoca clientul să nu reușească să deschideți un soclu TCP/IP pe computerul care execută SQL Server poate provoca, de asemenea, mesajele de eroare. Cu toate acestea, cu o problemă referitoare la stres socket, problema apare intermitent stres creşte şi scade. Computerul poate executa ore fără erori, apoi eroarea apare unul sau două ori și computerul, apoi se execută pentru mai multe mai multe ore fără erori. De asemenea, atunci când aveți această problemă, generale de conectivitate la SQL Server funcționează o clipă, nu reușește următoare, apoi funcţionează din nou următorul instant. Cu alte cuvinte, probleme legate de stres socket apar de obicei sporadic, dar real problemele de conectivitate cu SQL Server nu apar de obicei sporadic.
Două probleme principale legate de stres apar de obicei Când dezactivați soclurilor în timp ce utilizați SQL Server TCP/IP protocol: este posibil să executați din anonim porturi pe computerul client sau se depășește setarea implicită de WinsockListenBacklog pe computerul care execută SQL Server.
Pentru informații suplimentare despre porturi anonim, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:
319502 PRB: 'WSAEADDRESSINUSE' mesaj de eroare când încercați să vă conectați printr-un Port anonim după creșteți limita de conexiune IMAP
Ajustați setările MaxUserPort și TcpTimedWaitDelay
Rețineți că setările MaxUserPort și TcpTimedWaitDelay se aplică numai pentru un computer client care este rapid deschiderea și închiderea conexiuni la un computer la distanță care execută SQL Server și care nu utilizează gruparea de conexiuni. De exemplu, aceste setări se aplică pe un server Internet Information Services (IIS) care este un număr mare de solicitări HTTP intrare întreținerea și care este deschiderea și închiderea conexiuni la un computer la distanță care execută SQL Server și care utilizează protocolul TCP/IP cu soclurilor dezactivat. Dacă gruparea este activată, nu trebuie să reglați setările MaxUserPort și TcpTimedWaitDelay .
Când utilizați protocolul TCP/IP pentru a deschide o conexiune la un computer care execută SQL Server, biblioteca de rețea bază SQL Server se deschide un soclu TCP/IP pe computerul care execută SQL Server. Când se deschide acest soclu, biblioteca de rețea SQL Server nu activează opțiunea socket SO_REUSEADDR TCP/IP. Pentru mai multe informații despre setarea socket SO_REUSEADDR , consultați subiectul "Setsockopt" în Microsoft Developer Network (MSDN).
Rețineți că biblioteca de rețea SQL Server în mod special activați opțiunea soclu SO_REUSEADDR TCP/IP din motive de securitate. Când este activată SO_REUSEADDR , un utilizator rău intenționat poate hijack un port client la SQL Server și utilizați acreditări care furnizează client pentru a obține acces la computerul care execută SQL Server. În mod implicit, deoarece biblioteca de rețea SQL Server nu activează opțiunea socket SO_REUSEADDR , de fiecare dată când deschideți și închideți un socket prin Biblioteca SQL Server de rețea pe partea client, soclul intră în starea TIME_WAIT patru minute. Dacă sunteți rapid deschiderea și închiderea SQL Server conexiuni prin TCP/IP cu soclurilor dezactivat, rapid sunt deschiderea și închiderea TCP/IP sockets. Cu alte cuvinte, fiecare conexiune SQL Server are un soclu TCP/IP. Dacă deschideți rapid și închideți 4000 sockets în mai puțin de patru minute, veţi ajunge la setarea implicită maximă pentru client anonim porturi și nou soclu încercările de conexiune nu până la setul existent de socluri TIME_WAIT expiră.
Pe partea client, trebuie să măriți setările MaxUserPort și TcpTimedWaitDelay care sunt discutate în Q319502 atunci când aveți soclurilor dezactivat. Setările pentru aceste valori sunt determinate de cât de multe SQL Server connection se deschide și se închide apar în partea de client. Aveți posibilitatea să examinați cât de multe porturi client sunt într-o stare TIME_WAIT utilizând instrumentul Netstat pe computerul client. Executați instrumentul Netstat cu semnalizatorul -n după cum urmează, și numărul de client sockets la adresa IP a serverului SQL care se află într-o stare de TIME_WAIT. În acest exemplu, adresa IP a computerului la distanță care execută SQL Server este 10.10.10.20, adresa IP a computerului client este 10.10.10.10 și trei stabilit de două conexiuni și conexiuni într-o stare de 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
Dacă executați netstat -n și observați că aproape 4000 conexiuni la adresa IP din computerul țintă care execută SQL Server sunt într-o stare TIME_WAIT, puteți ambele măriți setarea implicită MaxUserPort și reduceți setarea TcpTimedWaitDelay , astfel încât să nu se execută din porturi client anonim. De exemplu, puteți setarea MaxUserPort 20000 și setarea TcpTimedWaitDelay la 30. O setare mai mică TcpTimedWaitDelay înseamnă că sockets așteptați în starea TIME_WAIT mai puţin timp. O setare mai mare de MaxUserPort înseamnă că aveți mai multe sockets în starea TIME_WAIT.
Rețineți că dacă ajustați setarea MaxUserPort sau TcpTimedWaitDelay , trebuie să reporniți Microsoft Windows pentru ca noile setări să aibă efect. Setările MaxUserPort și TcpTimedWaitDelay sunt pentru orice computer client care vorbește la un computer care execută SQL Server prin TCP/IP sockets. Aceste setări nu are niciun efect, dacă acestea sunt setate la computerul care execută SQL Server decât dacă vă fac local conexiuni de soclu TCP/IP pe computerul local care execută SQL Server.
Notă Dacă ajustați setarea MaxUserPort , vă recomandăm că vă rezerva port 1434 pentru utilizarea de către serviciul SQL Server Browser (sqlbrowser.exe). Pentru mai multe informații despre cum se face acest lucru, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:
812873 cum să rezerve un interval de porturi efemere pe un computer care execută Windows Server 2003 sau Windows 2000 Server
Ajustați setarea WinsockListenBacklog
Pentru informații suplimentare despre această setare de registry specifice SQL Server, faceți clic pe următorul număr de articol pentru a vedea articolul în baza de cunoștințe Microsoft:
154628 INF: SQL înregistrează 17832 cu mai multe solicitări de conexiune TCP\IP
Când biblioteca de rețea SQL Server ascultă pe socluri TCP/IP, biblioteca de rețea SQL Server utilizează asculta Winsock API. Al doilea parametru pentru a asculta API este întârzierile permisă pentru soclul. Acest jurnal de aşteptare reprezintă lungimea maximă a coada de așteptare conexiuni pentru instanța de ascultare. Atunci când durata de coada depășește lungimea maximă, biblioteca de rețea SQL Server respinge imediat mai multe soclu TCP/IP încercările de conexiune. În plus, biblioteca de rețea SQL Server Trimite un pachet ACK + resetare.
SQL Server 2000 utilizează un implicit asculta întârzierile setarea de 5. Aceasta înseamnă că computerul care execută SQL Server transferă valoarea 5 de parametrul de jurnal de aşteptare a asculta Winsock API când ascultați API stabileşte protocolul TCP/IP ascultă fire pe computerul care execută SQL Server. Puteți ajusta WinsockListenBacklog cheia de registry pentru a specifica o valoare diferită pentru a fi trecut pentru acest parametru. Începând cu SQL Server 2005, biblioteca de rețea trece valoarea SOMAXCONN ca setarea de jurnal de aşteptare pentru a asculta API. SOMAXCONN permite Winsock furnizorul pentru a seta o valoare rezonabilă maximă pentru această setare. De aceea, cheia de registry WinsockListenBacklog nu mai este utilizat sau necesare în SQL Server 2005.
Jurnal de aşteptare setarea funcționează după cum urmează: să presupunem că un serviciu arbitrar este de ascultare pentru solicitări de soclu TCP/IP intrare. Dacă setați setarea de jurnal de aşteptare la 5 și mai multe cereri de conexiune socket sunt redare în flux continuu în, serviciul nu poate fi capabil să răspundă la solicitările de primire cât de repede vor veni în. În acest moment, TCP/IP socket layer cozi acestor solicitări de intrare în coada de jurnal de aşteptare și serviciul mai târziu poate trage solicitările din această coadă și gestiona solicitarea de conectare socket primite. După coadă umple, TCP/IP socket layer imediat respinge solicitările de socluri suplimentare care intră prin trimiterea unui pachet ACK + REINIȚIALIZARE clientului. Mărirea întârzierile coadă dimensiunea creşte numărul de așteptare socket conexiune solicită că stratul soclu TCP/IP cozi înainte de solicitările sunt respinse.
Rețineți că setarea WinsockListenBacklog este specifică pentru SQL Server. SQL Server încearcă să citească această setare de registry la prima pornire a serviciului SQL Server. Dacă setarea nu există, se utilizează implicit de 5. Dacă setarea de registry există, SQL Server citește setarea și utilizează valoarea furnizate ca setarea întârzierile când ascultați WinSock API este numit ca subiectele de ascultare soclu TCP/IP sunt setate până în interiorul SQL Server.
Pentru a determina dacă se execută în această problemă, puteți executa o urmă Monitor rețea pe client sau pe computerul care execută SQL Server și căutați socket conexiune solicitările care sunt respinse imediat cu o ACK + resetare. Dacă examinați TCP/IP pachete în Network Monitor, vedeți un pachet, cum ar fi următoarele atunci când se produce această problemă:
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)
Rețineți că portul sursă este 0x599 sau 1433 în zecimal. Acest lucru înseamnă că pachet provine de la un computer obișnuit care execută SQL Server și care se execută pe portul implicit de 1433. De asemenea, Rețineți câmpul de confirmare semnificativ și Semnalizatoarele de resetare conexiune sunt setate. Dacă sunteți familiarizat cu filtrare o urmă Monitor rețea, puteți filtra valoarea TCP semnalizările de 0x14 hexazecimal pentru a vedea numai ACK + REINIȚIALIZARE pachetele în urmă Monitor rețea.
Rețineți că, de asemenea, puteți vedea similare ACK + REINIȚIALIZARE pachete dacă pe computer care execută SQL Server nu se execută la toate sau la computerul care execută SQL Server nu ascultă protocolul TCP/IP, astfel încât să vedeți ACK + REINIȚIALIZARE pachete nu este definit de confirmare că aveți această problemă. Dacă WinsockListenBacklog este prea mică, unele conexiune încercările primiți accepta unele conexiuni de pachete și primi imediat ACK + REINIȚIALIZARE pachete în aceeași perioadă de timp.
Rețineți că, în foarte rare cazuri, poate fi necesar să reglați această setare, chiar dacă gruparea este activat pe computerele client. De exemplu, dacă numărul de computere client sunt comunicarea cu un singur computer care execută SQL Server, un număr mare de simultane intrare încercările de conexiune pot apărea în orice moment special chiar dacă gruparea este activat.
Notă Dacă ajustați setarea WinsockListenBacklog , nu trebuie să reporniți Windows pentru această setare să aibă efect. Doar opriți și reporniți serviciul SQL Server pentru setarea să aibă efect. Setarea de registry WinsockListenBacklog este numai pentru computerul care execută SQL Server. Nu are niciun efect pe orice computer client care vorbește la SQL Server.
