[n00b] Redhat 9 geheugen in idle op 420 MB :?

[paQ]

ik heb vanochtend een verse installatie Redhat 9 geinstalleerd.
de updates gedraaid etc.

alles is netjes in orde

alleen alles is zo traag als dikke stront foor een koffiefilter

mozilla opstarten of de mail client duurt ongeveer 20 - 30 seconden.

volgens de systeem monitor gebruikt het systeem maar 2 % cpu, maar maar liefst dik 400 MB RAM
als ik mozilla oid draai loopt dat natuurlijk op met 15 a 20 MB

ik heb in totaal maar 512, en ik denk ook dat dit dan de reden is dat ales zo traag verloopt...


specs:
AMD Athlon XP 2000+ @ 1,67
512 MB RAM

[IKKE86]

welke services etc heb je meegeinstalleerd?

[paQ]

IKKE86 schreef op 22 mei 2004 @ 19:55:
welke services etc heb je meegeinstalleerd?

ik heb de standaard paketten geinstalleerd als office, mozilla, de mailclient etc.

na aanmelden bij de update server zijn er iets van 80 bestanden gedownload als fonts en perl updates etc etc.

maar ook vóór de updates al was het zo traag

[IKKE86]

paQ schreef op 22 mei 2004 @ 19:58:
[...]


ik heb de standaard paketten geinstalleerd als office, mozilla, de mailclient etc.

na aanmelden bij de update server zijn er iets van 80 bestanden gedownload als fonts en perl updates etc etc.

maar ook vóór de updates al was het zo traag

kijk anders is met top welke proccessen er zo veel geheugen vreten

[LollieStick]

post eens de output van het commando free

[roelio]

Waar lees je je RAM usage af? Is het incl. of excl. buffering, cache etc?

[_Squatt_]

Je kunt even controleren of je hd's wel dma aan hebben staan (zoeken op 'hdparm'). 420 MB is wel wat veel, weet je zeker dat daar niet toevallig de diskcache bij zit? (check ook deze faq).

512 MB moet overigens ruim voldoende zijn.

[paQ]

update:
net na alle updates e.d. en na een reboot kreeg ik in mijn bootmenu een geupdate kernel (naar het schijnt )
die heb ik nu gekozen en het verbruik is nu ongeveer 180 MB
lijkt me iets beter


maar is het dan 'normaal' dat mozilla od evolution opstarten bijna 30 seconden in beslag neemt?

[roodhoedje]

Meestal duurt dat inderdaad even, hoewel 30 sec wel veel is ik heb dit nooit gemeten met een stopwatch . Misschien is je hd nog bezig met dingen laden ofzo anders zou ik kijken of er een nieuwere versie uit is die ook bij je cpu past i586 i686 ect..

[odysseus]

Zelf met de meest trage versie die er bestaat, inclusief alle debug-toestanden die je maar kunt verzinnen, kost het geen halve minuut om Mozilla op te starten op een XP 2000+...het probleem ligt dus duidelijk ergens anders . Zou je eens de uitvoer van 'ps aux' kunnen posten? En van 'hdparm /dev/hda' (eventueel hdb/hdc/hdd, als je meerdere schijven gebruikt)?

[jealma]

Ik heb RedHat 9.0 gedraait op een XP1600+ met 256 mb pc2100 dus je moet het bij je settings zoeken...

[paQ]

odysseus schreef op 22 mei 2004 @ 20:49:
Zelf met de meest trage versie die er bestaat, inclusief alle debug-toestanden die je maar kunt verzinnen, kost het geen halve minuut om Mozilla op te starten op een XP 2000+...het probleem ligt dus duidelijk ergens anders . Zou je eens de uitvoer van 'ps aux' kunnen posten? En van 'hdparm /dev/hda' (eventueel hdb/hdc/hdd, als je meerdere schijven gebruikt)?

wil ik best

(maar ik ben eigenlijk linux-n00b; vandaar dat ik er nu maar eens mee begonnen ben... beter, alwéér begonnen)

[roodhoedje]

hdparm run je in de terminal (onder suse als root dus met su inloggen en dan hdparm, in de terminal dus) dan gewoon hdparm /dev/hda (mocht je niet op je primiary ide channel de masterschijf redhat hebben gezet dan is de a bij hda een andere letter b , c ,d ect)

