Hoppa till innehåll 
sar sysstat ger mig historiska mätvärden från Linux-servrar, med vilka jag tydligt kan följa belastningsmönster, flaskhalsar och avvikande beteenden över tid. På så sätt analyserar jag CPU, RAM, I/O och nätverk i efterhand och upptäcker återkommande toppar som ett rent realtidsverktyg lätt kan missa.
Centrala punkter
Jag sammanfattar följande huvudpunkter kort och tydligt.
- Historia I stället för en ögonblicksbild: Regelbunden mätning synliggör belastningsmönster.
- Kombination från insamling och analys: sysstat samlar in, sar bearbetar.
- Bredd Mätvärden: CPU, RAM, swap, disk-I/O, nätverk och mer.
- Diagnos Orsaker: Justera tidsfönstren på ett målinriktat sätt och jämför dem.
- Planering med trender: dimensionera kapaciteten på ett realistiskt sätt.
Vad gör sar och sysstat i vardagen?
Jag använder sar som System Activity Reporter, som gör de data som lagras av sysstat läsbara. sysstat samlar regelbundet in värden för CPU, minne, I/O och nätverk, medan jag med sar hämtar rapporter för specifika tidsperioder. På så sätt kan jag utan gissningar identifiera återkommande belastningsperioder orsakade av säkerhetskopieringar, cron-jobb eller trafiktoppar. Till skillnad från Live-verktyg Till skillnad från top eller htop utvärderar jag inte det ögonblickliga tillståndet, utan tar hänsyn till utvecklingen över tid. Detta perspektiv förhindrar feldiagnoser, eftersom det skiljer orsak och verkan åt och ger mig tillförlitliga ledtrådar.
Installation och aktivering på vanliga distributioner
Jag installerar sysstat Via pakethanteraren aktiverar du loggningen och kontrollerar systemd-timern. I Debian/Ubuntu räcker det oftast med apt install sysstat och en titt in i /etc/default/sysstatföljt av systemctl enable --now sysstat. På RHEL/CentOS/Oracle Linux använder jag dnf install sysstat och styr timrarna via systemctl. Därefter sparas dagens filer vanligtvis i /var/log/sa/ med namn som sa10 den 10:e i månaden. Jag kontrollerar uppgifterna med sar utan parametrar eller med sar -u 1 3 för en snabb ad hoc-kontroll.
De viktigaste SAR-anropen förklarade
För CPU använder jag sar -u och vid behov per kärna sar -u -P ALLtill Tips Det går inte att bortse från. När det gäller lagring och caching anser jag att sar -r och swapping med sar -S. Jag avläser plattans aktivitet med sar -d, nätverket med sar -n DEV,ETCP,TCP,UDP. Historiska filer öppnar jag med sar -f /var/log/sa/sa10 och avgränsa tidsfönster med -s TT:MM -e TT:MM . För detaljerade analyser av väntetiderna kompletterar jag sar med Analysera I/O-väntetider, eftersom jag på det sättet bättre kan utvärdera köer och genomströmning och Flaskhalsar identifiera tydligt.
Att tolka mätvärden korrekt: CPU, minne, I/O, nätverk
Jag tittar på ett fåtal nyckeltal som snabbt ger mig en tillförlitlig bild och som jag jämför över tid. CPU-Inaktiv Värden nära 0 och höga %iowait-värden tyder på köer vid hårddisken. Ett högt %steal-värde indikerar CPU-brist vid virtualisering. När det gäller RAM-minnet tittar jag på lediga minnessidor, sidcachebeteende och swap-ins/outs. För nätverket hjälper paketfel, bortfall och återutsändningar till att upptäcka kapacitetsgränser eller störningar.
| Mätetal | sar-omkopplare | Avvikande värden | omedelbar åtgärd |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle mycket låg, %iowait hög | Kontrollera I/O, fördela trådar, verifiera CPU-behovet |
| Minne | sar -r | lite ledigt utrymme, kraftig minskning av sidcachen | Optimera tjänster, utöka RAM-minnet, utvärdera cachelagring |
| Byta | sar -S | frekventa byten in och ut | Avlasta arbetsminnet, justera gränserna |
| Disk I/O | sar -d | Höga await-/svctm-värden, kön växer | Kontrollera I/O-profilen, justera lagringshierarkin eller batchfönstret |
| Nätverk | sar -n DEV,ETCP | Drops, fel, återutsändningar | Testa MTU/avlastning, analysera bandbredd och latens |
Analysera historiska data och tidsintervall
Jag arbetar nästan alltid med Tidsfönster, till exempel sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 för nattjobb. På så sätt jämför jag identiska tidpunkter på olika dagar och kan se trender istället för enstaka fall. För automatisk utvärdering sparar jag data med sadf -d i CSV-format och laddar upp dem till en egen översiktssida. Vid ovanliga toppar tittar jag på angränsande intervall för att utesluta sidoeffekter. Jag håller den här metoden enkel eftersom den ger mig snabbt användbara ledtrådar utan långa förberedelser.
Trendanalys och kapacitetsplanering
Jag använder de arkiverade värdena för Prognoser och dimensionerar resurserna utifrån faktiska mönster istället för magkänsla. Om CPU-utnyttjandet ökar vecka för vecka planerar jag in fler kärnor eller klockfrekvensreserver. Om minnesbehovet ökar på grund av cacher, väger jag fördelarna mot en RAM-utbyggnad. Om I/O-vägen visar på ökade väntetider, beslutar jag om snabbare lagring eller avkopplade batchfönster. För visualisering kopplar jag alternativt data till Grafana och Prometheus och kombinera SAR-trender med mätvärden från exportörer.
Praktiskt exempel: Webbserver med belastningstoppar
Jag ska beskriva ett fall där WordPress-sidorna varje kväll svarar med fördröjning och Användare Rapportera avbrott. Med sar -u -s 18:00:00 -e 20:00:00 och sar -d Jag upptäcker samtidiga I/O-toppar under säkerhetskopieringar. Samtidigt visar sar -n DEV en ökande nätverksgenomströmning, vilket kompletterar belastningsbilden. Kontrollmätningen dagen efter, utan säkerhetskopiering, bekräftar mönstret. Jag flyttar jobbet, optimerar databasfrågorna och rensar cacheminnena, vilket gör att kvällstopparna försvinner och svarstiderna åter blir konstanta.
Tips för datahantering, rotation och arkivering
Jag kontrollerar Förvaring på /etc/sysconfig/sysstat eller . /etc/default/sysstat och ställer in lagringstiden efter behov. För kritiska värdar sparar jag data i 30–90 dagar för att kunna upptäcka säsongsmässiga effekter. Filstorleken förblir hanterbar så länge intervallen är rimliga och ingen överdriven sekunduppdatering är aktiverad. Jag flyttar äldre arkiv till en central katalog eller lägger dem i ett enkelt långtidsarkiv. På så sätt håller jag data tillgängliga utan att belasta systemet eller sakta ner analysen.
Integration med övervakningsstackar och loggar
Jag sätter sar som Rådata-leverantör och kombinerar det med central övervakning, logganalys och larmfunktioner. En APM- eller loggstack förser mig med händelser, medan sar ordnar infrastrukturvärdena i tidsordning. För särskilt ”bullriga” värdar använder jag dessutom pidstat och iostat, för att koppla ihop processer och I/O-vägar. Dessutom hjälper det mig att Processredovisning, att tydligt identifiera resurskrävande processer. Denna kombination av händelse- och mätvärdesperspektiv förhindrar att man går i blindo och förkortar min felsökning avsevärt.
Finjustera inställningarna: Intervall, sa1/sa2 och timer
Jag satte Registreringsintervall så att de passar systemets dynamik. En minutintervall är ett lämpligt standardvärde, medan 10–30 sekunder kan vara lämpligt för mycket volatila värdar. Insamlingen sköts av sa1 (regelbundna stickprov), dagssammanfattningen sa2 (Rapporter om dagen). I systemd kontrollerar jag de aktuella timerna respektive tjänsterna och justerar frekvensen. På Debian/Ubuntu aktiverar jag ofta insamlingen uttryckligen med ENABLED="true" på /etc/default/sysstat. Jag dokumenterar intervallen för varje miljö så att senare jämförelser blir korrekta och så att ingen drar felaktiga slutsatser utifrån 5-sekundersstickprov jämfört med 1-minutsdata.
Översikt över avancerade SAR-alternativ
Förutom de klassiska funktionerna hjälper ytterligare knappar mig att Helbild: sar -b visar den aggregerade block-I/O-genomströmningen, sar -B kärnans sidindelningsbeteende och sar -W Swap-aktiviteten i detalj. Med sar -q ser jag Runqueue (processer som väntar på CPU) och belastningsutvecklingen. sar -H tillhandahåller Hugepage-data när det är relevant. För skivor använder jag vid behov sar -d -p, för att granska partitionerna var för sig. Jag är försiktig med svctm: Detta värde är i vissa fall opålitligt eller lika med 0 i moderna kärnor; jag föredrar att utvärdera invänta (latens från ände till ände) och avgqu-sz/aqu-sz (köstorlek). Och när jag behöver få en snabb överblick, ger sar -A en bred överblick, som jag sedan fördjupar mig i.
Att korrekt utvärdera virtuella maskiner och containrar
På Virtualiseringar Jag lägger särskilt märke till %steal: Höga Steal-värden innebär att hypervisorn tar CPU-tid från den virtuella maskinen. Det kan lätt leda till felbedömningar om jag bara utvärderar %idle. Därför korrelerar jag CPU-utnyttjande, Steal och Runqueue (sar -q) tillsammans. I containermiljöer skiljer jag mellan värd- och arbetsbelastningsperspektivet: sar övervakar värden, inte enskilda containrar. Om jag behöver detaljer per tjänst kompletterar jag med pidstat (per process) och tar hänsyn till cgroups-gränser. Jag kontrollerar dessutom CPU-frekvensskalning och strömlägen (klockfrekvensväxlingar), eftersom de på kort sikt kan orsaka fördröjningar som utan sammanhang kan uppfattas som CPU-brist.
Tidsreferens: tidszoner, sommartid och tillförlitlig korrelation
Jag är uppmärksam på konstant tidsbas, så att jämförelserna stämmer. sar sparar som standard i lokal tid; vid kluster lönar det sig att använda en enhetlig tidszon (ofta UTC). I samband med övergången till sommartid kontrollerar jag om det finns dubbla eller saknade tidsfönster och använder vid behov utdata från sadf med tidsstämplar i ISO-format. För att kunna korrelera med loggar eller APM-händelser justerar jag tidszonerna så att toppar i mätvärdena exakt kan kopplas samman med händelser (distributioner, säkerhetskopieringar, cron-jobb). Tydliga tidsreferenser minskar avsevärt risken för missförstånd vid efteranalyser av incidenter.
Automatisera och exportera med sadf
För rapporter och instrumentpaneler exporterar jag data med sadf. I vardagen använder jag sadf -d (CSV) för enkla utvärderingar, alternativt sadf -j (JSON) för flexibla pipelines. En typisk export ser ut så här: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. På så sätt skapar jag en fil med nyckeltal för CPU, RAM, block-I/O och nätverk för ett kvällsfönster. I skript jämför jag automatiskt veckodagar med dessa värden, beräknar medianvärdet och 95:e percentilen samt markerar avvikande värden. Jag håller medvetet antalet mätvärden begränsat för att bevara läsbarheten och undvika falska larm.
Praktiskt exempel: Databasserver med belastning från sidcache
En MySQL-värd klagar över sporadiska fördröjningar i sökfrågorna. sar -r visar att sidcachen minskar på kvällen, sar -S tillfälliga utbyten. Samtidigt ökar hos sar -d som invänta-tid, och sar -b tyder på ökade skrivflöden. Korrelationen med loggrotationer och ett ETL-jobb förklarar mönstret: Stora sekventiella skrivvågor tränger undan cachen och tvingar databasens läsningar till I/O. Jag sprider ut jobben, ökar RAM-minnet måttligt och ställer in DB-buffertarna så att de blir större på ett målinriktat sätt. Därefter förblir await- och swap-värdena stabila, latenserna minskar och sidcachen håller hotsets tillförlitligt i minnet.
Driftsaspekter: Overhead, utrustningslistor och filter
Jag håller i Overhead liten genom att välja ett proportionellt urval. Sysstat läser främst in från /proc och skriver binärt; vid minutintervall märker jag knappt belastningen. På värddatorer med väldigt många enheter eller kortlivade blockenheter (t.ex. vid snapshots) filtrerar jag utdata selektivt och utvärderar endast relevanta sökvägar. För dm-crypt, MD-RAID eller multipath-enheter kontrollerar jag både den logiska enheten och – där det är möjligt – den underliggande enheten för att korrekt identifiera flaskhalsar. Jag dokumenterar samtidigt enhetsnamnen så att senare jämförelser inte misslyckas på grund av omdöpta sökvägar.
Metodik: Referensvärden och jämförelsedagar
Jag definierar en per värd Baslinje per tidsfönster (t.ex. kl. 01–05: batch, kl. 09–18: kontorstid, kl. 18–22: rusningstid). För varje tidsfönster noterar jag typiska medianvärden och acceptabla percentiler (t.ex. CPU-%idle, invänta, avgqu-sz, vidarebefordringar). Vid avvikelser letar jag först efter nya uppdrag, driftsättningar eller trafikmönster – först därefter överväger jag kapacitetsutökningar. Denna disciplinerade ordningsföljd förhindrar förhastade beslut: ofta löser en liten planändring eller en justering av gränsvärdena mer än en kostsam utökning av hårdvaran. sar ger mig den tillförlitliga faktagrunden för detta över veckor och månader.
Gränser och nyttjanderättstillägg
Jag ser inte sar som en ersättning för Varning, eftersom det som standard varken övervakar tröskelvärden eller skickar ut aviseringar. Realtidsvarningar hör hemma i specialiserade system som hanterar regler, eskaleringar och arbetsflöden inom teamen. Även djupgående mätvärden för applikationer, databaser eller JVM:er täcker jag via exportverktyg och spårning. sar kommer till sin rätt när jag vill jämföra systemresurser historiskt och spåra flaskhalsar i driften. Sammanfattningsvis använder jag det målmedvetet där snabba, repeterbara svar på infrastrukturfrågor efterfrågas.
Kortfattat sammanfattat
Jag använder sar och sysstat, för att utifrån mätvärden skapa en överskådlig bild av serverbelastningen. Kombinationen av regelbunden datainsamling och målinriktad återblick klargör orsakerna, istället för att gissa på symptomen. Med några få kommandon upptäcker jag problem med CPU, minne, I/O och nätverk och kan tidsbestämma dem. Utifrån detta fattar jag realistiska beslut om kapacitet och identifierar ineffektiva rutiner, såsom felaktigt tidsinställda säkerhetskopieringar. Den som ansvarar för Linux-servrar får med denna metod en pålitlig vägledning och sparar tid vid analys, planering och drift.
