Navnet er litt unikt for noe som viser system statistikk: toppen. Det er en del av procps pakken, et sett med Linux verktøy som gir systeminformasjon. Foruten topp, procps også inkluderer fri, vmstat, ps, og mange andre verktøy.

Top gir deg et øyeblikksbilde av et system situasjon, for eksempel gratis fysisk minne, antall kjørende oppgaver, prosent av CPU-tiden bruken av hver prosesser - alt i én visning. Så det er som bruker ps, gratis, og oppetid på samme tid. Top får det meste av sin informasjon fra flere filer under /proc katalogen. Du kan allerede være klar over at denne katalogen gir brukere med et bredt spekter av systemomfattende statistikk, men takket være topp, kan vi oppsummere de fleste av dem i én organisert vindu.

Videre med toppen kan du gjøre ting som:

Sorter prosesser basert på CPU-tid-bruk, minnebruk, total kjøretid, etc.

Bytte til multi visningsmodus. I denne modusen, får du opp til fire vinduer og hvert vindu kan tildeles ulike innstillinger (sortering, fargestoffer, vises felt)

Send et signal ved å nevne målet prosessens PID og signalet nummeret.

Hvis du vil vite hvordan du bruker toppen mer effektivt, kan du se denne artikkelen.

Men er toppen ikke det ideelle verktøy for å samle system statistikk i lange intervaller, sier en uke eller en måned. SADC (systemaktiviteten data collector) er et bedre verktøy for denne type intervall. SADC genererer en logg som inneholder system statistikk og bruker sar å generere rapport og sammendrag basert på denne loggen. Noen mennesker bruker topp i batch-modus som et alternativ, men det er ikke så effektiv som SADC fordi:

SADC poster dataene i binært format, og dermed krever mindre plass

i henhold til personlig eksperiment, ved å bruke "time" kommandoen, SADC arbeider raskere enn topp derfor selve verktøyet ikke innføre stor overhead

Det er nok til å gjeninnføre toppen. La oss begynne med å forstå betydningen av hver del av toppen er "dashbordet". Også i denne artikkelen, er det viktig å være oppmerksom på betydningen av "høy" eller "lav". Det er ingen absolutt terskel til nettopp merke en rekke høy eller lav. Jeg pleier å bruke høy eller lav etiketten hvis statistikken er høyere eller lavere i forhold til det gjennomsnittlige antallet du vanligvis ser i relaterte felt.

Prosessor statistikker

På den øverste linjen, vist i figur 1, er det (fra venstre til høyre): nåværende tidspunkt (time: minutt: sekund), oppetid (time: minutt), antall aktive bruker-ID, og ​​last gjennomsnittet.

De to første er selvforklarende. Hva med antall aktive bruker-ID? Man skulle tro det er antall tiden innloggede brukere, enten interaktivt eller ikke (via ssh, for eksempel). Ikke akkurat. Det teller også antall pseudo-terminaler gytt under visse bruker ID-privilegier. La oss si at du har logget inn i GNOME som "Joe" og deretter kan gyte to xterm vinduer, så det teller du som tre brukere. Top inkrementerer tallet med én å rede eksistensen av init prosessen.

Load gjennomsnitt er representasjon av antall prosesser merket som kjørbart i oppkjøringen køen. Fra venstre til høyre, de representerer ett minutt, fem minutt, og 15-minutters gjennomsnittlig last. De er de samme tre numrene du kan se i /proc /loadavg. En detaljert forklaring finner du i denne Linux Journal artikkelen. Husk at en prosess i et kjørbart staten ikke nødvendigvis bety det er i dag utføres av prosessoren. Det er et merke som sier at "jeg (oppgaven) er klar til å bli henrettet, men det er opp til planleggeren til å bestemme når man skal plukke meg opp."

For eksempel, hvis du har en enkelt dual-core prosessor og ett minutt load gjennomsnitt leser "2", da i gjennomsnitt hver kjerne utfører en prosess. Hvis det står "4", så i gjennomsnitt én prosess blir utført og man venter i hver kjerne. Den faktiske situasjonen kan være annerledes, siden belastningen gjennomsnitt er faktisk viser "normalisert trender" under visse intervaller i stedet for diskrete tall på et bestemt tidspunkt.