dan krijg je een overzichtje dat graag posten

[paQ]

roodhoedje schreef op 22 mei 2004 @ 21:04:
hdparm run je in de terminal (onder suse als root dus met su inloggen en dan hdparm, in de terminal dus) dan gewoon hdparm /dev/hda (mocht je niet op je primiary ide channel de masterschijf redhat hebben gezet dan is de a bij hda een andere letter b , c ,d ect)

dan krijg je een overzichtje dat graag posten

code:

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 4998/255/63, sectors = 80293248, start = 0

[odysseus]

Dat ziet er goed uit, dus daar ligt het probleem niet . Kan je ook eens hetzelfde doen met 'ps aux'?

[paQ]

ditte?

code:

[root@f216125 root]# ps aux
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  2.4  0.0  1380  480 ?        S    22:24   0:04 init
root         2  0.0  0.0     0    0 ?        SW   22:24   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SW   22:24   0:00 [kapmd]
root         4  0.0  0.0     0    0 ?        SWN  22:24   0:00 [ksoftirqd_CPU0]
root         9  0.0  0.0     0    0 ?        SW   22:24   0:00 [bdflush]
root         5  0.0  0.0     0    0 ?        SW   22:24   0:00 [kswapd]
root         6  0.0  0.0     0    0 ?        SW   22:24   0:00 [kscand/DMA]
root         7  0.0  0.0     0    0 ?        SW   22:24   0:00 [kscand/Normal]
root         8  0.0  0.0     0    0 ?        SW   22:24   0:00 [kscand/HighMem]
root        10  0.0  0.0     0    0 ?        SW   22:24   0:00 [kupdated]
root        11  0.0  0.0     0    0 ?        SW   22:24   0:00 [mdrecoveryd]
root        15  0.0  0.0     0    0 ?        SW   22:24   0:00 [kjournald]
root        72  0.0  0.0     0    0 ?        SW   22:25   0:00 [khubd]
root      2798  0.0  0.0     0    0 ?        SW   22:25   0:00 [kjournald]
root      3158  0.0  0.1  1980  984 ?        S    22:25   0:00 /sbin/dhclient -1
root      3217  0.0  0.1  1456  568 ?        S    22:25   0:00 syslogd -m 0
root      3221  0.0  0.0  1384  452 ?        S    22:25   0:00 klogd -x
rpc       3239  0.0  0.1  1556  572 ?        S    22:25   0:00 portmap
rpcuser   3258  0.0  0.1  1628  768 ?        S    22:25   0:00 rpc.statd
root      3324  0.0  0.0  1372  492 ?        S    22:25   0:00 /usr/sbin/apmd -p
root      3361  0.0  0.2  3524 1520 ?        S    22:25   0:00 /usr/sbin/sshd
root      3375  0.0  0.1  2064  900 ?        S    22:25   0:00 xinetd -stayalive
root      3395  0.0  0.4  5960 2548 ?        S    22:25   0:00 sendmail: accepti
smmsp     3404  0.0  0.4  5756 2300 ?        S    22:25   0:00 sendmail: Queue r
root      3414  0.0  0.0  1420  448 ?        S    22:25   0:00 gpm -t imps2 -m /
root      3423  0.0  0.1  1432  592 ?        S    22:25   0:00 crond
root      3434  0.0  0.4  7592 2140 ?        S    22:25   0:00 cupsd
xfs       3485  0.0  0.6  5684 3488 ?        S    22:25   0:00 xfs -droppriv -da
daemon    3503  0.0  0.1  1416  532 ?        S    22:25   0:00 /usr/sbin/atd
root      3513  0.0  0.1  3412  544 ?        S    22:25   0:00 rhnsd --interval
root      3519  0.0  0.0  1364  408 tty1     S    22:25   0:00 /sbin/mingetty tt
root      3520  0.0  0.0  1364  408 tty2     S    22:25   0:00 /sbin/mingetty tt
root      3521  0.0  0.0  1364  408 tty3     S    22:25   0:00 /sbin/mingetty tt
root      3522  0.0  0.0  1364  408 tty4     S    22:25   0:00 /sbin/mingetty tt
root      3523  0.0  0.0  1364  408 tty5     S    22:25   0:00 /sbin/mingetty tt
root      3524  0.0  0.0  1364  408 tty6     S    22:25   0:00 /sbin/mingetty tt
root      3525  0.0  0.6 14132 3252 ?        S    22:25   0:00 /usr/bin/gdm-bina
root      3568  0.2  0.8 15332 4308 ?        S    22:25   0:00 /usr/bin/gdm-bina
root      3696  2.3  2.3 95844 12056 ?       S    22:27   0:01 /usr/X11R6/bin/X
root      3705  0.3  1.8 18836 9508 ?        S    22:27   0:00 /usr/bin/gnome-se
root      3763  0.0  0.1  3148  988 ?        S    22:27   0:00 /usr/bin/ssh-agen
root      3774  0.5  1.4 11284 7416 ?        S    22:27   0:00 /usr/libexec/gcon
root      3776  0.1  0.4  6272 2496 ?        S    22:27   0:00 /usr/libexec/bono
root      3778  0.3  1.3 13052 6880 ?        S    22:27   0:00 /usr/bin/metacity
root      3780  0.3  1.3 17428 6856 ?        S    22:27   0:00 gnome-settings-da
root      3787  0.0  0.2  2544 1212 ?        S    22:27   0:00 fam
root      3794  1.5  2.4 21268 12364 ?       S    22:27   0:00 gnome-panel --sm-
root      3796  2.1  3.0 73624 15504 ?       S    22:27   0:00 nautilus --no-def
root      3798  0.2  1.2 16460 6284 ?        S    22:27   0:00 magicdev --sm-cli
root      3800  0.1  1.3 16904 7132 ?        S    22:27   0:00 eggcups --sm-clie
root      3804  0.2  1.4 17128 7364 ?        S    22:27   0:00 /usr/libexec/noti
root      3810  0.2  0.8 11804 4376 ?        S    22:27   0:00 pam-panel-icon --
root      3812  0.9  2.6 24548 13680 ?       S    22:27   0:00 /usr/bin/python /
root      3813  0.0  0.0  1412  492 ?        S    22:27   0:00 /sbin/pam_timesta
root      3815  0.8  1.8 20228 9668 ?        S    22:27   0:00 gnome-terminal
root      3816  0.0  0.1  1864  596 ?        S    22:27   0:00 gnome-pty-helper
root      3817  0.1  0.2  4332 1404 pts/0    S    22:27   0:00 bash
root      3845  0.0  0.1  2664  724 pts/0    R    22:28   0:00 ps aux

