Linux procfs för administratörer: en översikt över viktiga filer

Das Linux procfs visar kärnans aktuella tillstånd via virtuella filer under /proc. För systemadministrationen är framför allt belastning, minne, processer, fildeskriptorer och blockenheter relevanta. Det är viktigt att förstå sammanhanget: vissa värden är ögonblicksbilder, andra är räknare som har ackumulerats sedan uppstarten eller glidande medelvärden. Titta därför aldrig bara på ett enskilt värde, utan jämför det med lämpliga signaler och sammanhanget för värddatorn, den virtuella maskinen eller containern.

Att förstå procfs: virtuell kärnvy istället för datalagring

Das procfs är ett virtuellt filsystem: Posterna under /proc återger datastrukturer och tillstånd hos den aktiva Linux-kärnan. De finns inte som permanent lagrat innehåll på ett lagringsmedium. Vid läsning genererar kärnan den aktuella vyn utifrån sitt nuvarande tillstånd; efter en omstart börjar till exempel många räknare om från början. Därför är /proc ett gränssnitt för övervakning och delvis styrning, inte en plats för egna filer eller beständiga konfigurationer.

När det gäller administrationen bör man skilja mellan tre områden. Globala statusfiler som /proc/meminfo, /proc/stat eller /proc/loadavg tillhandahåller nyckeltal för hela kärnan. Kataloger med numeriska namn, till exempel /proc/1234, ger detaljer om en enskild process. Under /proc/sys finns däremot kärnparametrar som, beroende på behörighet och parameter, kan vara både läsbara och skrivbara. Den liknande filstrukturen får inte dölja det faktum att statusavfrågningar och konfigurationsändringar har helt olika konsekvenser.

Vilka sökvägar och fält som finns tillgängliga varierar mellan olika Linux-system. Kärnversionen och -konfigurationen, arkitekturen, den identifierade hårdvaran samt de laddade modulerna påverkar vilka poster som visas. Även namnutrymmen förändrar enskilda vyer. Ett procfs som är kopplat till ett PID-namnområde begränsar särskilt process- och PID-vyn; detta innebär dock inte att globala filer automatiskt visar container- eller cgroup-specifika värden. Skript bör kontrollera filer och fält innan de utvärderar deras innehåll, istället för att förutsätta en fullständig procfs-struktur som är densamma överallt.

Detta ska skiljas från sysfs under /sys: Det visar främst enheter, drivrutiner och hårdvaruobjekt. cgroup2 är dessutom relevant för resursfördelning och gruppgränser. procfs förblir dock den direkta källan till många kärn- och processstatusar som behövs vid en första diagnostik.

Att sätta in mätvärden, ögonblicksbilder och synlighet i rätt sammanhang

Värdet i sig förklarar sällan ett problem i procfs. Först måste dess tidsreferens klargöras: Vissa uppgifter är kumulativa räknare sedan systemstart, andra beskriver ett aktuellt tillstånd, medan ytterligare andra avbildar glidande tidsfönster. Ett högt räknarvärde visar inledningsvis endast att en händelse har ackumulerats sedan uppstarten. En hastighet uppstår först utifrån två mätpunkter: skillnaden mellan värdena dividerat med tidsintervallet däremellan. Detta gäller till exempel för många CPU-, avbrotts- och datamedieräknare.

Filen /proc/uptime visar den totala drifttiden och den sammanlagda vilotiden. Den hjälper till att placera räknarna i tidsmässigt sammanhang sedan uppstarten, men ersätter inte en mätsekvens. En engångskonsultation är en ögonblicksbild; för tillförlitliga slutsatser om trender, toppar eller återkommande belastning krävs upprepade konsultationer med tidsstämpel. Värdena kan förändras redan under avläsningen, eftersom kärnan fortsätter att arbeta.

Även de synliga uppgifterna har sina begränsningar. /proc/self pekar alltid på den process som just nu löser sökvägen. Detta gör den praktisk för skript och interaktiva kontroller utan att behöva anta ett PID. Åtkomsten till andra processers kataloger kan dock begränsas genom filrättigheter, Linux-capabilities och procfs-mount-alternativet hidepid kan vara begränsad. Att vissa uppgifter inte är tillgängliga beror i detta fall inte på att procfs är defekt, utan är ett skydd mot att känslig processinformation läses ut.

