Kijken hoeveel Kb mem ieder proces gebruikt

[_-= Erikje =-_]

Mijn geheugen gebruik is spontaan van +- 15 mb naar 40 gesprongen en nu wil ik graag weten hoe dat komt, met ps -aux zie je alleen percentages, als ik daar de hoogste percentages kill (apache, mysql) dan zakt het geheugen gebruik nog maar enkele mb's

[RemcoX]

Kun je zien met 'top'. Type 'M' om te sorteren op memory, en kijk dan in de kolom 'SIZE'.

Uit 'man top':

code:

 SIZE The size of the task's  code  plus  data  plus  stack
        space, in kilobytes, is shown here.

BTW, let erop dat je ook nog zoiets als cache hebt, dat geheugen eet.

[BallisticToilet]

Je kunt ook:

ps -Ao vsz -o comm|sort -dn|tail -10

Hiermee krijg je de 10 meest slurpende processen op aflopende grootte.

[RemcoX]

Op maandag 31 december 2001 14:26 schreef BallisticToilet het volgende:
Je kunt ook:

ps -Ao vsz -o comm|sort -dn|tail -10

Hiermee krijg je de 10 meest slurpende processen op aflopende grootte.

Dat noem ik oplopende grootte.

Gebruik -r bij sort om aflopende volgorde te krijgen.

[BallisticToilet]

Ehhhrmm,

Vergeet je dan niet even die tail te veranderen in een head?? Anders krijg je de tien kleinste processen

Bovendien is het maar waarvandaan je begint te lezen.

oplopend, aflopend, whatever...

[RemcoX]

Op maandag 31 december 2001 14:40 schreef BallisticToilet het volgende:
Vergeet je dan niet even die tail te veranderen in een head?? Anders krijg je de tien kleinste processen

Ook dat nog eens ja...

Bovendien is het maar waarvandaan je begint te lezen.

Naja, volgens mij is het toch vrij gebruikelijk om een rij groter wordende getallen oplopend te noemen in plaats van aflopend. (ascending dus, niet te verwarren met increasing )

[BallisticToilet]

Ik bedoel dus: Als je in die one-liner alleen de -d in een -r veranderd, krijg je de 10 kleinste processen.

Oh en eh, het is ascending versus descending.

Dus zijn we het er over eens dat het moest zijn:

ps -Ao vsz -o comm|sort -rn|head -10 ??

[RemcoX]

Op maandag 31 december 2001 14:55 schreef BallisticToilet het volgende:
Ik bedoel dus: Als je in die one-liner alleen de -d in een -r veranderd, krijg je de 10 kleinste processen.

Dat klopt, maar dat beaamde ik in mijn vorige post toch ook al?

Oh en eh, het is ascending versus descending.

Desondanks moet je ascending niet verwarren met increasing.

Dus zijn we het er over eens dat het moest zijn:

ps -Ao vsz -o comm|sort -rn|head -10 ??

yep (niet te verwarren met j3p )

[deadinspace]

Op maandag 31 december 2001 14:19 schreef RemcoX het volgende:
BTW, let erop dat je ook nog zoiets als cache hebt, dat geheugen eet.

^^^^^^^^^^^^^

Topicstarter: post de output van 'free -m' eens.

[_-= Erikje =-_]

komt ie

code:

root@voyager:/etc# free -m
         total   used    free     shared    buffers     cached
Mem:        61     31      30       0       1      22
-/+ buffers/cache:      7      53
Swap:       129     0     129

[deadinspace]

Hehe, you need not worry

De kernel beheert het geheugen. Programma's vragen geheugen aan de kernel en krijgen dit toegewezen.

Programma's openen files, zowel om te lezen als om te schrijven. Maar sommige files worden heel vaak gelezen of geschreven. Blocks (stukjes file) die vaak van de HD worden gelezen, worden door de kernel in het geheugen gehouden. Als er dan nog eens een programma langskomt dat die block nodig heeft, hoeft de kernel het maar uit het geheugen te halen (en dat gaat VEEL sneller dan van de harddisk). Dit heet cachen.

Ook kan het voorkomen dat een programma heel veel schrijft naar een file, maar omdat HDs langzaam zijn zou het programma telkens maar een beetje kunnen schrijven en wachten, schrijven en wachten, enz. In plaats daarvan zegt het programma tegen de kernel 'Hier, deze 5 MB wil ik in die file hebben, regel maar'. De kernel plaatst dit in zijn geheugen en doet naar het programma toe alsof het weggeschreven is (wat dus vrijwel onmiddelijk gebeurt). Dan gaat de kernel pas naderhand de data werkelijk wegschrijven (en wel zo dat het zoveel mogelijk gebeurt tijdens het uitvoeren van andere dingen, 'op de achtergrond' zeg maar). Dit heet bufferen.

Buffering en caching wordt door de kernel beheerd. Dit goed balanceren is erg moeilijk, maar de Linux kernel doet dit over het algemeen gelukkig heel aardig - je hoeft je er niet druk over te maken of je het bij moet regelen ofzo, jij en ik kunnen dat niet beter dan de kernel zelf. Buffering en caching zijn overigens HEEL belangrijk voor de performance (als je je DOS met en zonder SMARTDRV kan herinneren ken je het verschil).

In de output van 'free' staat in de bovenste regel hoeveel geheugen er in totaal in gebruik is, dus inclusief caches en buffers. Dit getal zal altijd groeien naarmate je bak langer aanstaat, tot ongeveer alles in gebruik is. Dit is volkomen normaal gedrag.
Een regel lager staat hoeveel geheugen in gebruik is zonder caches en buffers (dus zo'n beetje hoeveel in gebruik is door programma's).

In jouw geval is 31 van de 61 MB in gebruikt (je bak staat dus nog geen jaren aan ), en slechts 7 MB voor programma's (dat is niet veel).

Iets voor de FAQ misschien? (ga ik weer )

[_-= Erikje =-_]

thnx, is nu weer 11 meg totaal.

Dit zou idd niet verkeerd staan in de FAQ

[deadinspace]

Op maandag 31 december 2001 19:20 schreef _-= Erikje =-_ het volgende:
thnx, is nu weer 11 meg totaal.

Hoezo is het nu weer 11 meg?

[Apache]

Op dinsdag 01 januari 2002 02:45 schreef deadinspace het volgende:

[..]

Hoezo is het nu weer 11 meg?

check zijn eerste post

k'neem aan dat die 11MB weer het deel van het geheugen is dat echt gebruikt is, dus totaal - caching, raar dat mensen zo naar hun geheugen kijken imo

[deadinspace]

Ow zo... Ik dacht dattie misschien gereboot had ofzo... Dan had ik toch echt nog even moeten vertellen dat dat niet nodig is

[_-= Erikje =-_]

eerst was er normaal gesproken altijd 11-20 meg in gebruik, toen plotsling 40 en nu weer gewoon 11

[deadinspace]

Mmz, hier loopt het eigenlijk nooit zo drastisch terug... Het kan zijn dat hij om de een of andere reden even grote buffers nodig had en die nu geflusht heeft...