Processen beheren

Werk voor de systeembeheerder

Hoewel het beheer van het systeem, incluis processen, eerder een werkje voor de systeembeheerder is, kan het zeker geen kwaad om als gewone gebruiker een minimale kennis over deze materie te vergaren. Je hebt immers het recht om je eigen processen te beheren, ook al heb je normaalgezien niets te zeggen over processen die door andere gebruikers opgestart worden. En ook op systemen waar je de enige gebruiker bent, is het nuttig te weten hoe je je processen zo optimaal mogelijk kan laten draaien.

We gaan ons dus buigen over het probleem “performantie”, maar dan op een heel globale manier. We gaan het niet hebben over moeilijk te traceren hardware problemen of optimalisatie van code. Dat is met de basiskennis die we nu hebben nog een veel te moeilijk onderwerp.

In plaats daarvan zullen we de dagelijkse problemen van de gewone gebruiker bespreken, en methodes aanhalen die je zullen helpen om je systeem zo optimaal mogelijk te gebruiken. Zoals je zal zien, is dat vooral een kwestie van “eerst denken, dan doen”.

Hoe lang zal het duren?

Het time commando werkt als een chronometer. Het geeft aan hoeveel uur, minuten en seconden een opdracht duurt om uit te voeren. Je gebruikt het door het te plaatsen vóór het commando dat je wilt uitvoeren. Een voorbeeld: berekenen hoe lang het duurt om de /usr map te doorzoeken:

Handeling met de muis.

willy@ubuntu:~$ time find /usr
<--output weggelaten-->

real	0m14.859s
user	0m0.006s
sys	0m0.441s

De echte tijd (real) is natuurlijk hetgeen ons als gewone gebruiker het meest interesseert. De andere twee indicaties duiden op processen van de gebruiker van het commando en processen die door het systeem zelf worden opgestart.

[Opmerking]Nog time

Wat we hier net besproken hebben, is het time commando dat ingebouwd is in de Bash shell. Met /usr/bin/time krijg je uitgebreidere informatie, zie de man pagina's.

De uitvoering van gewone commando's duurt over het algemeen niet zo lang, enkele seconden hooguit. Het chronometreren van commando's wordt pas interessant voor taken waarvan je verwacht dat ze lang zullen duren, bijvoorbeeld backups of het maken van software. Door het time commando regelmatig eens te gebruiken in zo'n omstandigheden, krijg je een idee van hoe lang het zal duren om in de toekomst gelijkaardige commando's uit te voeren. Het laat je ook toe om adequaat de snelheid van twee computers te vergelijken.

Performantie

Voor een gebruiker betekent performantiehet snel uitvoeren van commando's”. Voor een systeembeheerder daarentegen betekent performantie veel meer dan dat: de beheerder moet de performantie van het systeem optimaliseren voor het hele systeem, inbegrepen alle gebruikers, processen en diensten. De performantie van een systeem kan afhangen van duizend kleine dingen waarmee geen rekening gehouden wordt in het time commando:

  • Het uit te voeren programma kan slecht geschreven zijn of het kan de computer suboptimaal gebruiken.

  • De snelheid van harde schijven, controllers en allerlei soorten interfaces kan een programma vertragen.

  • De snelheid van het netwerk kan een blokkerende faktor zijn.

  • Het aantal gebruikers op het systeem en het aantal taken die gelijktijdig worden uitgevoerd, kunnen vertragend werken.

  • Het tijdstip kan een rol spelen als gevolg van bovenstaande faktoren.

  • ...

Vooral wanneer je niet de enige gebruiker bent op een systeem, zal je hiermee rekening moeten houden.

Belasting

Zoals we reeds zagen met het top commando, kan je met het commando uptime informatie krijgen over de belasting van het systeem. Geef het commando gewoon in, zonder opties of argumenten:

Handeling met de muis.

willy@ubuntu:~$ uptime
 10:10:04 up 49 min, 2 users, load average: 0.00, 0.00, 0.02