Särskild försiktighet krävs i containrar. Ett procfs som är knutet till ett PID-namnområde visar, vid processrelaterade sökvägar, endast processerna i detta namnområdesperspektiv. Globala kärnfiler som /proc/meminfo, /proc/stat eller /proc/diskstats kan däremot fortfarande återspegla värden från värddatorn och begränsas inte automatiskt till containergränsen. Innan varje diagnos måste man därför klargöra om frågan gäller processer, globala kärnvärden eller de faktiskt tilldelade resurserna; gränser och användning av en container ingår dessutom i cgroup2-analysen.

Läsa, konfigurera och säkra under /proc/sys

Området /proc/sys är filsystemvyn för sysctl-gränssnittet. Att läsa av ett värde används för diagnostik. Skrivåtkomst förändrar däremot omedelbart beteendet hos den aktiva kärnan och kan påverka tjänster, resursförbrukning eller säkerhetsfunktioner. Att en ändring träder i kraft utan omstart innebär inte att den är riskfri eller automatiskt permanent: varaktigheten beror på den valda systemkonfigurationen.

Katalogstrukturen underlättar den första översikten. Under /proc/sys/fs finns bland annat globala parametrar för filsystemet och filhanteringen. /proc/sys/vm samlar inställningar för minneshanteringen, medan /proc/sys/net innehåller nätverksrelaterade parametrar. Vilka underkataloger och nycklar som finns tillgängliga beror i sin tur på kärnkonfigurationen och systemets funktioner. En befintlig parameter är därför inte ett allmängiltigt recept för optimering; dess dokumentation och den konkreta arbetsbelastningen är avgörande.

Ett motexempel på en skenbar optimering är drop_caches under /proc/sys/vm. I kärndokumentationen klassificeras funktionen som avsedd för felsökning och testning, och man avråder från användning utanför dessa syften, eftersom tömning av återanvändbara cacher kan påverka prestandan negativt. Lite ledigt minne är i sig inte någon anledning att tömma cacher: Kärnan använder medvetet RAM även för filcache.

Innan varje ändring bör det finnas en tydlig orsak. Spara först utgångsvärdet, dokumentera syftet och förväntade bieffekter, gör ändringen på ett kontrollerat sätt och observera därefter relevanta mätvärden samt systemets beteende. Planera återställningen i förväg och inför ett värde i en permanent konfiguration först efter en teknisk granskning. Mer ingående grundläggande information om parametrar och deras kontrollerade hantering behandlas i artikeln Kernel tuning i Linux-hosting: Sysctl-parametrar i överblick.

De viktigaste procfs-filerna efter administrationsuppgift

Valet av en procfs-fil bör utgå från administrativa överväganden, inte från strävan efter en så fullständig kataloglista som möjligt. Globala filer innehåller ofta värden som gäller för hela kärnan, processvägar beskriver en enskild synlig process och poster under /proc/sys/fs innehåller konfigurationsinformation och systemomfattande gränsvärden. Vissa värden är aktuella tillstånd, andra är räknare som ackumulerats sedan uppstarten eller glidande medelvärden. Denna distinktion avgör om en enda avläsning räcker eller om två mätpunkter krävs.

Tabellen är en utgångspunkt, inte en diagnoskedja. Ett avvikande värde kräver alltid en oberoende verifiering: belastning med CPU- och I/O-data, minnesvärden med Pressure Stall Information och processvariabler med tjänstens beteende. Särskilt /proc/diskstats och /proc/stat är kumulativa räknare; skillnaden över ett känt intervall ger en bättre bild av trender än det absoluta värdet. I containrar måste man dessutom kontrollera om en fil tillhandahåller globala kärnvärden eller en vy som är tillgänglig per cgroup. I de följande avsnitten är signalerna därför indelade efter belastning, minne, processer och I/O.

Belastning, CPU och minne: Utvärdering av kombinerade signaler