Flytte en linje under, ser vi statistikk om antall oppgaver i ulike tilstander:

Running: som vi har diskutert før, representerer dette antallet oppgaver i et kjørbart tilstand.

Sleeping: prosesser blir blokkert på grunn av venter på en hendelse (for eksempel tidsavbrudd eller I /O ferdigstillelse). Det står for både utkoblbart (kan vekke tidligere av SysV signal) eller avbruddsfri (fullstendig ignorerer SysV signal) prosesser.

Stoppet: den nøyaktige betydningen her er "pauset", ikke "avsluttet". I en terminal, kan du stoppe et program ved å sende den en SIGSTOP signal eller trykke Ctrl-Z om det er en forgrunn oppgave.

Zombie: "En død kropp uten sjel" kan være en god analogi. Etter et barn oppgave er avsluttet, er det ryddet opp og det eneste som står igjen er en oppgave beskrivelse som inneholder en svært viktig verdi: exit status. Så hvis antallet zombier er høy, er det et tegn på at en eller flere programmer har en bug skikkelig avslutningsbarne oppgaver.

Nå skriver vi CPU seksjons statistikk. Ved å trykke på "1", kan du bytte mellom kumulativ og per-core /fysisk CPU-bruken. Tallene her er hentet fra /proc /stat. Top gjør prøvetaking og konverterer dem fra disken baserte nummer i prosenter.

De to venstre-de fleste felt, % oss
og % sy
, representerer prosentandelen av CPU tid brukt i brukermodus og kjernemodus, henholdsvis.

Hva er bruker og kjernemodus? La oss gå tilbake litt og diskutere Intel x86-plattformen. I dette tilfelle har prosessoren fire nivåer av rettigheter, som strekker seg fra 0 til 3, hver kalt en "ring". Ring 0 er den mest privilegerte domene - noen koder henrettet når CPU går dette nivået kan få tilgang til noe på systemet. Ring 3 er de minst privilegerte domene.

Linux-kjernen, som standard, ikke bruker ringer 1 eller 2, bortsett fra i visse vilkår dvs. legge inn en hypervisor. Ring 0 er også kjent som kernel-modus, fordi nesten alle kjerne koder er gitt dette privilegiet. Ring 3 er, lett å gjette, kjent som brukermodus. Bruker plass koder lever i denne ringen.

Denne logisk separasjon primært fungerer som beskyttelse. Brukerkoder kan gjøre noe arbeid, men å røre underliggende lag, som lesing eller skriving til harddisken eller fordele flere kilobyte RAM, kodene må be om kjernetjenester, også kjent som systemkall. Systemkall er sammensatt av en eller flere kjernefunksjoner. De kjører på vegne av kall oppgaven. Så fra privilegieopptrapping synspunkt, er det det samme oppgave, men å bytte fra brukermodus til kernel-modus. Når et systemkall er ferdig, den returnerer en verdi, og oppgaven er flyttet tilbake til brukermodus.

Etter min mening, er en lav eller høy nummeret på begge disse modus verdiene egentlig ikke en stor bekymring. Vi kan betrakte det som en måte å identifisere vår systemets egenskaper. Hvis du finner den % sy
høyere enn% oss mesteparten av tiden, er det sannsynlig at maskinen din fungerer som en filserver, databaseserver, eller noe lignende. På den annen side, en høyere % oss
betyr maskinen din gjør mye av tallknusing.

Høy % sy
verdier kan også bety noen kjernetråder er opptatt med å gjøre noe. Kjernetråder er som vanlige oppgaver, men de har en grunnleggende forskjell: de opererer helt i kernel-modus. Kernel tråder er opprettet for å gjøre en bestemt jobb.

For eksempel: pdflush skriver tilbake oppdatert siden cacher til relaterte lagring, og en migrering tråden gjør lastbalansering mellom CPUer ved å tilordne noen oppgaver til mindre lastet prosessorer. Hvis kjernetråder bruke for mye tid i kernel-modus, vil brukeren plass oppgaver har mindre sjanse for å kjøre. Selv med den nyeste planleggeren som Completely Fair Scheduler (CFS), som gir bedre rettferdighet, bør du lese tilhørende dokumentasjon for å finjustere kjernen tråden.

% hi Hotell og % si
er statistikk relatert til CPU service avbrudd. % hi
er prosentandelen av CPU tid betjene harde avbrudd, mens % si
er når CPU betegner myk avbruddet tid prosentandel.

Ok, så hvorfor er de kalt "myk" og "hard"? Litt bakgrunnsinformasjon om hvordan Linux-kjernen håndtak avbryte først: når et avbrudd kommer på et visst IRQ linje, erkjenner Linux-kjernen raskt det. Det beslektede handler i IDT (Interrupt deskriptortabellen) utføres. Denne erkjennelsen prosessen er gjort mens deaktivere avbrudds levering i lokal prosessor. Dette er grunnen til at det må være rask; hvis ikke, vil antallet ventende avbrudd stige og vil gjøre hardware respons verre.

Løsningen? Kvitter rask, forberede noen data, og deretter utsette det virkelige arbeidet før senere. Denne utsatte jobben kalles en myk interrupt, fordi det er egentlig ikke et avbrudd, men behandles som en. Ved å dele arbeidet med interrupt håndtering, blir systemrespons jevnere og indirekte gir user space koden mer tid til å kjøre. Hvorfor? Enkel - interrupt handler kjører i kernel-modus, akkurat som når vi utfører et systemkall.

En høy % hi
verdi betyr én eller flere enheter er for opptatt med å gjøre sitt arbeid, og er mest sannsynlig overbelastet. I visse tilfeller kan det bety at enheten er ødelagt, så det er godt å gjøre en grundig kontroll før det blir verre. Sjekk /proc /interrupts, og du kan finne kilden.

Når det gjelder % si
, et høyt antall her ikke alltid relatert til høy frekvens av reelle avbrudd. Dele arbeidet mellom den reelle interrupt handler og myke IRQ er sjåførens jobb, så høyt % si
tendens til å vise at det er noe som trengs for å optimalisere inne sjåføren. Den enkleste måten å optimalisere er oppgradere kjernen. Hvis du kompilere kjernen på egen hånd, kan du bruke konfigurasjonsfilen av den gamle kjernen som base config av din nye kjernen, slik at du kan sammenligne resultatet av myk IRQ ledelse. Tredjeparts drivere bør også oppgraderes. En rå observasjon ved hjelp av Google forteller at nettverksdrivere er vanligvis kilden til problemet.

Minne Statistikk

La oss gå videre virtuelt minne statistikk. Dette området er avledet fra /proc /meminfo innhold.

Hva er "total memory" etter din mening? Størrelsen på RAM? Ikke egentlig. Den virkelige meningen er den totale størrelsen på RAM som er kartleggbart ved din kjører kernel. Hvis du ikke bruker en kjerne som har stor adressering evne, er den maksimale adresserbart minne rundt 896 Mb. 896 Mb er en Gb minus noen reserverte kernel-adresseområdet. Teoretisk sett er en Gb kernel adresse plass, mens 3 Gb er brukervennlig plass adresse plass i en 32-bits x86-arkitektur.

For å sikre at systemet kan gjøre stor adressering, installere en kjerne pakke som inneholder strenger som "PAE", "bigmem" eller "hugemem." Ved hjelp av denne modifiserte kjernen, kan du tilordne opptil 64 GB med funksjon som kalles PAE (Physical Address Extension).

De to forvirrende felt i minne statistikk er "buffere" og "bufret". Bufret? Hva er cache? Først kan man få feil konklusjon av sin plassering. Legg merke til det er plassert i "Swap" linje, slik at man kan ta konklusjonen det er cache av swap eller noe lignende. Ikke i det hele tatt. Det er faktisk en del av "Mem" linje, som beskriver fysiske minneforbruk.

buffer er i minnet kopi av blokker som et resultat av kjernen utføre rå disktilgang. For eksempel, når kjernen ønsker å lese innholdet i en fil, først kjernen har til å hente informasjon fra den relaterte inode. For å lese denne inode, leser kernel en blokk fra blokken enheten på et bestemt sektor offset. Derfor kan vi konkludere med at bufferstørrelse stiger hvis det er tilgang til inode eller dentry (katalogoppføring), eller super (når vi montere en partisjon), da direkte tilgang til en fil eller blokk enhet.