[Mayco]

hang daar eens [ code ] tags rond, dan is het al wat duidelijker

[DataGhost]

Mayco schreef op 22 mei 2004 @ 22:36:
hang daar eens [ code ] tags rond, dan is het al wat duidelijker

of druk op view message?

[paQ]

het lijkt wel of linux er bij ieder wissewasje er een paar MB afsnoept en niet meer vrij maakt.

bijv.:
na reboot 184 MB
ik start Mozilla en hij loopt naar de 216
sluit ik deze af, dan loopt die maar terug naar 204
evolution openen > 238
aflsuiten > 230

dat soort dingen

[Wilke]

Ik heb het sterke vermoeden dat je dit eens moet gaan doorlezen:

NOS FAQ: Waarom zit in Linux altijd mijn geheugen (bijna) vol?

[ Voor 32% gewijzigd door Wilke op 23-05-2004 12:10 ]

[odysseus]

Dat is natuurlijk de reden dat het geheugen vol zit of lijkt te zitten, maar het verklaart niet waarom Mozilla er zo lang over doet om op te starten .

Duurt het overigens ook zo lang als je een programma opstart dat geen internetverbinding nodig heeft? Denk aan een simpel spel of zo, of een teksteditor .

[Papillon]

Het komt ook wel eens voor dat mozilla traag start bij verkeerde netwerk instellingen. Check je DNS config (/etc/resolv.conf) Probeer eens met een host <DNS-entry> of het resolven van DNS adressen vlotjes verloopt.

Of check de gateway instellingen m.b.v. bijv. route. Als die niet goed staat kan het ook weer effe duren eer ie klaar is.. Is het wel OK dan heeft ie in een fractie van een seconde de hele routetabel.

[paQ]

nou andere programma's doen er ook niet echt kort over...