Om systemet är långsamt är /proc/loadavg en bra utgångspunkt, men det ger ingen fullständig bild av CPU:ns belastning. De tre värdena visar den genomsnittliga belastningen under de senaste 1, 5 och 15 minuterna. I belastningen ingår inte bara körbara enheter i tillståndet R, utan även uppgifter i det oavbrytbara väntetillståndet D, till exempel vid I/O. Det fjärde fältet visar de enheter som för närvarande kan köras i förhållande till alla befintliga schemaläggningsenheter. Hög Genomsnittlig belastning kan därför tyda på konkurrens om CPU-resurser, blockerade I/O-åtkomster eller båda.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

CPU-raderna i /proc/stat innehåller tidsandelar sedan systemstart i USER_HZ. För att beräkna belastningsandelar utifrån detta måste två avläsningar jämföras; en enskild avläsning visar endast ackumulerad tid. Värdet iowait är dock inte ett direkt mått på latens för lagringsenheter: beräkningen av detta värde har dokumenterade begränsningar och kan under vissa omständigheter till och med minska. För att identifiera en I/O-orsak är det därför lämpligt att även använda enhetsvärden och I/O-PSI.

Även ett lågt värde för MemFree innebär inte nödvändigtvis att det råder brist på RAM-minne. Linux använder ledigt minne specifikt för cache. MemAvailable uppskattar hur mycket minne nya applikationer förväntas kunna tilldelas utan att swap-minnet behöver användas, och är oftast mer användbart för en första bedömning. Först när MemAvailable börjar bli knappt och minnesstopp samtidigt uppstår blir tecknen på minnesutskrift. I en container kan dessa globala lagringsvärden dock härröra från värddatorn; för garanterade eller begränsade resurser är dessutom cgroup2-vyn avgörande.

Filerna under /proc/pressure kompletterar denna bild. För memory och io betyder ”some” att åtminstone vissa uppgifter inte kunde fortsätta under en del av tidsfönstret; ”full” står där för ett tillstånd där alla uppgifter som inte var inaktiva var blockerade samtidigt. Värdena avg10, avg60 och avg300 avser 10, 60 respektive 300 sekunder, medan ”total” är en kumulerad stall-räknare. För CPU är ”full” på systemnivå inte semantiskt definierat och matas ut som noll sedan Linux 5.13 av kompatibilitetsskäl; det ska därför inte tolkas som ett diagnostiskt värde på systemnivå. CPU-, memory- och io-PSI besvarar olika frågor och bör inte användas i stället för varandra.

Om en tjänst reagerar långsamt när MemFree är lågt, bör du först kontrollera MemAvailable och /proc/pressure/memory. Om båda ser normala ut talar det emot en akut systemomfattande minnesbelastning. Därefter kan /proc//status visa om den berörda processen till exempel har ett högt VmRSS-värde, många trådar eller ett onormalt tillstånd. Denna kombination skiljer en cacheintensiv men normal minnesanvändning från ett problem som kräver ytterligare processanalys.

Undersöka processer, filbeskrivare och lagringsenhets-I/O

För en säker övning med en garanterat existerande process står $$ för PID-numret för den aktuella shellen. Statusfilen är mer läsbar för människor än den fältorienterade stat-filen. Name identifierar processen, State dess tillstånd, PPid föräldraprocessen och Threads antalet trådar. VmRSS är en snabb approximation för resident minne, vars RSS-redovisning sker skalbart och asynkront och därför kan vara felaktig; VmSize beskriver däremot det virtuella adressutrymmet. FDSize beskriver storleken på deskriptortabellen, inte nödvändigtvis antalet för närvarande öppna poster. Frivilliga och ofrivilliga kontextbyten kan hjälpa till vid klassificeringen av schemaläggningsbeteendet, men är i sig inte ett bevis på fel.

cat /proc/$$/status
ls -l /proc/$$/fd

