Database hos kunde går kjempe tregt.

[HDSoftware]

​Heisan..

Vi har et WEB system som kjører på en IIS server.  Som db bruker vi MSSQL 2014

 

​Vi har en kunde som klager veldig på tregheter og vi har gjort noen tester på forskjellige spørringer som vi vet er komplekse og før store differanser.  Hos kunde kjører spørringen på ca 8000ms.  Når vi kopierer hele databasen over til vår egen server så går det 1500ms.

 

​test spørringen kjøres rett i Management studio på serveren slik at det er ingen innblanding av IIS serveren og slikt.

 

Ok.  La oss anta at testen er gjort på to maskiner som burde respondere likt, hvilke andre ting kan gjøre en slik forskjell.

 

Jeg spør på denne måten fordi folkene som har gjort testene med stor sannsynlighet vet hva de driver med og jeg går derfor ut ifra at testene er gjort utenfor arbeidstid og slikt ting..

 

Vi vurderer å gå til innkjøp av en server som vi kan sette opp hos oss for så å dokumentere at denne oppfører seg riktig, for så å flytte den inn hos kunden og så se hva som skjer, men vill høre først om noen av dere der ute vet at "vi burde trykket på den knappen" først

 

[Drogin]

Serverne deres er like? Tenker da spesielt på harddiskene(men også CPU og minne)?
Ikke rart om det er forskjell på ytelse om dere kjører på SSD, og det i prod er HDD.

Eller om dere kjører HDD, og i prod ligger databasen på et SAN.

 

Eller om dere kjører en fysisk host, og prod er på en VM

Endret 26. september 2016 av Drogin

[Drogin]

Jeg ville også sjekket ut denne:
https://msdn.microsoft.com/en-us/library/ms189858.aspx

 

Dere kan be om en analyse av fragmenteringen på indexene i prod(se "Detecting Fragmentation"). Det kan være årsaken.

Endret 26. september 2016 av Drogin

[HDSoftware]

Ja, skjønner at dette kan skape differanser.

Maskinvaren til kunde er SSD disker.  Litt usikker på om disse ligger i et SAN, men det vil jeg annta.  Når dette er løftet over på "våre" test maskiner så er dette omtrendt den samme konfigurasjonen.  Begge tester er gjort i en VM.  Vi har også kjørt testene rett på jærnet og da blir resultatet, som forventet, en god del bedre enn 1500ms.  Da havnet vi net på ett sted rett under 1000ms.  Jeg så ingen grunn til å nevne dette for det ville være openbart.  Men jeg er selvsagt enig med deg, konfigurasjon er alfa og omega, men jeg vill høre om noen hadde non annen erfaring som vi muligens burde ha testet

[HDSoftware]

Jeg ville også sjekket ut denne:

https://msdn.microsoft.com/en-us/library/ms189858.aspx

 

Dere kan be om en analyse av fragmenteringen på indexene i prod(se "Detecting Fragmentation"). Det kan være årsaken.

 

Ja, denne skal jeg ta med meg videre, men mener i hvert fall at de kjører indeksering nå og da.  Dessverre kjenner jeg ikke dette system veldig godt, men jeg har sett et par av scriptene som kjører der og de er lange og tunge.  Vet jo at det ikke skal rare join treet til før en spørring tar votter og vinter, men jeg syntes det var så stor forskjell på resultatene her i forhold til hardware at jeg måtte spørre..

[quantum]

 Når dette er løftet over på "våre" test maskiner så er dette omtrendt den samme konfigurasjonen. 

 

 

Hvordan gjør dere dette? Antar indekser blir bevart, men er jo greit å få bekrefta for å få eliminert at det er problemet. 

 

Vet ikke hvordan det er med MS SQL, men mange andre databaser har diverse housekeepingrutiner som rydder og oppdaterer statistikker som optimizeren bruker osv.  Hvis dette ikke er kjørt vil ting kunne gå treigt. 

[NoBo]