wacht... ik ga nu testen...

mozilla vanaf een reboot duurde 26 sec.
evolution 22
tekstverwerker van open office 1.1 18 sec.

nu deze eenmaal geopend zijn geweest nog eens:

mozilla 4
evolution 33
tekstverwerker 4

[ Voor 12% gewijzigd door paQ op 23-05-2004 22:35 ]

[Confusion]

Open Office.org in 18 seconden is voor mij snel, terwijl Mozilla in 26 voor mij langzaam is. Mijn specs zijn 1.3 Ghz / 768 Mb. Ik vind het persoonlijk niet erg, aangezien het daarna inderdaad maar een paar seconden is.

[MSalters]

Klinkt als het standaard ELF .so probleem; zie http://www.ukuug.org/even...2/papers/pdf/dsohowto.pdf

Kort gezegd, tijdens het laden van Mozilla moet je in Linux (en alle andere OSen die ELF gebruiken) veel meer namen checken dan in Windows.

[odysseus]

Op mijn oude Slot A Athlon (op 770MHz, met extern L2-cache) staat Mozilla er binnen tien seconden en dat vind ik al behoorlijk traag - een halve minuut op een machine die minstens drie keer sneller is lijkt me geen kwestie van 'normale' lookups of wat dan ook, daar zit echt wel een probleem .

De beste manier om achter de oorzaak te komen is door eens 'strace -tt -o strace_mozilla.log mozilla' te draaien en het bestand 'strace_mozilla.log' ergens online te zetten en het hier te posten. In dat bestand is vrij eenvoudig te zien waar precies zoveel tijd in gaat zitten en hoe dat opgelost kan worden .

[Rembrand20]

Linux gebruikt meestal al je geheugen.
Hij gaat pas vrijgeven als het ook nodig is.

Maar post het comamndo free -m en top eens.

[paQ]

code:

[paq@f216125 paq]$ free -m
             total       used       free     shared    buffers     cached
Mem:           501        239        262          0         12        121
-/+ buffers/cache:        106        395
Swap:         1019          0       1019


[paq@f216125 paq]$ free top
             total       used       free     shared    buffers     cached
Mem:        513828     245320     268508          0      12312     124284
-/+ buffers/cache:     108724     405104
Swap:      1044184          0    1044184

edit:

nou

nu kost een herstart van mozilla ook 20 sec.

ik vind een simpele feature als je browser od mail starten dat tegen de halve minuut aanloopt gewoon weg zo traag als dikke stront berg-op

[ Voor 17% gewijzigd door paQ op 24-05-2004 18:26 ]

[odysseus]

paQ schreef op 24 mei 2004 @ 17:59:
edit:

nou

nu kost een herstart van mozilla ook 20 sec.

ik vind een simpele feature als je browser od mail starten dat tegen de halve minuut aanloopt gewoon weg zo traag als dikke stront berg-op

Zoals ik al eerder zei: dat is dus ook niet normaal, alleen de oorzaak is nog onbekend. Met dat strace-commando zou het mogelijk moeten zijn om daar achter te komen .

[paQ]

dat strace commando is dus unknown

[ Voor 3% gewijzigd door paQ op 26-05-2004 21:01 ]

[odysseus]

Dan moet je even de Red Hat-variant van "apt-get install strace" draaien - even installeren dus . Met strace zou dit echt zo ontdekt en daarna hopelijk opgelost moeten zijn .

[slager]

Welke windowmanager gebruik je? Ik heb zelf met de laatste KDE-versies (3.2.0 en 3.2.1) ook gehad dat alles op onverklaarbare wijze erg traag was/werd. Terwijl GNOME gewoon soepel liep op hetzelfde systeem.

offtopic:
Ben sindsdien overgestapt op GNOME, en wil nu trouwens ook niet meer anders.

[froggie]

odysseus, ga die jongen nou niet in de war brengen met je 'apt-get install strace'
Maar slinger idd ff de RPM manager van RH aan en install 'strace'. Heb het laatst zelf ook gebruikt en is een zeer handige tool als je alle andere opties al geprobeerd hebt (of eerder natuurlijk).

[jaapbrandhof]

Ik weet niet 100% zeker hoor, maar maakt de installatie van linux standaard een swap space aan?

Zo niet, misschien is deze dan totaal vergeten.