Katalogen fd innehåller symboliska länkar till öppna filer, pipor, enheter eller socklar. Den kan till exempel hjälpa till att hitta en process som fortfarande håller en raderad loggfil öppen. Ett stort antal öppna filbeskrivare är dock helt normalt hos proxyservrar, databaser eller händelsebaserade servrar. För filtrerade vyer och tilldelning över flera processer är Använd lsof för att analysera öppna filer ett lämpligt komplement. Kommandorader från cmdline kan avslöja konfidentiella argument; environ är ännu mer känsligt på grund av eventuella inloggningsuppgifter eller token och bör därför inte användas rutinmässigt.

maps listar virtuella minnesområden med behörigheter, offset, enhet, inode och, i förekommande fall, sökväg. smaps kompletterar varje mappning med detaljerade minnesvärden och ger en mer exakt, men mer resurskrävande, ögonblicksbild jämfört med RSS-uppgifterna. Båda filerna är avsedda för fördjupade minnesanalyser: deras utdata kan vara omfattande, och tolkningen av enskilda mappningar kräver sammanhang. För en första översikt är status samt de systemomfattande minnes- och PSI-filerna oftast mer effektiva.

Vid hög belastning och låg CPU-användning utökar /proc/diskstats diagnostiken till enhetsnivå. Filen för kumulativa I/O-statistikuppgifter per blockenhet. För att utvärdera aktiviteten som en hastighet måste två tidpunkter jämföras. Vid detta tillfälle måste fysiska enheter, partitioner och virtuella enheter eller Device Mapper-enheter tydligt särskiljas; räknare på olika nivåer får inte summeras utan vidare. En processens öppna filbeskrivare kan inte direkt kopplas till en diskstats-enhetsräknare: filsystem, cache och mappningslager ligger emellan. Tillsammans med /proc/pressure/io går det dock att kontrollera om observerbara I/O-stopp och enhetsaktivitet sammanfaller tidsmässigt.

procfs i drift: avfrågningar, övervakning och dataskydd

För reproducerbara driftsdiagnoser behandlar du procfs-frågor som mätpunkter: Du noterar tidsstämpel, systemkontext och den specifika frågan. Många värden är ackumulerade räknare sedan start; först när skillnaden mellan två värden divideras med tidsintervallet får man fram en hastighet. Detta gäller till exempel räknare från /proc/diskstats. En enskild mätning kan därför påvisa aktivitet, men varken genomströmningen eller en varaktig försämring kan kvantifieras på ett tillförlitligt sätt.

Ett övervakningssystem bör bland annat vid regelbundna intervall läsa av lagringsvärden från /proc/meminfo, enhetsvärden från /proc/diskstats, registrera process- och systemstatus samt, om kärnstöd finns tillgängligt, utskriftssignaler. Den måste omvandla råvärden till lämpliga enheter, beräkna skillnader för räknare och spara historik. I containrar får det inte likställa globala procfs-värden med arbetsbelastningens resursgränser: processvägar kan vara begränsade till PID-namnrymden, medan minnes- eller enhetsvärden delvis speglar värddatorn. För gränser och utnyttjande av en grupp krävs kompletterande cgroup2-metriker. Endast tidsmässiga förlopp möjliggör tillförlitliga tröskelvärden: Ett högt värde kan vara normalt om det passar in i det förväntade belastningsfönstret; en plötslig ökning jämfört med den egna baslinjen är ofta mer relevant. De tillgängliga procfs-posterna beror på den körande kärnan och dess konfiguration.

Direkta filer och verktyg kompletterar varandra. ps, top eller . htop är lämpliga för den interaktiva processöversikten; free, vmstat, iostat, pidstat, ss och sar Beroende på hur de är konfigurerade bearbetar de data för specifika frågor. procfs är fortfarande ett bra val om du vill granska kärnkällkoden direkt eller skapa ett litet, överskådligt skript. För larmhantering och kapacitetsplanering är tidsseriedata oftast det lämpligare alternativet.

Synlighetsbegränsningar gäller även för läsbara förfrågningar. Åtkomsträttigheter, monteringsalternativ och PID-namnrymder kan dölja processdata eller begränsa dem till en containervy. Omvänt innebär en egen /proc-montering inte att varje global kärndokument endast innehåller data från containern. En saknad processpost eller ett oväntat högt globalt värde är därför i första hand en indikation på att man bör utreda körningsmiljön, monteringsalternativen och cgroup-kontexten.

