Hej,

Tänkte att det kna vara en bra idé att skicka utt en liten blänkare så att jag inte missar nått eller om någon känner igen sig.

Jag sitter och jobbar mot en databasserver som börjar uppvisa en del problem.

Det som uppstår ibland är att den får
provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine.
vilket känns som ett 10053 winsockproblem.
Alternativt får vi
Software caused connection abort: recv failed
som påminner om ovanstående men jag har egentligen ingen aning om vad det det betyder mer specifikt.

Min fråga är egentligen vad som skulle kunna ge dessa fel? Är det ett generellt prestandaproblem med databasserver, diskarna, eller nått annat jag bör titta på?

Maskinen är en win2003 sp2 x64 med mssql2005 x64 standard edition.
Vad jag kan se på den så peakar diskanvändningen på databasdiskarna och även processorn titt som tätt.
T.ex. har de laggt tempfilskapande av stora tempfiler 50->300GB på samma diskar som databasen :(.

Min idé är att det är pretanda, troligast relaterat till diskanvändingen och jag sitter just nu och försöker flytta bort så mycket som möjligt från servern, men det är inte helt lätt när det är flera års adhocprogramerande med hårdkodningar och beroenden som ligger där....

/Martin

Hej,
Skullle nog ha uppdaterat lite om vad jag hunnit göra och kolla.

1. Problemet verkar ha tilltagit med på senare tid, likaså har belastningen kontinuerligt ökat.
2. TCPChimney är är avstängt och även de andra servrarna som är beroende av databasen som kör 2003 vhar det avstängt.
3. win2k3 har sitt syn-flood DOS skydd aktiverat.
4. Servern skickar ut några tusen  filer på mellan 500kB och 800MB var dag så CTCP hotfix:en har det funderats lite på men pga konstiga SDK och andra saker instalerade så väntas det med denna. Har däremot  hunnit bryta loss och flytta på c:a 30% av denna distibution inklusive dess tempfilskrivningen mot databasdisken ( Skrev en buffrad lösning ej mellanlagrar nått :) )  till andra servrar och de upplever att databasen går bättre nu. Får förhoppningsvis bort större delen av den kvarvarande distributionen nu
5. Databasanropen returnerar mestadels väldigt lite data och det är mestadels läsningar.
6. Minnesmässigt ligger databasen runt det den är tilldelad, men nytt minne är på väg in i maskinen så den borde gå från 6,5GB till runt det dubbla imorgon.
7. Diskbelastningsmässsigt så har Disk Access Queue mot databasdisken legat högt. Nu så ligger average på 6,768 och max på 452,471. Obs, mätningen har skett över korta tidsintervall! Men det ger en fingervisning iaf.
8. .Net-mässigt har databasservern 3.5 installerat och allt verkar vara byggt med det som target. Möjligtvis att någonting någonstans kör 4.0 men det som jag sett som fått felen har hört 3.5.

Kollar man wait stats så ser top 95% ut såhär enligt den ändrarde queryn från MVP Deep Dive Book http://www.mssqltips.com/sqlservertip...

wait_type                     wait_time_s     pct     running_pct
CXPACKET                     7515.42         63.93     63.93
WRITELOG                     2011.41         17.11     81.04
PAGEIOLATCH_SH             880.11          7.49     88.53
LCK_M_IX                        294.84          2.51     91.04
EXECSYNC                       256.38          2.18     93.22
SOS_SCHEDULER_YIELD     201.02          1.71     94.93
IO_COMPLETION               198.53          1.69     96.62

CXPACKET tyder ju på nått jox i kombinationen flera processorer/diskaccess/minnesproblem.
WRITELOG tyder ju på diskaccessen.
Om jag får dra mina egna slutsatser iaf :).

Så än så länge jag lägger jag tid på följande i fallande prioriteringsordning
1. Flytta bort allt annat som jobbar mot databasdisken och få ned avg disk access queue length.
2. Tilldela mssql mera minne.

Har även kollat igenom top(20) mest använda SPs och inte hittat mycket att optimera indexmässigt. Däremot så finns viss fragmenterig på index. Så reorganize/rebuild någon gång vid låg belastning ska läggas upp idag.

Nu ska jag stressa vidare med dagens uppgifter.

 /Martin

Hej,

Kom på att jag nog borde updaterat lite om hur det gått och ber om ursäkt att dröjt så länge.

Med flytt av delar av tempareorna som låg på DBdiskarna, minnesuppgradering och lite riktade insatser i SQL:en (skriva om delar av top-20 prestandakrävande frågor och se över deras indexering) så försvann problemen.

Naturligtvis finns en hel drös vidare åtgärder man skulle vilja göra, men de hamnar som vanligt i att göra-listan.

/Mvh Martin