|
SQLSERVER-käyttäjäyhteydet SQL-instanssin yleiset tilastot suorituskykylaskurissa vastaavat sitä Voit myös katsoa TCPv4Connections Established suorituskyvyn laskurissa
Koneella, jossa on vain SQLSERVER-palvelu,TCPV4-yhteydet muodostettu && Mssql UserConnectionsNämä kaksi parametria ovat käytännössä synkronoituja ja niitä kutsutaan seuraavassa testisisällössä yhteyksien lukumääräksi
Tämä yhteyksien määrä on rajoitettu, samankaltainen kuin maksimimäärä samanaikaisia rajoituksia. Kun tämä raja saavutetaan, kyselyt muuttuvat vastaamattomiksi, vaikka CPU-, IO- ja MEM-resursseja olisi vapaita (jotkut, eivät kaikki, kyselyt ovat vaikutuksen alaisia)
TCPV4 Connections Established && Mssql UserConnectionsin maksimiarvo riippuu seuraavista tekijöistä
a. Suorituslauseen monimutkaisuus liittyy toisiinsa, mitä monimutkaisempi lause, sitä pienempi on suurin määrä yhteyksiä (tämä ilmiö on erittäin tärkeä)
b. Se liittyy pyynnön säikeen rinnakkaisuuteen,
10 prosessia, jokainen prosessi avaa 5 000 säikettä pyydettäväksi,VALITSE getdate()Väite on jo hylätty, kun se saavuttaa noin 4000 (ymmärtääkseni vaikka monet ketjut eivät ole pyytäneet resursseja, pyyntöjen määrä on suuri, mikä myös vaikuttaa).
10 prosessia, jokainen prosessi avaa 1000 säikettä pyydettäväksi, VALITSE getdate()Lausunnot voivat tavoittaa yli 10 000.
c. Se liittyy säiepyyntöjen esiintymistiheyteen
Jos jokainen säie suorittaa kyselyn ja pysähtyy 0–10 000 millisekunniksi, se vie vähemmän yhteyksiä kuin jos sitä ei ole keskeytetty
d. Testissä havaittiin myös, että jotkin sulkemattomat liitännät aiheuttivat laskurin täyttymisen, mistä ei keskusteltu
10 prosessia, jokainen prosessi avaa 1000 pyyntösäikettä, satunnaisesti tauko (0–10 sekuntia) jokaisen palvelimen kyselyn jälkeen. Testitulokset ovat seuraavat:
Toteutus:VALITSE * JÄRJESTELMÄSTÄ. [dbo]. [DBA_alert]lause (tämä kysely palauttaa 200 riviä, ja yhteyksien maksimimäärä on 700, jolloin ongelma alkaa syntyä)
Kun yhteyksien määrä saavuttaa 700, virheitä alkaa raportoida, ja klo 1200 alkaa ilmestyä suuri määrä virheitä, ja yhteyksien määrä noin 1800 jää jumiin eikä enää kasva. Virheitä ja hitaita yhteyksiä on runsaasti
Toteutus:VALITSE getdate()Tuomioaika(Suurin liitäntömäärä on 3500 ja ongelma alkaa)
Kun liitäntöjen määrä saavuttaa 3500, jotkut niistä alkavat raportoida virheitä, ja suurin paine nousee noin 11000:een, ja yhteyksien määrä kasvaa edelleen hitaasti. Virheitä ja hitaita yhteyden katkeamia
Johtopäätös on: annetuissa paineolosuhteissa: helpoin suorittaaSuurin yhteysmäärä voi olla jopa 3500, kun SELECT getdate(), ja suorita SELECT * FROM [system]. [dbo]. [DBA_alert]-lauseen mukaan yhteyksien enimmäismäärä voi olla enintään 700. Kyselyaikakatkaisu tapahtuu, kun CPU:lla, IO:lla ja MEM:llä on suuri määrä käyttämättömiä resursseja.
Tuotantoympäristössä 10*1000 säikeen paine on saavutettavissa, mutta SQL on monimutkaisempi kuin testiympäristö.
Samanaikainen lukuPullonkaula ei johdu tietokoneen tai palvelimen verkkokortin kaistanleveydestä
Todistaakseni yllä olevan. Tein seuraavat testit, exec dbo.run2 suurten samanaikaisten tapauksissa;
ALTER proc [dbo]. [run2]
kuten
aseta nocount päälle
valitse getdate()
julista @i int
joukko @i=0
kun taas @i<1000 Kun tämä arvo on 1000, suurin yhteysmäärä on noin 1300, ja kun tämä arvo on 10, on normaalia saavuttaa 5000.
Aloita
LAITA SISÄÄN [pubeihin]. [dbo]. [tb_test] ([name]) arvot (newid())
setti @i=@i+1
loppu
mene
Vaihtosyklien määrä ei vaikuta palautustulokseen, eli verkkokortin liikenteen paine on sama, mutta toinen aikakatkaistaan nopeasti ja toinen voidaan aina tarkistaa, jolloin verkkokorttien kaistanleveyden vaikutus molemmilla puolilla voidaan poistaa.
Virhesisältö, kun suurin määrä yhteyksiä on pysähtynyt:
Netstat – tulos, kun suurin yhteysmäärä jumittuu (vahvasti vakiintunut):
Testiohjelman kaavio, kun suurin määrä yhteyksiä on pysähtynyt:
On syytä huomata:Yhteys virheisiin tai aikakatkaisuihin ei ole tasainen, ja keskittyy joihinkin prosesseihin, eli jotkut prosessit voivat aina toimia normaalisti, ja toinen osa raportoi virheitä pitkään (sillä ei ole mitään tekemistä prosessien aloitusjärjestyksen kanssa, ymmärtääkseni joillakin prosesseilla on resursseja, ne voivat jatkaa normaalia toimintaa, kun taas alkuperäisten resurssien säikeiden muut prosessit ovat keskeytettyjä, eivätkä voi hakea uusia resursseja, vaan raportoivat virheitä toistuvasti). Kuten yllä olevasta kuvasta näkyy, 2. ja 7. prosessi alkoi saada paljon aikakatkaisuja, ja muut prosessit jatkoivat toimintaansa. Palvelimella kyselyt voivat näkyä vaikuttamattomina tai vähemmän joidenkin koneiden vaikutuksen alaisena, ja jotkut koneet kärsivät merkittävästi.
Johtopäätös: Vaikka SQLSERVER-käyttäjäyhteyksien yläraja liittyy useisiin ehtoihin, pullonkaulan arvioiminen ja ennustaminen on silti mahdollista; kun tämä yläraja saavutetaan, kyselyt hidastuvat ja aikakatkaisuja (vaikka CPU, IO. MEM, liikenne voi myös tapahtua, kun resurssit ovat käyttämättömiä). Itse asiassa joidenkin TCP-parametrien muuttaminen nostaa tätä ylärajaa, ja saatan kirjoittaa lisäravinteita myöhemmin
|
Julkaistu 26.11.2014 15.11.08
|
|
|
|
