4 sätt att lösa prestandaproblem i sql-server – del 3

Detta är del 3 av 3 i en serie om att lösa prestandaproblem i sql-server.
Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor.

Perfmon

Förutom profiler och DMV:er är det bra att köra perfmon för att övervaka hur servern mår. Här kan man ofta på hårdvarunivå bättre identifiera var prestandaproblemen ligger.
Jag går igenom ett antal olika räknare (performance counters) och beskriver hur de skall läsas av och vad rimliga värden är.

De räknare som jag tycker är viktiga att övervaka på en sql-server-databas är följande
Memory: Pages/sec
Physical Disk: Avg. Disk Queue Length
Physical Disk: Avg. Disk Sec/Read
Physical Disk: Avg. Disk Sec/Write
Processor: % Processor Time
SQL Server Buffer: Buffer Cache Hit Ratio
SQL Server General: User Connections

Memory: Pages/sec
Denna räknare visar hur mycket som går in eller ut från minne till disk. Du vill att denna räknare skall hålla sig under 20. Om den har ett snittvärde över 20 över en tidsperiod på 5 minuter så behöver du köpa mer minne till servern, alternativt konfigurera om din server och tilldela mer minne via sql-server-konfigurationen. Det är vanligt att man har toppar över 20 och det är helt normalt, det som är viktigt är att snittet inte går över 20.

Physical Disk: Avg. Disk Queue Length
Denna räknare visar hur mycket kö det är mot dina diskar. Denna räknare finns även som läs- respektive skrivvariant som då endast visar hur mycket läs- eller skrivkö det är. De räknarna heter. Physical Disk: Avg. Disk Read Queue Length och Physical Disk: Avg. Disk Write Queue Length. Men de räknarna kan man börja använda först om man ser att man har ett övergripande problem.
De flesta brukar säga att man har diskproblem om räknaren är över 2, men jag tycker nog att man börjar se problem redan när den överstiger 1-1½. Här kommer det också att bli toppar, exempelvis när den gör en checkpoint. För denna räknare gäller även att den i snitt över en tidsperiod på 5 minuter inte skall överstiga 2, alternativt 1-1½ om du väljer att gå på min linje.

Det som är viktigt med denna räknare är dock att den måste beräknas, beroende på hur många diskar du har i ditt system. Om du exempelvis får att snittvärde för avg. disk queue length på ditt system är 7 och du har 10 diskar i ditt system så blir det alltså 7/10=0.7 vilket är mindre än 2 och alltså bör du inte ha några stora diskproblem. Oavsett raid-typ skall du alltid dela på antal diskar i systemet.

Om du vill räkna ut hur många IOs du har per disk skall du använda olika algoritmer beroende på vilken raid-typ.
Raid 0 — I/Os per disk = (reads + writes) / antal diskar
Raid 1 — I/Os per disk = (reads + (2 * writes)) / 2
Raid 5 — I/Os per disk = (reads + (4 * writes)) / antal diskar
Raid 10 — I/Os per disk = (reads + (2 * writes)) / antal diskar

reads får du fram genom räknaren Physical Disk: Avg. Disk Reads/Sec, writes får du fram genom räknaren Physical Disk: Avg. Disk Writes/Sec.

Avg. Disk Sec/Read
Denna räknare talar om hur många sekunder i snitt det tog för disksystemet att returnera data.
Här brukar man säga att
Mindre än 10 ms – mycket bra
Mellan 10 – 20 ms – okej
Mellan 20 – 50 ms – långsamt, kan behöva tillsyn
Större än 50 ms – stora I/O-problem

Avg. Disk Sec/Write
Denna räknare talar om hur många sekunder i snitt det tog för disksystemet att skriva ner data. Här gäller samma avläsningsstrategi som för Avg. Disk Sec/Read.

Processor: % Processor Time
Talar om hur mycket processorlast du har. Processorlasten bör inte överstiga 80%, om den gör det så tyder det på att processorn är överbelastad och att du bör utöka med fler eller snabbare processorer.

SQL Server Buffer: Buffer Cache Hit Ratio
Denna talar om hur ofta sql-server går mot minnet istället för mot disk. I ett OLTP-system vill du att detta värde skall vara över 99% och absolut inte under 90%. Om den är under 90% så bör du köpa mer minne direkt. Om den är under 99% så bör du fundera på om mer ram kan hjälpa till, exempelvis genom att granska fler minnesräknare.

SQL Server General: User Connections
Denna talar om hur många användaranslutningar som finns mot sql-server. Denna bör vara under 255 om du använder standardinställningen på Maximum Worker Threads i sql-server, eftersom den är 255. Om du har fler user connections än 255 bör du öka Maximum Worker Threads till ett värde som är högre än ditt högsta antal user connections. Om user connections är fler än Maximum Worker Threads så kommer sql-server att dela på trådar för varje anslutning vilket kan ge sämre prestanda. Notera dock att beroende på om du kör connection pool så kan många anslutningar ligga vilandes, så många gånger har man kanske fler användaranslutningar än vad sql-server egentligen behöver hantera.

2 kommentarer

  1. […] 15 september 2009 vid 19:53 · Arkiverad under Prestanda, SQL-Server När sajten går långsamt och orsaken är databasen kan man givetvis lösa problemet genom att köpa mer och/eller snabbare hårdvara. Ett billigare och enklare alternativ som man skall prova först är att undersöka om det går att optimera det befintliga på något sätt. Exempelvis genom att skapa eller modifiera index, skriva om lagrade procedurer eller denormalisera tabeller för att få bättre prestanda. I dessa inlägg beskriver jag fyra användbara sätt att identifiera var flaskhalsen finns och därigenom också veta hur problemet bäst skall lösas. Jag har valt att dela upp inlägget i tre delar, de andra delarna publiceras de närmsta dagarna. Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor. […]

  2. […] 17 september 2009 vid 07:36 · Arkiverad under Prestanda, SQL-Server Detta är del 2 av 3 i en serie om att lösa prestandaproblem i sql-server. Del 1 går igenom hur man letar upp prestandaproblem med profiler, del 2 går igenom DMV och del 3 går igenom performance monitor. […]

RSS feed for comments on this post

Kommentarer inaktiverade.

%d bloggare gillar detta: