RedHat 7.1 vreet geheugen

[Verwijderd]

Na wat verhalen gelezen te hebben dacht ik dat een P200MMX met 64Mb meer dan voldoende zou moeten zijn om hem onder Linux (Red Hat 7.1) te laten fungeren als router (NAT), firewall, dhcp, web- en ftp-server -- volgens mij is de configuratie zelfs ruim, en is dit al te doen op een 486 met 16 Mb.

Heb nu Red Hat geinstalleerd en alleen de firewall geconfigureerd, gebruikt 't ding toch al meer dan 50 Mb geheugen wat me eigenlijk wat veel lijkt.

X staat er niet op, veel andere services draaien er volgens mij niet (gekeken met lsmod). Wel heb ik (misschien minder handig) bij Red Hat gekozen voor "Server install". Komt het door dit laatste, is het zowieso normaal of valt er wat aan te verbeteren?

[warp]

Linux gebruikt een heel groot deel van je geheugen als cache. Dit wordt weer vrijgegeven als apps het nodig hebben.

Post anders even de output van top.

[Verwijderd]

In principe wordt al je geheugen gereserveerd als buffer of als cached.
Dus het is normaal dat er weinig free memory overblijft.

Maar welke services draai je precies?
Met lsmod kun je alleen de geladen kernelmodules uitlezen.
Probeer eens ps ax. Dat geeft een processlist.

Services kun je uitzetten met chkconfig --list en chkconfig --del <service>
Wil je ze nu uithebben, en niet de volgende boot, gebruik dan service:
service <service> stop

[Verwijderd]

Linux gebruikt een heel groot deel van je geheugen als cache. Dit wordt weer vrijgegeven als apps het nodig hebben.

Als ik een paar applicaties open begint het ding te swappen, maakt het onwaarschijnlijk dat het vele geheugengebruik komt door allocatie voor cache (toch? - ipv te swappen zou hij het dan moeten vrijgeven).

Zit niet bij die machine nu, mail je vanavond output van top commando (wat doet dat?)

[odysseus]

Zou je dan ook meteen de output van 'ps aux' en 'free -m' kunnen bekijken? Vooral 'free -m' is interessant, dat laat het geheugengebruik zien, met apart vermeld hoeveel er gecached/gebufferd en dergelijke is.

[active2]

met lsmod zie je niet welke services allemaal lopen

Het enige wat je daarmee kan zien is of er modules zijn geladen ja of nee!

Waar je wel even kan kijken is in een van de runlevels van je systeem (weet niet waar het staat ik draai Debian)!

Met ps aux kun je zien wat het meeste trekt!

Ik heb Debian zelf draaien op een 386 met 4Mb geheugen en hij draait als caching only nameserver en dat draait goed! (alhoewel hij wel wat sneller kan hoor)...

Post de output van ps aux maar eens!

[deadinspace]

Op donderdag 21 februari 2002 15:18 schreef active2 het volgende:
met lsmod zie je niet welke services allemaal lopen

Klopt, maar niemand had het over lsmod

Post de output van ps aux maar eens!

'ps auxf' dan het liefst (met die f zie je makkelijk welke processes children zijn van andere), en dan het liefst tussen [ code ] [ /code ] tags (mits het niet fout gaat met de enters zoals laatst bij iemand ).

[odysseus]

Op donderdag 21 februari 2002 17:07 schreef deadinspace het volgende:
Klopt, maar niemand had het over lsmod

RTFM! Read The Fine Message . De topicstarter vertelde dat hij gekeken had welke services er draaiden met het commando 'lsmod'...

[deadinspace]

Op donderdag 21 februari 2002 17:18 schreef odysseus het volgende:
RTFM! Read The Fine Message . De topicstarter vertelde dat hij gekeken had welke services er draaiden met het commando 'lsmod'...

Ow, idd overheen gelezen.

[Papillon]

Als je ook de volgende output ziet van free:

total used free shared buffers cached
Mem: 384468 378708 5760 64 33424 267852
-/+ buffers/cache: 77432 307036
Swap: 265064 0 265064

Dan betekent het niet per definitie dat ie maar 5.7 MB vrij heeft. 5.7 MB is ongebruikt zeg maar. wat vrij is voor apps staat onder free in de rij -/+ buffers/cache. In dit geval dus 307036 KB. En dus is 77432 in gebruik.

[Verwijderd]

Bijgaand de output van achtereenvolgens free, ps auxf en top. Lijkt er inderdaad op dat het meeste geheugen wordt gebruikt voor cache/buffers, niet voor applicaties (used: 40936, buffers 1408, cached 30880).

free:

code:

         total   used    free     shared    buffers     cached
Mem:       62284    40936   21348       0    1408   30880
-/+ buffers/cache:   8648   53636
Swap:    161240     0     161240

ps auxf:

code:

USER     PID %CPU %MEM   VSZ  RSS TTY   STAT START   TIME COMMAND
root       1  0.5  0.8  1340  512 ?   S    09:10   0:03 init [3] 
root       2  0.0  0.0     0    0 ?   SW   09:10   0:00 [keventd]
root       3  0.0  0.0     0    0 ?   SW   09:10   0:00 [kapm-idled]
root       4  0.0  0.0     0    0 ?   SW   09:10   0:00 [kswapd]
root       5  0.0  0.0     0    0 ?   SW   09:10   0:00 [kreclaimd]
root       6  0.0  0.0     0    0 ?   SW   09:10   0:00 [bdflush]
root       7  0.0  0.0     0    0 ?   SW   09:10   0:00 [kupdated]
root       8  0.0  0.0     0    0 ?   SW<  09:10   0:00 [mdrecoveryd]
root      73  0.0  0.0     0    0 ?   SW   09:10   0:00 [khubd]
root     361  0.0  0.0     0    0 ?   SW   09:11   0:00 [eth0]
root     445  0.0  0.0     0    0 ?   SW   09:11   0:00 [eth1]
root     509  0.0  1.0  1400  624 ?   S    09:11   0:00 syslogd -m 0
root     514  0.0  1.8  1952 1132 ?   S    09:11   0:00 klogd -2
rpc   528  0.0  0.9  1484  580 ?      S    09:11   0:00 portmap
rpcuser    543  0.0  1.2  1536  760 ?     S    09:11   0:00 rpc.statd
root     662  0.0  1.0  1452  628 ?   S    09:11   0:00 /usr/sbin/automou
root     674  0.0  1.5  2204  944 ?   S    09:11   0:00 xinetd -stayalive
root     747  0.0  1.3  1684  812 ?   S    09:13   0:00  \_ in.telnetd: 1
root     748  0.0  1.7  2272 1080 pts/0    S    09:14   0:00    \_ login -- 
root     749  0.0  2.1  2360 1312 pts/0    S    09:14   0:00        \_ -bash
root     783  0.0  1.0  2552  684 pts/0    R    09:22   0:00          \_ p
root     689  0.0  0.7  1368  484 ?   S    09:11   0:00 gpm -t ps/2 -m /d
root     739  0.0  0.6  1312  432 tty1     S    09:11   0:00 /sbin/mingetty tt
root     740  0.0  0.6  1312  432 tty2     S    09:11   0:00 /sbin/mingetty tt
root     741  0.0  0.6  1312  432 tty3     S    09:11   0:00 /sbin/mingetty tt
root     742  0.0  0.6  1312  432 tty4     S    09:11   0:00 /sbin/mingetty tt
root     743  0.0  0.6  1312  432 tty5     S    09:11   0:00 /sbin/mingetty tt
root     744  0.0  0.6  1312  432 tty6     S    09:11   0:00 /sbin/mingetty tt

top:

code:

  9:23am  up 13 min,  1 user,  load average: 0.00, 0.00, 0.00
28 processes: 27 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  0.3% user,  0.1% system,  0.0% nice, 99.4% idle
Mem:    62284K av,   41188K used,   21096K free,     0K shrd,    1412K buff
Swap:  161240K av,   0K used,  161240K free          30976K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  784 root  18   0   996  996   812 R     0.5  1.5   0:00 top
    1 root   8   0   512  512   444 S     0.0  0.8   0:03 init
    2 root   8   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root   9   0     0    0     0 SW    0.0  0.0   0:00 kapm-idled
    4 root   9   0     0    0     0 SW    0.0  0.0   0:00 kswapd
    5 root   9   0     0    0     0 SW    0.0  0.0   0:00 kreclaimd
    6 root   9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    7 root   9   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    8 root  -1 -20     0    0     0 SW<   0.0  0.0   0:00 mdrecoveryd
   73 root   9   0     0    0     0 SW    0.0  0.0   0:00 khubd
  361 root   9   0     0    0     0 SW    0.0  0.0   0:00 eth0
  445 root   9   0     0    0     0 SW    0.0  0.0   0:00 eth1
  509 root   9   0   624  624   528 S     0.0  1.0   0:00 syslogd
  514 root   9   0  1132 1132   440 S     0.0  1.8   0:00 klogd
  528 rpc     9   0   580  580   496 S     0.0  0.9   0:00 portmap
  543 rpcuser    9   0   760  760   656 S     0.0  1.2   0:00 rpc.statd
  662 root   9   0   628  628   528 S     0.0  1.0   0:00 automount

[odysseus]

Niets om je zorgen over te maken...die machine staat gewoon uit zijn neus te vreten eigenlijk . Weinig processen, load average van nul en nog meer dan genoeg vrij RAM, om nog maar niet over swap te beginnen...

[ACM]

Evt, kan je nog dezelfde overzichten plaatsen wanneer je enkele applicaties opent en je denkt dat ie aan het swappen is...

Soms is het zo dat de kernel beslist dat het toch efficienter is om te swappen dan om de cache te verkleinen.

[Verwijderd]

Op vrijdag 22 februari 2002 09:16 schreef odysseus het volgende:
Niets om je zorgen over te maken...die machine staat gewoon uit zijn neus te vreten eigenlijk . Weinig processen, load average van nul en nog meer dan genoeg vrij RAM, om nog maar niet over swap te beginnen...

Gelukkig maar. Had zelf het idee (zie topic start) dat het (vermeende) exorbitante geheugengebruik wel eens zou kunnen komen doordat ik een Red Hat "server install" had gedaan, en wilde dus een "custom" herinstallatie doen. Maar als ik het goed begrijp gaat dat me dus alleen meer vrije diskspace opleveren, en een hoop moeite kosten?

[Verwijderd]

Op vrijdag 22 februari 2002 09:24 schreef Mr.Unbreakable het volgende:

[..]

Gelukkig maar. Had zelf het idee (zie topic start) dat het (vermeende) exorbitante geheugengebruik wel eens zou kunnen komen doordat ik een Red Hat "server install" had gedaan, en wilde dus een "custom" herinstallatie doen. Maar als ik het goed begrijp gaat dat me dus alleen meer vrije diskspace opleveren, en een hoop moeite kosten?

Zoiets ja

[ACM]

Op vrijdag 22 februari 2002 09:24 schreef Mr.Unbreakable het volgende:
Maar als ik het goed begrijp gaat dat me dus alleen meer vrije diskspace opleveren, en een hoop moeite kosten?

Ik denk dat het zelfs kwa diskspace niet zo veel uitmaakt. Maar aangezien exact dezelfde kernel geinstalleerd wordt zal het (erg efficiente waarom zou je geheugen vrijhouden als je het toch niet gebruikt...) geheugen gebruik niet veranderen.

Overigens doe ik zelf altijd een custom install omdat ik graag dat beetje controle dat er nog mogelijk is bij redhat wel wil behouden

[odysseus]

Of het inderdaad een hoop moeite is weet ik niet, maar het enige echte voordeel zal inderdaad wat meer vrije schijfruimte zijn. Je zou nog even die rpc-daemon uit kunnen schakelen, die gebruik je toch waarschijnlijk niet en het scheelt weer wat RAM en maakt het misschien weer wat veiliger...