Den bufrede feltet forteller oss størrelsen på RAM som brukes til å cache innholdet i filene blir lest nylig. Hvordan er det forskjellig fra buffer feltet? Husker at bufferstørrelsen øker når vi omgå filsystem lag, og bufrede størrelsen øker når gjør det motsatte. Vi kan også se bufret størrelse som graden av caching aggressivitet fra kjernen. Både buffer og cache vanligvis vokser som vi gjør mer leseoperasjoner - og dette er helt normalt. Påfølgende leser kan være fornøyd med å lese fra cache, noe som forbedrer hastigheten og reduserer lese latency.

Per-prosessen statistikker

Resten av toppen på dashbordet er pr-prosessen statistikk. Dette er et svært bredt delemne å dekke, så valget må gjøres:

Avdekke betydningen av minne relaterte felt: VIRT, RES, SHR, nFLT, og nDRT

Forstå NI og PR felt og sammenhengen mellom de to

"Hvor mye minne er tildelt av oppgaven X?" du spør. Du er forvirret mellom å se på VIRT, RES, eller SHR. Før du svarer på det, vil jeg ta en rask oppsummering om to typer minneområde: anonyme eller fil-støttet.

Et eksempel på en anonym minneområdet er et resultat av utførende malloc (), en C-funksjon for å be viss mengde minne. Det kan skje når tekstbehandlingsprogrammet tildeler en buffer for å holde de tegnene du har skrevet. Eller når en nettleser forbereder biter av minne til å vise en nettside.

Hva om fil-støttede minneområde? Når programmet laster en felles bibliotek, et program som heter dumper laster og kartlegger bedt biblioteket til prosess adresse plass. Dermed fra programmet synspunkt, tilgang til bibliotek (dvs. å kalle en funksjon) er som peker til bestemt minneadresse. Se i denne LinuxDevCenter artikkelen for mer informasjon om minnetildeling.

VIRT refererer til lengden på minneområdet, mens RES viser oss hvor mange minneblokker (kalt sider) er egentlig fordeles og kartlagt å behandle adresseområdet. Dermed er VIRT som å snakke om størrelsen på landet vi eier, men huset, hva RES representerer, bygget på toppen av det ikke nødvendigvis trenger å oppta hele plassen. Ganske sannsynlig, er RES langt mindre enn VIRT og det er helt logisk grunn av kravene til paging mekanismen, som bare tildeler sider når det virkelig trengs. Så, er svaret klart: RES viser deg tilnærming av per-prosessen minneforbruk.

Men RES i seg selv har en feil. Husker at vi inkluderer størrelsen på filen-støttede minneområdet i beregningen (f.eks for det delte biblioteket). Vi vet at to eller flere programmer som kjører kan bruke samme sett med biblioteker. Tenk om KDE- eller GNOME-baserte programmer. Når du kjører disse programmene, vil de refererer til de samme bibliotekene men mappet til sin egen adresse plass. Du kan få feil konklusjon disse programmene krever et stort område, mens det i realiteten summen av sidene som tilhører kjørende programmer er lavere enn summen av sine RES.

Det er der SHR kommer til å redde. SHR viser oss størrelsen på filen-støttede minneområdet. Dermed RES minus SHR etterlater oss med størrelsen på anonym minneområdet. Så, er selve minneforbruket for en prosess sted mellom RES og RES minus SHR, avhengig av hvor mange delte bibliotekene er lastet med en gitt prosess og andre prosesser ved hjelp av de samme bibliotekene.

La oss gå til andre felt: nFLT og nDRT. Disse to feltene ikke møter opp som standard, så du må velge dem først ved å trykke 'f' eller 'o' og trykke på tasten som representerer feltet. Husker at kjernen gjør etterspørselen paging Hvis en prosess peker gyldig minne adresse, men ingen side er til stede der. Det formelle navnet på denne tilstanden er sidefeil. Sidefeil har to typer: små og store feil. Mindre sidefeil skje hvis ingen lagring tilgang er involvert. På den annen side, store sidefeil gjør involvere lageraksess.

En mindre sidefeil er forbundet med den anonyme minneområdet, fordi det ikke er behov for å lese disken. Unntaket fra dette er når sidene blir byttet ut. En stor sidefeil er koblet til filen støttede minneområde. På alle store feil, er diskblokker lese og brakt til RAM. Men takket være side cache, hvis målet diskblokk innhold finnes det så vil det være en mindre feil.