[slager]

Als het [n00b] in de titel klopt, is hij niet met DiskDruid bezig gegaan, en heeft de installatie dus zelf een swap aangemaakt.

[paQ]

Bij het indelen van de partities is er inderdaad een Swap aprtitie aangemaakt.
of hebben jullie het nu weer over een andere Swap

Ik zal het vanavond nog eens even proberen te installeren. (strace)

Alhoewel het gisteren plotsklaps allemaal heel snel ging ineens
_{en dat [n00b] klopt wel wat betreft Linux}

offtopic:
shut up dreeke

[ Voor 14% gewijzigd door paQ op 27-05-2004 12:13 ]

[paQ]

Froggie schreef op 26 mei 2004 @ 23:30:
odysseus, ga die jongen nou niet in de war brengen met je 'apt-get install strace'
Maar slinger idd ff de RPM manager van RH aan en install 'strace'. Heb het laatst zelf ook gebruikt en is een zeer handige tool als je alle andere opties al geprobeerd hebt (of eerder natuurlijk).

Bij de RPM staat strace er niet bij

en apt-get herkent ie niet

gisteravond was alles ineens retesnel
booten, programmaś starten, zelf het openen van mappen ging vlot.

allemaal dingen die nu een eeuwigheid duren.
Over het openen van een map moet ie soms wel 20 seconden nadenken

[PierreAronnax]

Zoals het op de site van ClarkConnect staat:

Why does my system use so much memory?

From the Linux Journal -- "When extra physical memory is not in use, the kernel attempts to put it to work as a disk buffer cache. The disk buffer stores recently accessed disk data in memory; if the same data is needed again it can be quickly retrieved from the cache, improving performance. The buffer grows and shrinks dynamically to use the memory available, although priority is given to using the memory for paging. Thus, all the memory you have is put to good use. " -- Full Article

en:

Voor snelheid en efficiency, wordt al het beschikbare Fisiek geheugen(RAM) gebruikt om toegansgtijd en bestandsdoorvoer te versnellen. In andere woorden, het is normaal dat dus het geheugengebruik meestal boven de 90% ligt...

[ Voor 22% gewijzigd door PierreAronnax op 27-05-2004 20:26 ]

[paQ]

maar dat verklaart nog steeds niet waarom het systeem zo ontieglijk langzaam is.
Voor ik dit berichtje tikte heb ik gereboot. Evolution opstarten duurde net 48 sec

[Papillon]

Hoe performt je disk eigenlijk?

Probeer eens een hdparm -t /dev/hda

Misschien kun je ook inzicht geven op de hardwarwe die je ervoor gebruikt. M.a.w. wat voor controller?

[paQ]

Papillon schreef op 27 mei 2004 @ 20:38:
Hoe performt je disk eigenlijk?

Probeer eens een hdparm -t /dev/hda

Misschien kun je ook inzicht geven op de hardwarwe die je ervoor gebruikt. M.a.w. wat voor controller?

weer een commando dat niet wordt herkend...

(het zegt mij ook niets btw)

[Papillon]

Ben je wel root als je hdparm draait?

Als gebruiker kan je dat tooltje inderaad niet gebruiken. Een tandaard Linux installatie heeft dit tooltje geinstalleerd. Dat valt onder RedHat en/of SuSe te checken met "rpm -qa|grep hdparm". Als dat geen resultaat oplevert heb je het waarschijnlijk niet geinstalleerd.

[paQ]

Papillon schreef op 27 mei 2004 @ 20:55:
Ben je wel root als je hdparm draait?

Als gebruiker kan je dat tooltje inderaad niet gebruiken. Een tandaard Linux installatie heeft dit tooltje geinstalleerd. Dat valt onder RedHat en/of SuSe te checken met "rpm -qa|grep hdparm". Als dat geen resultaat oplevert heb je het waarschijnlijk niet geinstalleerd.

dat veranderd de zaak

code:

/dev/hda:
 Timing buffered disk reads:  64 MB in  1.13 seconds = 56.64 MB/sec
[root@f216125 root]#

[Papillon]

Eh.. Kun je het volgende naar mijn mail-adres sturen?

- Inhoud /var/log/messages
- Inhoud /var/log/boot.log

[odysseus]