Dit commando geeft van links naar rechts het volgende weer:

  • De huidige tijd.

  • Het aantal dagen, uren en minuten dat het systeem al aan het draaien is.

  • Hoeveel gebruikers er momenteel aangemeld zijn.

  • De belasting van het systeem gedurende de laatste minuut, de laatste 5 minuten en de laatste 15 minuten.

De belasting van het systeem wordt uitgedrukt met een relatief getal. Je kan met andere woorden niet zeggen of het veel of weinig is als je niet weet wat normaal is voor je systeem. Sommige systemen lijken wel constant te slapen, omdat de belasting aangeduid wordt met 0:00; andere, met meerdere processoren, kunnen een belasting van 78 tonen en perfect draaien. Je moet dus regelmatig dit commando gebruiken, zodat je de output kan interpreteren wanneer je de indruk hebt dat het traag gaat.

[Opmerking]Load?

Belasting wordt in het Engels load genoemd. Je zult de term vast wel eens tegenkomen in man pagina's en andere documentatie.

Houd er verder ook rekening mee dat dat verschillende systemen zich verschillend kunnen gedragen onder ogenschijnlijk dezelfde omstandigheden. Bijvoorbeeld het afspelen van een muziek- of video-CD kan traag gaan op een systeem met 2x speed CD-ROM speler, en snel op een ander systeem dat een 40x speed CD-ROM speler heeft, hoewel beide systemen de zelfde processorsnelheid hebben.

Wat kan ik doen?

Algemene bedenkingen

Een uitgebreide werkomgeving, zoals bijvoorbeeld een bureaublad waarop je veel extra toeters en bellen ingesteld hebt, kan je werk vertragen. Vooral als je niet elk jaar een nieuwe computer wilt kopen, is bescheidenheid hier een deugd.

In de tekstomgeving kunnen variabelen en paden (zie lespakket 3) die verkeerd ingesteld zijn ervoor zorgen dat het systeem er langer over doet om opdrachten en bestanden te vinden.

Prioriteit

Sommige taken, waarvan het geen rol speelt of ze nu supersnel of aan normale snelheid uitgevoerd worden, zullen toch standaard opstarten met een hoge prioriteit, en zo andere processen beletten om een redelijk aandeel van de processorcyclussen te gebruiken.

De prioriteit van een proces wordt aangeduid met een nice nummer (van het Engels: aardig, vriendelijk). Een programma met een hoog nice nummer is vriendelijker voor het systeem en zal andere processen ook de kans geven om cycli op de processor te gebruiken. Een laag nice nummer daarentegen betekent dat het proces egoïstisch is en zoveel mogelijk cycli voor zichzelf houdt.

De prioriteit van een proces aanpassen is enkel nuttig voor processen die veel processorkracht gebruiken, zoals bijvoorbeeld rekentoepassingen en compilers. Processen die veel I/O operaties doen worden automatisch beloond door het systeem en krijgen een hogere prioriteit - en dus een lager nice nummer. Input via het toetsenbord, bijvoorbeeld, krijgt altijd de hoogste prioriteit.

[Opmerking]Compiler?

Een compiler is het programma dat geschreven code omzet naar een programma dat door de processor uitgelezen kan worden.

[Opmerking]I/O?

I/O staat voor Input/Output. Hiermee wordt bedoeld de datastromen van en naar de processor, bijvoorbeeld wanneer de processor een proces uit de wachtrij in het geheugen uitleest (zie de paragraaf “Het top commando”).

De prioriteit van een programma instellen afwijkend van de standaardwaarde doe je met het nice commando. Maar meestal zal je merken dat een programma, dat al aan het draaien is, teveel belasting veroorzaakt voor de processor. Om de prioriteit aan te passen zonder het proces te onderbreken, gebruik je renice. Gezien we in deze cursus geen processen opstarten die zodanig veel belasting veroorzaken dat de prioriteit ervan veranderd moet worden, gaan we niet verder in op het gebruik van deze commando's. Dit commando wordt meestal ook door systeembeheerders gebruikt, wanneer gewone gebruikers teveel resources van het systeem in beslag nemen. Lees de man pages mocht je ze nodig hebben, bijvoorbeeld op de servers op het werk.