Flaskehalsen kan ligge på mange nivåer. Alt fra 'feil' blokkstørrelse på filsystem hvor db/translogger ligger, bruk av Thin Provisioning på SAN og/eller virtualiseringslaget, feil/dårlig konfigurert vCPU (NUMA, antall etc.) For lite tildelt RAM til VM, feil vNIC brukt i VM(!), manglende/feil konfig av VM-ens OS/SQL Server, installert tredjeparts SW (eks. antivirus.) Hvis SAN kan det være for lite ledig kapasitet (IO, cache, CPU vRAID level, ++) /tregt i forhold til SQL serverens spørring. Hvis VM hosten(e) har iSCSI kobling mot SAN-et og det ikke er konfigurert riktig (switcher, antall porter mellom host og SAN, pakkestørrelse ++) og eller har dårlig kapasitet vil det også spille inn.

Sannsynligvis er ikke alt over relevant for kundens miljø.

 

Som et første steg, prøv deg frem med et verktøy for måling av disk IO, transfer speed (IOMETER, SQLIO etc.) og sammenlign mellom deres server og kundens.

[HDSoftware]

 

 Når dette er løftet over på "våre" test maskiner så er dette omtrendt den samme konfigurasjonen. 

 

 

Hvordan gjør dere dette? Antar indekser blir bevart, men er jo greit å få bekrefta for å få eliminert at det er problemet. 

 

Vet ikke hvordan det er med MS SQL, men mange andre databaser har diverse housekeepingrutiner som rydder og oppdaterer statistikker som optimizeren bruker osv.  Hvis dette ikke er kjørt vil ting kunne gå treigt. 

 

Jeg er litt usikker på hva MSSQL putter i selve Databasen og hva som lagres andre steder, jeg mistenker at folkene som utførte testen bruker et backup sett for å slippe å avmontere noe som er i drift.  Går jo da ut ifra at kun rådataene blir med.  Det ville jo i så fall bety at alt må re indekseres før testing på ekstern host, noe jeg også går ut ifra at ikke blir gjort, men det kan jeg ikke si med sikkerhet. 

 

Takker for innspillet

[HDSoftware]

 

 

 Når dette er løftet over på "våre" test maskiner så er dette omtrendt den samme konfigurasjonen. 

 

 

Hvordan gjør dere dette? Antar indekser blir bevart, men er jo greit å få bekrefta for å få eliminert at det er problemet. 

 

Vet ikke hvordan det er med MS SQL, men mange andre databaser har diverse housekeepingrutiner som rydder og oppdaterer statistikker som optimizeren bruker osv.  Hvis dette ikke er kjørt vil ting kunne gå treigt. 

 

Jeg er litt usikker på hva MSSQL putter i selve Databasen og hva som lagres andre steder, jeg mistenker at folkene som utførte testen bruker et backup sett for å slippe å avmontere noe som er i drift.  Går jo da ut ifra at kun rådataene blir med.  Det ville jo i så fall bety at alt må re indekseres før testing på ekstern host, noe jeg også går ut ifra at ikke blir gjort, men det kan jeg ikke si med sikkerhet. 

 

Takker for innspillet

 

 

Her var det masse å teste på.  Jeg sender dette videre til vår mann i SQL testingen... og ikke minst IT duden hos kunden..

 

Tusen takk for innspill alle sammen

[siDDis]

Selv 1500ms høres mye ut, du har en flaskehals en eller annen plass. Synd at Windows er en helt håpløs plattform å debugge sånne ting.

 

SQL Server har noe som heter explain plan, http://stackoverflow.com/questions/7359702/how-do-i-obtain-a-query-execution-plan#7359705

 

Det er et veldig nytting verktøy for å forstå hvordan databasen din fungerer. Jeg bruker dette ofte for optimalisering av PostgreSQL. På en 6 år gammel PostgreSQL server jeg har stående her med 4 SSD disker så kan jeg kverne 2500MB/s eller 20 millioner rader i sekundet. Nyere hardware skal greie 2x-4x bedre.

Endret 15. oktober 2016 av siDDis