nFLT vist av toppen bare teller antall store sidefeil. Hvis dette tallet blir høy, er det en god indikasjon på at du trenger mer RAM. Hvis ledig minne blir stramt, vil noen sider i siden cache spyles ut og anonym minne vil bli byttet ut. Dermed, hvis de åpnes, ekstra store feil oppstår. Prøv å legge til mer RAM, til du ser moderat verdi for nFLT. Sjekk også programmet interne logg eller statistikk og se om høy nFLT betyr redusert ytelse. Vanligvis har latency et tett forhold med store sidefeil.

nDRT er ment å vise antall skitne sider. Men uten en klar årsak, denne verdien (som er hentet fra lengst til høyre felt av /proc /< pid > /statm) viser alltid null i Linux-kjernen 2.6.x. Forhåpentligvis noen kunne fikse den relaterte kjernen koden, slik at toppen kan riktig vise nummeret. I mellomtiden kan du sjekke størrelsen på skitne sider ved å sjekke /proc /< pid > /smaps. Statistikken er brutt ned i hver VMA (Virtual Memory Area) region.

En skitten side betyr at en fil-støttet siden inneholder endrede data. Dette skjer når kjernen ønsker å skrive til disken. Bortsett fra i direkte I /O tilfeller er dataene bare skrevet til side cache og selve siden er merket som skitne. Senere pdflush kjernetråder periodisk skanne de skitne sidene og skrive innholdet på disken. Denne asynkrone prosedyre forhindrer at skrive oppgave blir blokkert for lenge.

Nå slår vi vår oppmerksomhet til NI og PR-feltet. Disse feltene representerer prioriteten for en prosess. NI viser hyggelig nivå, en statisk prioritet tildelt en oppgave når det blir klargjort. Som standard har hver ny prosess hyggelig nivå 0, men du kan overstyre den med "hyggelig" verktøyet. NI varierer fra -20 til 19. PR viser dynamisk prioritet, som er beregnet basert på hyggelig nivå. Når en prosess begynner sitt liv, lik PR NI pluss 20.

Under runtime, PR kan gå opp eller ned avhengig av kjernen versjonen du bruker. Pre-2.6.23 Linux-kjernen, kan PR være hvilken som helst verdi innenfor NI + 20-x og NI + 20 + x. x
seg selv kan anses som "bonus" eller "rabatt" punkt. Hvis en prosess sover mye, vil det få bonus så sin PR dekrementeres. Ellers, hvis en prosess tygger mye CPU-tid, sin PR vil bli inkrementert. Når kjernen planleggeren ønsker å velge hvilken prosess som skal kjøre, prosessen med lavest prioritet dynamiske vinner.

I Linux 2.6.23 og oppover, er PR alltid NI pluss 20. Det er konsekvensen av det nyfusjonerte CFS scheduler, hvor søvn intervall ikke lenger utelukkende tilsier dynamisk prioritet justering. Og, er nå dynamisk prioritet ikke den største bekymringen når du velger den neste løpe oppgave. Uten å gå for dypt inn CFS innvendige, er det tilstrekkelig å si at CFS planleggeren velger kjørbart prosessen som i dag bruker minst CPU virtuell tid. Dette er "rettferdighet" CFS ønsker å oppnå, med alle prosesser ha en forholdsmessig del av CPU prosessorkraft, med PR fungerer som veiing faktor til denne rettferdighet. Da kan vi konkludere med gjennomføringen av CFS, en prosess med høyere PR har en sjanse til å preempt den nedre.

Om forfatteren

Mulyadi Santosa, RHCE, bor i Jakarta, hovedstaden i Indonesia. Han jobber som frilansskribent og er en eier av en oppstart som fokuserer på undervisning Linux for ulike nivåer av publikum. Han skriver en månedlig spalte om Linux for CHIP Indonesia
magasinet, og har skrevet artikler for indonesiske og utenlandske publikasjoner. Du kan kontakte ham på Denne e-postadressen er beskyttet mot programmer som samler. Du må aktivere Javascript for å kunne se og besøke sin blogg.

Takk

Avishay Traeger, for å overbevise meg om å skrive om dette emnet

Breno Leitao, Sandeep K. Sinha, Cheetan Nanda for hyggelig diskusjon og hint. < .no>