rupert is terug
HELSINKI - Donderdagavond. De werkweek nadert alweer haar einde. Het was een bijzonder drukke week. We zijn nog niet helemaal klaar, maar we werken hard, geloof me... Ik ben deze week tamelijk druk geweest met wat manager-dingetjes, en een beetje software-ontwerp, en een beetje optimalisatie, en... en... En vanmiddag had ik Finse les. De taal blijft erg lastig, en elke les brengt weer nieuwe verrassingen. Ik heb een aardig overzicht van de grammatica, dat wil zeggen, ik weet wanneer iets wellicht verbogen dient te worden (bijna altijd!). Maar wanneer precies? En hoe? Vanmiddag was een beetje zoals Life of Brian ("Romani ite domum") toen ik een zin moest opschrijven op het bord...

Waar is mijn telefoon toch gebleven?

Ik ben altijd geïnteresseerd in het optimaliseren van software - zowel professioneel als bij mijn hobbyprojecten. Ik vond de analyse van de starttijd van de GNOME-desktop van Lorenzo Colitti dan ook erg interessant - de voorgestelde veranderingen zorgen ervoor dat het opstarttijd ongeveer gehalveerd word, en er zijn verdere verbeteringen mogelijk. Sommige van de voorgestelde wijzigingen zijn ook interessant voor onze 770, maar over het algemeen richten de verbeteringen zich nogal op het minimaliseren van disk-seeks. De 770 heeft echter geen harddisk maar flash-geheugen, waarvoor disk-seeks niet zo'n probleem zijn.

In het 770-geval is het optimaliseren van het geheugengebruik wel erg belangrijk. Daarvoor zijn verschillende hulpmiddelen beschikbaar.

Er is bijvoorbeeld smaps, geschreven door de mensen van Instituto Nokia de Tecnologia in Brazilië. Vooralsnog nog niet in de standaard Linux-kernel (maar staat in het lijstje voor 2.6.14, zo lijkt het). Via /proc/<pid>/smaps (een uitgebreide versie van /proc/<pid>/maps (proc(5)) kan gedetailleerde informatie over het geheugengebruik van een applicatie verkregen worden. Voor alle 'gemapte' stukken geheugen (incl. bestanden) wordt aangeven hoeveel geheugen 'shared', 'private' en 'dirty' is (ik heb hier even geen smaps-kernel, dus output is geleend):

# cat /proc/4576/smaps

08048000-080dc000 r-xp /bin/bash
Size: 592 KB
Rss: 500 KB
Shared_Clean: 500 KB
Shared_Dirty: 0 KB
Private_Clean: 0 KB
Private_Dirty: 0 KB
080dc000-080e2000 rw-p /bin/bash
Size: 24 KB
Rss: 24 KB
Shared_Clean: 0 KB
Shared_Dirty: 0 KB
Private_Clean: 0 KB
Private_Dirty: 24 KB
080e2000-08116000 rw-p
Size: 208 KB
Rss: 208 KB
Shared_Clean: 0 KB
Shared_Dirty: 0 KB
Private_Clean: 0 KB
Private_Dirty: 208 KB
b7e2b000-b7e34000 r-xp /lib/tls/libnss_files-2.3.2.so
Size: 36 KB
Rss: 12 KB
Shared_Clean: 12 KB
Shared_Dirty: 0 KB
Private_Clean: 0 KB
Private_Dirty: 0 KB
etc.

De analyse van de uitkomsten daarvan (zeker wanneer het gaat om de veranderingen tijdens de uitvoering van een programma) is echter niet zo eenvoudig, en vergt wat ervaring... De hoeveelheid dirty geheugen moet geminimaliseerd worden, en 'shared' geheugen valt te prefereren boven 'private' geheugen. 'Onze' Tommi Komulainen paste dat toe op GTK+, bijvoorbeeld.

Een simpeler manier om iets over het geheugengebruik van een programma te leren is good-old top - een goede ruwe benadering van het geheugengebruik van een programma is RES - SHR, oftewel het 'residente' geheugen minus het geheugen gedeeld met andere programma's. In het onderstaande voorbeeld geldt bijvoorbeeld dat rhythmbox, Xorg (de X-server), en top zelf, resp. 10Mb, 12Mb, en 264Kb gebruiken.

top - 11:54:51 up  2:08,  7 users,  load average: 1.19, 0.67, 0.37
Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie
Cpu(s): 29.4% us,  3.3% sy,  0.0% ni, 66.7% id,  0.0% wa,  0.7% hi,  0.0% si
Mem:    515744k total,   504536k used,    11208k free,    14464k buffers
Swap:        0k total,        0k used,        0k free,   208564k cached
PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
12779 djcb      15   0 61404  20m  10m S  7.2  4.0   3:39.76 rhythmbox          
 6447 root      15   0 59496  20m 8340 S  3.6  4.0   2:30.68 Xorg               
13232 djcb      16   0  2132 1104  840 S  0.7  0.2   0:00.27 top                
...

Een ander interessant getal is the load average. De drie getallen 1.19, 0.67 en 0.37 geven de gemiddelde systeembelasting aan voor resp. de laatste 1, 5 en 15 minuten. Getallen > 1 betekenen dat de CPU het zo druk had dat processen moesten wachten. Trouwens, altijd goed om af en toe naar dit soort gegevens te kijken - ik ontdekte uit bovenstaande dat m'n swap niet geactiveerd was - oops
-- djcb @ 01:48 | 0 comments