default.aspx

Jag satt och slet mitt hår med symptomen att sql-server slutade svara på frågor var fjärde minut. Problemet varade mellan 20-60 sekunder. Därför vill jag gärna dela med mig av hur det löstes.

Systemet körde på Windows Server Enterprise Edition 2008 R2 x64 med SQL Server Enterprise Edition 2008 R2 x64. Disksystemet var 8st Samsung 100GB SSD SLC. 512MB cache i diskkontroller och 128GB ram. Processorn var två Intel X7550 med åtta kärnor.

Vi flyttade våra databaser från SQL-Server 2005 standard edition x64 med en betydligt äldre hårdvara. Alla mätningar vi gjort (med IOMeter) innan det nya systemet driftsattes pekade på att vi kunde få ut mer än dubbelt så mycket IO, jämfört med det gamla systemet.

När det nya systemet sattes igång såg allt väldigt bra ut. Låg CPU-last, låga köer på disksystemen och inga minnesproblem. Efter ett tag i takt med att det blev mer och mer last såg vi dock en tendens till att systemet hängde sig. Detta blev mer och mer allvarligt eftersom dessa hängningar gjorde att alla frågor köades upp och efter ett tag blev kön så full att databasen inte kunde ta emot fler anrop och därför fick klienterna fel.

Frågor som normalt tog 2-5 ms tog istället 10-15 sekunder.
Jag hade efter uppgraderingen byggt om alla index, uppdaterat statistiken och kompilerat om alla lagrade procedurer.

Jag körde igång flera trace mot databasen för att försöka hitta om problemet låg på någon enskild fråga som inte passade sql-server 2008 lika bra, men jag hittade inga sådana samband. Jag tittade med performance monitor för att se diskköer och se om checkpoints från databasservern kanske var orsaken till hängningarna. Men det visade sig att checkpointsen inte alls kördes samtidigt som hängningarna uppstod.

Jag visste att vi hade de senaste drivrutinerna och vi använde servertillverkarens drivrutiner. På raid-kontrollerkortet var write cache aktiverat.
Innan systemet driftsattes hade vi lagt på senaste CU till sql-server 2008 R2, samt kört windows update. Även SQL-Server Server 2008 best practice analyzer hade vi kört för att verkligen säkerställa att vi konfigurerat allt rätt.

Som start hade jag satt att SQL-Server maximalt fick utnyttja 126GB av de tillgängliga 128GB. Jag provade att sänka detta, så SQL-Server bara fick 96GB tillgängligt, för att säkerställa att det inte var windows som hade för lite resurser. Jag satte även ner max degree of parallelism till 8 för att säkerställa att det inte var enskilda processer som tog mycket CPU. Nu hade visserligen inte mina mätningar på CPU med performance monitor visat detta, men jag ville ändå dubbelkolla.

Jag kontrollerade alla inställningar när det gäller energisparläge. Allt sattes till ”maximum performance” för att säkerställa att systemet skulle leverera så mycket som möjligt.

Jag körde sp_who2 och who is active som tydligt visade att systemet hade problem (när hängningarna skedde), bland annat genom att flera hundra processer fanns i listan, jämfört med bara några få annars. Mellanperioden var det inga som helst problem. Det svåra i felsökningen var att då hängningarna inträffade så visade dessa verktyg att mycket enkla frågor skapade låsningar och deadlocks.

Slutligen visade det sig att det hela rörde sig om en bugg i windows som microsoft ännu inte har valt att släppa ut på windows update.

Buggfixen hittar ni här. Där kan man bland annat läsa ”A computer that is running Windows 7 or Windows Server 2008 R2 becomes unresponsive when you run a large application” och att hotfixen var släppt den 14 april 2010.

Jag kan inte annat än att säga att jag helt klart trodde att windows server 2008 r2 var byggt för just ”large applications”. Det är naturligtvis förödande när man lägger flera hundra tusen på licenser och trots det får man enorma problem. Som dessutom beror på en känd bugg men som de av någon anledning inte valt att lägga ut på windows update.

Jag vill också säga att vi givetvis skapade ett supportärende mot microsoft, men att de inte hade hittat någon lösning innan vi fick hjälp av Jason Massie på msdn-forumen som hade råkat ut för samma sak och därför kunde peka i rätt riktning ganska omgående.

Jag hoppas att detta inlägg kan hjälpa andra som är på väg att gå över till windows server 2008 r2 och där planerar att köra ”större applikationer”.