Prestandaövervakning och felsökning

En simpel introduktion till prestandaövervakning och felsökning av Linux-system.

Varför?

För att kunna identifiera avvikelser från normal drift måste en administratör känna till serverns normaltillstånd; Hur mycket belastas CPUn under normal drift? Hur mycket minne används? Hur ser I/O ut?

Med normaltillståndet som utgångspunkt kan problem identifieras, flaskhalsar undanröjas och framtida uppgraderingar planeras för i god tid.

Vad?

Processor (CPU)

Viktiga parametrar att förstå är kontextbyten, jobbkö, utnyttjandegrad samt genomsnittlig last.

Kontextbyten sker när processorn byter från att jobba med en process eller tråd till en annan. Varje gång det sker sparar processorn den aktuella processens tillstånd till minnet och läser den nya processens tillstånd från minnet. Kontextbyten är grundläggande för multikörning (multitasking) och spelar således en stor roll i hur väl ett system presterar.

Jobbkön hanterar aktiva processer som finns i kön för att köras i en processor. När processorn är redo plockas en process från kön baserat på prioritet. Processer som sover (sleep state) eller väntar på skrivning/läsning (I/O wait state) finns inte i jobbkön. Alltför många processer i jobbkön kan orsaka prestandaproblem.

Utnyttjandegraden är ett mått på hur väl en processor utnyttjas, dvs många procent av dess fulla kapacitet som används.

Genomsnittlig belastning anger utnyttjandegraden över tid. I Linux, och de flesta unix-lika system, är detta angivet med tre olika perioder: 1, 5 och 15 minuter. Genom att jämföra dessa kan administratören avgöra om belastningen ökar, minskar eller är kontinuerlig. Belastningen räknas ut från det totala antalet processer i jobbkön och det totala antalet icke avbrytbara (uninterruptable) uppgifter.

Minne (RAM)

Minne, eller RAM, avser det fysiska minnet i en dator. Det "virtuella minnet" avser däremot både det fysiska minnet, RAM, samt det s.k swap-minnet som är en avlastnings area där sällan använd data kan skrivas ner från fysiska minnet för att ge plats åt mer frekvent använd data. I det virtuella minnet räknas kärnans (kernel space) och användar-delens (user space) minne in.

Om hårdvaran stödjer 32-bitar eller 64-bitar avgör hur mycket minne en process kan adressera och utnyttja. Ett 32-bitars system kan maximalt utnyttja 4GB virtuellt minne. På ett 64-bitars system finns ingen sådan praktisk begränsning (då 264 bytes, dvs mer än 18 triljoner bytes kan adresseras).

Kärnan använder outnyttjat minne som filsystemscache. Minnessidor (memory pages) som sällan används skrivs till disk i swap-minnet för att ge plats åt mer frekvent nyttjade minnessidor, det kallas för att systemet "swappar". Mycket swapping påverkar systemet negativt eftersom disk, sekundärt minne, är betydligt mycket långsammare än RAM. Ett illa lastat system kan således tillbringa mer tid att läsa från och vänta på skrivning till disk än att göra någonting meningsfullt.

Skrivning/Läsning (I/O)

I/O-väntan (I/O wait) är den tid processorn tillbringar med att vänta på diskaktivitet. Konstant hög I/O-väntan är en klar indikation på att systemet lider av en långsam disk.

Läsningar per sekund och skrivningar per sekund mäts i antalet block per sekund och betecknas "bi" eller "blk_read" (blocks in eller block_read) för läsning och "bo" eller "blk_wrtn" (blocks out eller block_written) för skrivning.

Transaktioner per sekund (tps) är en summering av läs- och skriv-transaktioner per sekund (rtps respektive wrtps)

Nätverk

Goda kunskaper om TCP/IP underlättar vid analys och felsökning vad beträffar nätverksrelaterade problem. Förslag på verktyg för analys av nätverkstrafik finns under rubriken "Sen då?".

Inkommand och utgående paket för varje nätverkskort, fysiskt och virtuellt, på systemet bör övervakas för att tidigt upptäcka nätverks- och/eller kapacitets- problem.

Hur?

Processor, minne, disk och nätverk påverkar varandra. Det är viktigt att se till ett system som en helhet. Många transaktioner eller hög I/O-väntan behöver inte indikera att problemet är nätverket eller disken. Det kan exempelvis indikera på problem i hur en enskild applikation beter sig. 80% av prestandaproblem beror på applikationsproblem och resterande 20% på infrastrukturen.

De flesta problem löser sig själva så snart man verkligen förstår det. Begränsa och definera problemet tydligt. Spendera tid på att verkligen förstå problemet och vilka parametrar som är involverade. Se om du kan reproducera problemet: framkalla det på egen hand. Det hjälper dig både att förstå problemet, finna en lösning och att sedan verifera att din lösning verkligen åtgärdar problemet istället för att bara justera symptomen.

Samla in och kontrollera mätvärden. Vad skiljer sig från normal produktions belastning? Desto mer mätvärden du har att jämföra desto lättare kan du ringa in och åtgärda problemet.

Eliminera ovidkommande parametrar. Detta förenklar felsökningen och undviker felaktiga slutsatser. Detta är en iterativ process där en parameter i taget elimineras och verifieras. Fortsätt denna process tills du finner den felande parametern.

Ändra bara en sak i taget. På så vis kan du vara säker på vilken åtgärd som löser problemet, förstå varför och förhindra att problemet återkommer. Genom att ta ett steg i taget undviker du också att skapa nya, ovidkommande, problem som stjäl energi och fokus från det ursprungliga problemet.

Verktyg

Notera att du som administratör måste förstå vad resultatet från dessa verktyg betyder och vad det innebär för systemet som helhet. Att bara köra ett gäng kommandon utan att förstå vad de berättar för dig är meningslöst.

Dessa måste behärskas av en administratör:
  • ps
  • top
  • free
  • iostat
  • netstat

Följande bör behärskas av en administratör:
  • sysstat (sad, sar)
  • vmstat
  • mpstat
  • tcpdump
  • netcat

Sen då?

Nästa steg är att övervaka individuella tjänster och införa larmfunktioner, incidentrapportering och rutiner. Analysera nätverkstrafik och applikationers beteenden.

Referenser