[Waarschuwing]Interaktieve programma's

Onthoud dat het geen goed idee is om een interaktief programma van prioriteit te veranderen, of dat te doen bij een proces dat in de voorgrond draait.

CPU verbruik

Zoals we reeds zagen, zijn er op een Linuxsysteem altijd meerdere programma's die de processor(en) gelijktijdig willen gebruiken, ook al ben je de enige gebruiker van het systeem. Elk programma heeft een zeker aantal CPU-cycli nodig om te kunnen werken. Het kan dus gebeuren dat er niet genoeg cycli zijn omdat de processor te druk bezig is. Het uptime geeft niet echt nauwkeurige informatie, je moet weten wat normaal is op je systeem om de waarden van de gemiddelden te kunnen interpreteren. Er zijn een aantal zaken die je kan uitproberen wanneer je vermoedt dat de processor de vertragende faktor is:

  • Start zware programma's wanneer de belasting laag is, bijvoorbeeld 's nachts. Zie de volgende sektie voor meer informatie over automatische uitvoering van taken.

  • Voorkom dat het systeem onnodig werk doet: stop programma's en diensten die je niet gebruikt, gebruik locate in plaats van find, enzovoorts.

  • Draai zware taken met een lage prioriteit.

Als geen van deze oplossingen een optie is op jouw systeem, dan moet je misschien overwegen om de CPU te vervangen door een sneller model.

Geheugen

Wanneer een draaiend proces meer geheugen verwacht dan er fysisch beschikbaar is, zal het Linuxsysteem niet stilvallen of op een andere manier falen. In plaats daarvan begint het te swappen (letterlijk van het Engels to swap, omwisselen): de inhoud van het fysische geheugen wordt gecopieerd naar een lokatie op de harde schijf, zodat er ruimte vrijkomt om om meer processen te bedienen. Deze manier van werken vertraagt het systeem natuurlijk enorm, want de toegang naar schijven is honderden of zelfs duizenden keren trager dan de toegang naar het geheugen. Het top commando kan gebruikt worden om informatie te geven over de beschikbare ruimte om te swappen (zie de paragraaf “Het top commando”). Bij voorkeur komt swappen niet of slechts heel weinig voor.

Probeer het volgende wanneer je ziet dat je machine veel swapt:

  • Stop, kill of renice de grootste geheugenvreters. Zie de paragraaf “Processen onderbreken” voor meer over het kill commando om processen te onderbreken.

  • Voeg meer geheugen toe.

  • Verfijn de instellingen van het systeem. Dit gaat echter verder dan het onderwerp van deze cursus, tuning is een taak voor systeembeheerders.

I/O verbruik

Analyseprogramma's

Hoewel I/O limieten systeembeheerders veel hoofdbrekens kunnen bezorgen, zijn er op Linux niet echt handige gereedschappen om de I/O performantie te meten. Het meest gebruikt zijn vmstat, netstat en iostat. Grafische programma's interpreteren de output van deze commando's.

[Opmerking]I/O limiet?

De I/O limiet is de maximale hoeveelheid data die per tijdseenheid naar een bepaald apparaat gestuurd kan worden. Een voorbeeld dat je vast wel kent: CD's schrijven kan snel gaan of traag gaan, afhankelijk van de snelheid van het schrijfstation. Net zo is het voor verschillende types van harde schijven, geheugen en andere onderdelen van de computer.

Elk randapparaat heeft zijn eigen specifieke problemen. Toch kunnen de I/O problemen in twee grote categorieën opgedeeld worden: problemen te wijten aan te weinig beschikbare bandbreedte op het netwerk en problemen te wijten aan de traagheid van harde schijven.

Netwerk I/O

