SQL Server – IO rekord eller hall of shame?

Våra konsulter hjälper ofta våra kunder med SQL server prestanda relaterade problem. Det är inte ovanligt att flaskhalsen beror på IO problem eftersom hårddisklösningen långsammaste komponenten i en SQL server. Självklart så handlar prestanda problemet då inte bara om att hårdvaran är dålig, utan även på hur man nyttjar hårdvaran! I veckan så hittade en av våra SQL konsulter en SQL fråga som hade i genomsnitt 1 000 000 000 IO operationer. Med tanke på att en hårddisk klarar som max 200 IO /s så kan man ganska snabbt räkna ut att med en hårddisk så skulle den frågan ta 57 dygn att exekvera. Med 100 hårddiskar, givet att det inte finns någon annan flaskhals, så skulle denna fråga ta ca 14h. Att slänga hårdvara på problemet skulle vara både dyrt och onödigt. Om man byter ut hårddiskarna mot SSD som klarar fler IO operationer per sekund så kan självklart tiden för SQL frågan minskas, men det är föga kostnadseffektivt. Även med en RamSan 630 som klarar 1 000 000 IO/s så skulle frågan ta 1000 sekunder givet att det inte uppstår andra flaskhalsar på vägen. Frågan som exekverades var extremt ineffektiv med 15 “correlated subqueries”, vilket innebar att för varje rad i selecten så exekveras 15 underfrågor som är beroende av den yttre frågans resultat.

Utöver detta så saknades ett bra index så att varje underfråga gjorde en index seek + en key lookup för varje träff i index seek. SQL frågan exekveras inte i en Stored procedure utan som AdHoc vilket gör att koden inte går att förbättra förrän någon hittat varifrån denna fråga exekveras. Vad som däremot gick att göra var att lägga på ett index som underfrågorna behövde för att få bort alla key lookups. Denna enkla åtgärd förbättrade prestandan tillräckligt för att falla bort ifrån “Hall of shame”  listan som listar de 10 värsta IO konsumenterna, som I detta fall innebär under 10 000 000 IO.

Slutsats:

– Monitorera er produktionsmiljö för att hitta de sämsta SQL frågorna
– Börja med att åtgärde de SQL satser som tar mest resurser för att snabbast nå resultat
– Säkerställ att tabellerna är indexerade korrekt för er last
– Optimera SQL koden så mycket som går, det går att skriva högeffektiv kod
– Mät prestanda i koden innan de släpps till produktion
– Undvik att tillåta direktaccess till tabeller för slutanvändare, eftersom alla kan skriva SQL kod, men få kan skriva bra SQL kod.

På SQL service har vi konsulter med lång erfarenhet av prestandaoptimering som gärna hjälper er med att identifiera och optimera era databaser. Det är en långsiktigare investering att optimera databasen än att köpa ny hårdvara eftersom det går alltid att ställa relativt enkla frågor som tar alla tillgängliga resurser i en server.