paQ schreef op 27 mei 2004 @ 20:08:
[...]


Bij de RPM staat strace er niet bij

en apt-get herkent ie niet

Voor een RPM:
http://www.rpmfind.net//l...strace-4.4.95-2.i386.html

En apt-get wordt niet herkend omdat het een tool is van Debian, niet van Red Hat - mijn bericht was daar blijkbaar minder duidelijk over dan ik zelf dacht .

[paQ]

odysseus schreef op 27 mei 2004 @ 22:48:
[...]

Voor een RPM:
http://www.rpmfind.net//l...strace-4.4.95-2.i386.html

En apt-get wordt niet herkend omdat het een tool is van Debian, niet van Red Hat - mijn bericht was daar blijkbaar minder duidelijk over dan ik zelf dacht .

oh

ga ik vanavond ook weer naar kijken

Papillon schreef op 27 mei 2004 @ 22:13:
Eh.. Kun je het volgende naar mijn mail-adres sturen?

- Inhoud /var/log/messages
- Inhoud /var/log/boot.log

gemaild...
was niets aan de hand (naar het schijnt)

[ Voor 25% gewijzigd door paQ op 28-05-2004 08:11 ]

[DeMoN]

Waarom niet ff online zetten dan?

Dan kunnen er iig 100000 users meekijken ipv 1tje

[Martin Sturm]

Wat voor chipset gebruik je?
Dat kan namelijk best wel uitmaken..

[paQ]

DeMoN schreef op 28 mei 2004 @ 11:25:
Waarom niet ff online zetten dan?

Dan kunnen er iig 100000 users meekijken ipv 1tje

ik heb nog geen upload mogelijkheid ingesteld in redhat
daarbij scheen er niets aan de hand te zijn met de inhoud van die bestanden...

Martin Sturm schreef op 28 mei 2004 @ 11:44:
Wat voor chipset gebruik je?
Dat kan namelijk best wel uitmaken..

VIA

[ Voor 22% gewijzigd door paQ op 28-05-2004 12:39 ]

[Papillon]

Probeer eens het volgende:

Zet een terminal open en start daar het comaando "top". Die geeft een overzicht van de lopende processen en system load. Deze gegevens worden eens in de zoveel tijd ververst.

Start vervolgens mozilla en bekijk dan de resultaten van top. Vallen er dan bepaalde processen op die bijv. een hoge load vergen?

Als er een proces is dat veel load vraagt welke is dat dan? Zijn er geen processen die een hoge load vragen, dan is het meest waarschijnlijke dat er ergens een timeout zit.

Een ander punt wat het starten van mozilla traag kan maken is een grote hoeveelheid aan plugins. Kun je daarom ook kijken hoe het staat met de plugins die mozilla heeft? (help -> About Plugins)

Op mijn systeem met een langzamere disk en 512 MB duurt het (1e keer) starten van mozilla echt niet meer dan 4 sec. Dat is echter wel zonder java en rataplan.

[paQ]

Papillon schreef op 28 mei 2004 @ 17:01:
Probeer eens het volgende:

Zet een terminal open en start daar het comaando "top". Die geeft een overzicht van de lopende processen en system load. Deze gegevens worden eens in de zoveel tijd ververst.

Start vervolgens mozilla en bekijk dan de resultaten van top. Vallen er dan bepaalde processen op die bijv. een hoge load vergen?

Als er een proces is dat veel load vraagt welke is dat dan? Zijn er geen processen die een hoge load vragen, dan is het meest waarschijnlijke dat er ergens een timeout zit.

Een ander punt wat het starten van mozilla traag kan maken is een grote hoeveelheid aan plugins. Kun je daarom ook kijken hoe het staat met de plugins die mozilla heeft? (help -> About Plugins)

Op mijn systeem met een langzamere disk en 512 MB duurt het (1e keer) starten van mozilla echt niet meer dan 4 sec. Dat is echter wel zonder java en rataplan.

er zit niets bij wat eruit piekt

de ene keer duurt het 20 seconden, de andere keer 48, een keer meegemaakt dat alles met een paar seconden klaar stond...

daarbij is het niet enkel mozilla, maar alle programma's EN uberhaupt door mappen gaan in het systeem.
Dubbelklik op een map: 15 seconden wachten en dan pas de inhoud