Diagnosflöden för långsamma tjänster och resursflaskhalsar

Felsökning börjar med ett symptom, inte med ett enskilt värde som man antar är orsaken. Kontrollera därefter minst en oberoende signal och notera om iakttagelsen gäller värddatorn, en virtuell maskin eller en container. På så sätt undviker du till exempel att förhastat tolka en hög belastning som ett CPU-problem eller ett stort antal öppna deskriptorer som ett läckage. Följande steg utgör inledande läsdiagnoser och ersätter inte applikationsspecifika loggar.

Vid hög belastningsgenomsnitt bör du först kontrollera om det är pågående eller väntande uppgifter som driver upp siffran. Belastningsvärdena visar genomsnitt över en, fem och 15 minuter och tar hänsyn till både R- och D-tillstånd. Jämför därför CPU-tidsfält endast med försiktighet med I/O-belastning och enhetsaktivitet. I synnerhet iowait får inte tolkas isolerat som lagringslatens.

Vid långsam användning och lågt MemFree-värde är MemAvailable det bästa första kontextvärdet. Lägg till minnes-PSI och status för den berörda processen, till exempel dess VmRSS, antal trådar och tillstånd. PSI skiljer mellan följande när det gäller minne och I/O: some för delvis blockerade uppgifter och full för fullständig blockering av icke-idler-uppgifter. Om PSI-filer saknas kan detta bero på kärnkonfigurationen eller miljön; det utesluter inte att det rör sig om en flaskhals.

För fil- och processdiagnostik kan behörigheter och PID-namnrymder begränsar informationens värde. I containrar beskriver /proc ofta endast den tilldelade processvärlden. Vid nekad åtkomst eller ofullständiga kataloger bör du därför kontrollera användarrättigheter, procfs-monteringsalternativ och namnområdets sammanhang innan du drar en teknisk slutsats utifrån avsaknaden av data.

Rätta till vanliga missuppfattningar och välj lämpliga verktyg

Fyra vanliga missuppfattningar leder ofta till felaktiga åtgärder vid Linux-administration. Lite MemFree betyder inte automatiskt RAM-brist, eftersom kärnan bland annat använder minnet som cache; för nya applikationer är MemAvailable en mer meningsfull uppskattning. Hög belastning är inte ett bevis på CPU-mättnad, eftersom även uppgifter som väntar utan avbrott räknas in. En hög andel iowait mäter inte en datalagringsenhets direkta latens. Och procfs är inte identiskt överallt: kärnversionen, konfigurationen, hårdvaran, modulerna och namnutrymmena påverkar filer och fält.

Välj metod utifrån frågan. För en punktvis orsaksanalys ger procfs Direkta rådata från den aktiva kärnan. För en snabb, läsbar översikt är specialiserade kommandoradsverktyg oftast effektivare. När trender, larm eller kapacitetsbeslut är avgörande behöver du en övervakning som ordnar mätpunkterna i tidsordning, beräknar skillnader i mätvärden och lagrar historiska jämförelsevärden. Vid resursbegränsningar för enskilda tjänster eller containrar kompletterar en analys på cgroup-nivå den globala värdöversikten; PSI kan, vid lämplig konfiguration, även vara tillgängligt per cgroup.

Särskild återhållsamhet gäller för /proc/sys. Att läsa av en parameter är en diagnostisk åtgärd, medan att skriva till den förändrar kärnans aktiva beteende. Ändra endast ett värde om orsaken är klarlagd, utgångsvärdet har dokumenterats, effekterna kan observeras och det finns en återgångsväg. Katalogerna fs, vm och net ordnar parametrarna efter tema, men ger inga universella inställningsriktlinjer.

Exemplet drop_caches visar skillnaden mellan ingrepp och optimering: I kernel-dokumentationen beskrivs gränssnittet som icke-destruktivt, men man varnar för prestandaproblem och rekommenderar inte att det används som en rutinmässig driftsåtgärd utanför test- eller felsökningsscenarier. En försiktig regel är därför: Mät först, gör sedan en välgrundad och begränsad ändring, observera effekter och biverkningar och dokumentera beslutet.