Volgende problemen kunnen zich voordoen op het netwerk:

  • Overbelasting: De hoeveelheid data die over het netwerk moet passeren, is groter dan de capaciteit van het netwerk, zodat alle taken die netwerkaktiviteit vereisen voor alle gebruikers traag gaan. Deze problemen kunnen opgelost worden door het netwerk op te kuisen, diensten die niet gebruikt worden te desactiveren of door het netwerk te herconfigureren, bijvoorbeeld door beter geschikte netwerkhardware te plaatsen.

  • Problemen met de integriteit van het netwerk: Deze problemen treden op wanneer data op weg door het netwerk beschadigd worden en kunnen enkel opgelost worden door het falende netwerkapparaat op te sporen en te vervangen, bijvoorbeeld de netwerkkaart van de computer, de kabels of de apparatuur die ervoor zorgt dat de data de juiste weg volgt over het netwerk.

Schijf I/O

Vertragingen te wijten aan trage schijven zijn veel moeilijker op te sporen. De schijfproblemen worden als volgt opgedeeld:

  • Per-proces transfer te laag: de snelheid van lezen of schrijven van een enkel proces is onvoldoende, bijvoorbeeld omdat het proces heel veel leesoperaties moet doen. De snelheid van het systeem is in dit geval wel OK als dat bepaald proces niet draait.

  • Geaggregeerde snelheid is te laag: het systeem is traag voor alle processen.

De oplossingen hangen af van de aard van het probleem. Lezen en schrijven kan traag gaan omdat de harde schijf aan het stuk gaan is, dat is het meest voordehandliggend en vervanging van de schijf verhelpt het probleem. Als alle hardware naar behoren funktioneert, wordt het echter ingewikkelder. Een mogelijke oplossing is meer schijven plaatsen, zodat er naar verschillende schijven tegelijk I/O kan zijn. Of je kan overwegen om snellere controllers te gebruiken of, in bedrijfsomgevingen, om over te stappen op een andere architectuur.

Soorten gebruikers

Gebruikers kunnen onderverdeeld worden in verschillende klassen, afhankelijk van hun gedrag en gebruik van het systeem:

  • Gebruikers die een (groot) aantal lichte commando's draaien: jij bijvoorbeeld, de beginnende gebruiker.

  • Gebruikers die weinig, maar zware processen draaien: simulaties, berekeningen, wetenschappelijke toepassingen, emulatoren of andere programma's die veel geheugen en grote bestanden gebruiken.

  • Gebruikers die weinig processen draaien maar veel processorcapaciteit verbruiken, bijvoorbeeld ontwikkelaars van programma's.

je kan kijken welke gebruikers er op het systeem aangemeld zijn door middel van het w commando, daarmee kan je ook zien wat de gebruikers aan het doen zijn:

Handeling met de muis.

willy@ubuntu:~$ w
11:19:16 up 1:59, 2 users, load average: 0,00, 0,00, 0,00
USER	TTY	FROM		LOGIN@	IDLE	JCPU	PCPU	WHAT
willy	:0	-		09:22	?xdm?	3:20	1.18s	x-session-manage
willy	pts/0	:0.0		09:23	0.00s	0.37s	0.02s	w

In de eerste lijn herkennen we de output van het uptime commando. Daarna volgt info over de gebruikers:

  • USER: de gebruikersnaam

  • TTY: de (pseudo)terminal waarop de gebruiker werkt. :0 betekent dat de gebruiker op het eerste scherm aan het werken is, pts/0 is het eerste terminal venster.

  • FROM: van waar is de gebruiker aangemeld: een streepje betekent lokaal, voor pseudoterminals zie je het displaynummer en -subnummer waarop het terminal venster getoond wordt.

  • LOGIN@: tijdstip waarop de sessie gestart werd.

  • IDLE: de zogenaamde idletime duidt aan hoe lang de gebruiker al niets aan het doen is. Voor een grafische login staat er ?xdm?: het is niet relevant om hier idletime te geven, omdat de gebruiker vast ook allerlei commando's aan het uitvoeren is of processen draaiende heeft. Dat moet je dan nagaan met ps.

  • JCPU: de tijd dat de processor bezig is geweest met alle commando's die vanuit deze terminal draaien. Niet relevant voor de grafische sessie.

  • PCPU: de tijd dat de processor bezig is geweest met het proces, genoemd in het laatste veld.

  • WHAT: het proces dat de gebruiker nu draait.

