|
SQLSERVER felhasználói kapcsolatok Az SQL példány általános statisztikai felhasználói kapcsolatai a teljesítményszámlálóban ennek felelnek meg A teljesítményszámlálóban a TCPv4Connections Established oldalra is hivatkozhat
Egy gépen, ahol csak az SQLSERVER szolgáltatás van,TCPV4 kapcsolatok létrehozása && mssql UserConnectionsEz a két paraméter alapvetően szinkronizált, és a következő teszttartalomban a kapcsolatok számának nevezik őket
Ez a kapcsolatszám korlátozott, hasonlóan a maximális egyidejű korlátokhoz. Ha ez a határ eléri, a lekérdezések nem reagálnak rá, még akkor is, ha vannak szabad CPU, IO és MEM erőforrások (néhány, nem minden lekérdezés érintett)
A TCPV4 Connections Established && Mssql UserConnections maximális értéke a következő tényezőktől függ
a. A végrehajtási utasítás összetettsége összefügg: minél összetettebb az állítás, annál kisebb a maximális kapcsolat (ez a hatás nagyon fontos)
b. Ez kapcsolódik a kérés szál egyidejű egyidejű szakaszához,
10 folyamat, minden folyamat 5 000 szálat nyit meg a kérésre,SELECT getdate()A kijelentést már elhagyják, amikor eléri a 4000-es számot (az én értelmezésem szerint bár sok szál nem kért erőforrásokat, a kérések száma nagy, ami szintén hatással van).
10 folyamat, minden folyamat 1000 szálat nyit meg a kéréshez, SELECT getdate()A kijelentések elérhetik a 10 000 dollárt.
c. Ez a szálkérések gyakoriságával függ
Ha minden szál futtat egy lekérdezést és 0-10 000 milliszekundumra megáll, kevesebb kapcsolatot foglal el, mint ha nincs felfüggesztve,
d. A teszt során azt is megállapították, hogy néhány záratlan csatlakozás felfújja a számlálót, amit nem tárgyaltak
10 folyamat, mindegyik folyamat 1000 kérésszálat nyit meg, véletlenszerűen szünetet tart (0-10 másodperc) minden lekérdezés után a szerveren. A teszteredmények a következők:
Végrehajtás:VÁLASSZ * FROM [rendszer]. [dbo]. [DBA_alert]állítás (ez a lekérdezés 200 sort ad vissza, a maximális kapcsolat száma 700, és a probléma elkezd megjelenni)
Amikor a kapcsolatok száma eléri a 700-at, néhány hibát kezdenek jelenteni, és 1200-nál nagy számú hiba jelenik meg, és a 1800 körüli kapcsolatok száma elakad, és már nem emelkedik. Hibák és lassú kapcsolatok bőven vannak
Végrehajtás:SELECT getdate()A mondat ideje(A maximális kapcsolat száma 3500, és a probléma kezdődik)
Amikor a csatlakozások száma eléri a 3500-at, néhányan hibákat kezdenek jelenteni, a legmagasabb nyomás pedig körülbelül 11000-re ér, és a csatlakozások száma még mindig lassan nő. Hibák és lassú csatlakozási kitörések
A következtetés az: adott nyomás alatt: a legegyszerűbb végrehajthatóA maximális kapcsolatszám akár 3500 lehet, amikor SELECT getdate(), és a SELECT * FROM [rendszer] futtatása alatt történik. [dbo]. [DBA_alert] állítás esetén a maximális kapcsolatszám legfeljebb 700 lehet. A lekérdezési időkérés akkor következik be, amikor a CPU, az IO és a MEM mind sok üres erőforrással rendelkezik.
A gyártási környezetben nem érhetők el a 10*1000 szál nyomása, de az SQL összetettebb lesz, mint a tesztkörnyezet.
Egyidejű számA szűk keresztmetszetet nem a számítógépem vagy szerverkártyám sávszélessége okozza
Hogy bizonyítsam a fentieket. A következő teszteket végeztem, nagy egyidejű esetén exec dbo.run2;
ALTER proc [dbo]. [run2]
mint
Állítsa be a nocount
Select: getdate()
decl @i int
@i=0
míg @i<1000 Ha ez az érték 1000, a maximális kapcsolat száma körülbelül 1300, és ha ez az érték 10, normális elérni az 5000-et.
Kezdeni
BEHELYEZKEDJ [kocsmákba]. [dbo]. [tb_test] ([name]) értékek (newid())
set @i=@i+1
vége
Menj
A váltási ciklusok száma nem befolyásolja a visszaküldési eredményt, vagyis a hálózati kártya forgalomára gyakorolt nyomás ugyanaz, de az egyik gyorsan időlejár, a másik pedig mindig ellenőrizhető, így a hálózati kártyák sávszélességének mindkét oldalon hatása kizárható.
Hibatartalom, amikor a maximális számú kapcsolat megáll:
Netstat – egy eredmény, amikor a maximális kapcsolati szám beragad (erősen megalapozott):
Tesztprogramot futtatva diagram, amikor a maximális kapcsolatszám leáll:
Érdemes megjegyezni:A hibákkal vagy időtúllépésekkel való kapcsolat nem egyenlő, és bizonyos folyamatokban koncentrálódik, vagyis egyes folyamatok mindig normálisan működhetnek, a másik rész pedig hosszú ideig jelent hibákat (ez semmi köze a folyamatok kezdeti sorrendjéhez, az én értelmezésem szerint egyes folyamatok rendelkeznek erőforrásokkal, képesek normálisan működni, míg az eredeti erőforrások szálaiban lévő más folyamatok előzmények, és nem jelentkezhetnek új erőforrásokra, folyamatosan jelentéseket jelentenek a hibákról). Ahogy a fenti ábrán látható, a 2. és 7. folyamatok sok időkorlátot kaptak, és más folyamatok tovább működtek. A szerveren a lekérdezések bizonyos gépek érintetlennek vagy kevésbé érintettnek tűnhetnek, míg egyes gépek jelentősen érintettek.
Következtetés: Bár az SQLSERVER felhasználói kapcsolatok felső határa több feltételhez kapcsolódik, még mindig lehetséges a szűk keresztmetszet becslése és előrejelzése, és amikor elérjük ezt a felső határt, nagy számú lekérdezés lassítja és időtúllépést fog okozni (bár a CPU, IO. MEM, forgalom akkor is előfordulhat, ha tétlen erőforrások vannak). Valójában néhány TCP paraméter megváltoztatása növeli ezt a felső határt, és később írhatok kiegészítőket
|
Közzétéve 2014. 11. 26. 15:11:08
|
|
|
|