Grafisch gereedschap

Er is een heel gamma aan grafische programma's ter beschikking, die het makkelijker maken om de output van de vaak cryptische tekstcommando's te analyzeren. Een voorbeeld is gnome-system-monitor, die je kan opstarten vanuit een terminal venster:

Figuur 5.2. De Gnome system monitor

De Gnome system monitor

Iets eenvoudiger is het programma xload. Je moet het even laten draaien voor je beeld krijgt. Dit programma geeft een periodiek bijgewerkt histogram van de belasting op het systeem.

Processen onderbreken

Wat zijn de opties?

Zelfs al kan je de processen van andere gebruikers niet beïnvloeden, dan kan je toch je eigen processen in toom houden. Je kan nu al informatie over processen opvragen en je weet welke restricties er kunnen optreden. Wanneer je merkt dat één van de processen die je zelf hebt opgestart, te veel middelen gebruikt, heb je twee mogelijkheden:

  • Zorg dat het proces minder belastend is door middel van het renice commando; hiervoor moet je het proces niet onderbreken.

  • Stop het proces.

De prioriteit veranderen

Het werken met nice en renice vereist een uitgebreide kennis van het systeem. Er is echter een gemakkelijker manier: top (zie de paragraaf “Het top commando”). Een belastend proces zal vermoedelijk een negatieve nice waarde hebben in de kolom “NI”. Werk als volgt:

  • Spoor het proces identificatienummer op.

  • Typ r.

  • Vul het PID van het proces in en druk Enter.

  • Geef de nice waarde in en druk Enter. Twintig is gewoonlijk een goede keuze, dat betekent dat vanaf nu het proces maximaal 1/5 van de processorcapaciteit zal gebruiken.

Voorbeelden van processen die je zo behandelt zijn emulatoren, virtuele machines, compilers enzovoorts.

Het kill commando

Een proces stoppen omdat het hangt, op hol slaat of teveel of te grote bestanden aanmaakt, doe je met kill. Als je daartoe de gelegenheid hebt, probeer dan eerst de zachtaardige manier en stuur een SIGTERM signaal (zie de paragraaf “Signalen”). Dit instrueert het proces om af te handelen waar het mee bezig is volgens de procedures zoals beschreven in de code van het programma. Op die manier wordt alle rommel opgeruimd en worden er geen bestanden beschadigd. Ga als volgt te werk:

  • Zoek het procesidentificatienummer van het proces dat je wilt stoppen met behulp van ps -ef.

  • Gebruik het commando kill -15 PID_nummer.

  • Ga na met ps of het proces echt wel weg is.

Van sommige processen raak je echter niet zo makkelijk af. Probeer dan in eerste instantie kill -2, een interruptiesignaal. Dat is hetzelfde als een programma onderbreken met Ctrl+C als het in de voorgrond draait.

Als ook dat niet helpt, zit er niet veel anders op dan het sterkste signaal te sturen, een SIGKILL, met kill -9.

Kijk in elk geval altijd na met ps of het stoppen gelukt is.

Shells zijn doorgaans het moeilijkst om te stoppen, en dat is maar goed ook. Stel je voor dat je telkens een nieuwe terminal zou moeten openen, wanneer je Ctrl+C invoert...

Het xkill commando

Handeling met de muis.

Grafische programma's die vasthangen kan je proberen stoppen met xkill. Na het ingeven van dit commando verandert de muispijl in een doodshoofd. Beweeg het doodshoofd over het venster van het programma dat je wilt stoppen en klik met de linkermuistoets.