Limiteren van geheugen-gebruik?

[aKra]

Ik zit hier met een probleem, ik doe sinds kort erg veel voor het Distributed Computing project D2OL want ze hadden gelukkig een LINUX client. Maar ik zit nu met een probleem, op elke LINUX server/pc gebruiken ze gewoon al het overgebleven RAM als cache?

Ik ben in de client zelf gaan zoeken, maar daar heb ik er niks over teruggevonden.

Ook Google.nl maakte me niks wijs, alleen verhalen om de kernel te compilen met virtual "users/servers" op een PC... Maar daar zoek ik niet echt naar

Bestaan er programma's voor LINUX (Debian, Slackware en Gentoo) net zoals 'nice' (deze is alleen voor de CPU usage) om het geheugengebruik van applicaties te beperken?

(Praktijk voorbeeld van processen:)

code:

horus:~# free -m
             total       used       free     shared    buffers     cached
Mem:          2024       1944         80          0         48       1244
-/+ buffers/cache:        650       1373
Swap:         1953          0       1953
horus:~#

code:

horus:~# ps aux
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
-knip-
root       308  0.0  0.0  2480 1356 ?        S    Apr20   0:01 SCREEN -S d2ol-1
root       309  0.0  0.0  2092 1012 pts/2    SN   Apr20   0:00 /bin/sh ./D2OL/D2
root       350  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       351  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       352  0.0  1.9 286424 39776 pts/2  SN   Apr20   1:37 /root/d2ol-1/jre/
root       353  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       354  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:01 /root/d2ol-1/jre/
root       355  0.0  1.9 286424 39776 pts/2  RN   Apr20   1:24 /root/d2ol-1/jre/
root       356  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       357  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       358  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:02 /root/d2ol-1/jre/
root       359  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       362  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       363  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:12 /root/d2ol-1/jre/
root       364  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       367  0.0  0.0  2484 1360 ?        S    Apr20   0:01 SCREEN -S d2ol-2
root       368  0.0  0.0  2092 1012 pts/3    SN   Apr20   0:00 /bin/sh ./D2OL/D2
root       409  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       410  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:03 /root/d2ol-1/jre/
root       411  0.0  1.9 286424 39776 pts/2  SN   Apr20   6:10 /root/d2ol-1/jre/
root       413  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:07 /root/d2ol-1/jre/
root       416  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:01 /root/d2ol-2/jre/
root       417  0.0  1.9 286396 39976 pts/3  SN   Apr20   1:36 /root/d2ol-2/jre/
root       418  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       419  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:01 /root/d2ol-2/jre/
root       420  0.0  1.9 286396 39976 pts/3  RN   Apr20   1:24 /root/d2ol-2/jre/
root       421  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       422  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       423  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:02 /root/d2ol-2/jre/
root       424  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       427  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       428  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:12 /root/d2ol-2/jre/
root       429  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root       431  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:03 /root/d2ol-2/jre/
root       432  0.0  1.9 286396 39976 pts/3  SN   Apr20   6:35 /root/d2ol-2/jre/
root       434  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:07 /root/d2ol-2/jre/
root       496  0.0  1.9 286424 39776 pts/2  SN   Apr20   0:00 /root/d2ol-1/jre/
root       517  0.0  1.9 286396 39976 pts/3  SN   Apr20   0:00 /root/d2ol-2/jre/
root     22677  0.0  1.9 286396 39976 pts/3  SN   06:07   0:00 /root/d2ol-2/jre/
root     22725  0.0  1.9 286396 39976 pts/3  SN   06:08   0:00 /root/d2ol-2/jre/
root     22726  0.0  1.9 286396 39976 pts/3  SN   06:08   0:00 /root/d2ol-2/jre/
root     22727  0.0  1.9 286396 39976 pts/3  SN   06:08   0:00 /root/d2ol-2/jre/
root     22728 99.7  2.5 55200 52720 pts/3   RN   06:08  82:30 /root/d2ol-2/D2OL
root     25094  0.0  1.9 286424 39776 pts/2  SN   07:26   0:00 /root/d2ol-1/jre/
root     25127  0.0  1.9 286424 39776 pts/2  SN   07:27   0:00 /root/d2ol-1/jre/
root     25128  0.0  1.9 286424 39776 pts/2  RN   07:27   0:00 /root/d2ol-1/jre/
root     25129  0.0  1.9 286424 39776 pts/2  SN   07:27   0:00 /root/d2ol-1/jre/
root     25130 99.9  2.5 55184 52688 pts/2   RN   07:27   6:10 /root/d2ol-1/D2OL
-knip-

code:

horus:~# top
top - 07:32:38 up 7 days, 19:10,  4 users,  load average: 2.62, 2.43, 2.31
Tasks: 111 total,   6 running, 105 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0% us,  0.0% sy, 99.8% ni,  0.0% id,  0.0% wa,  0.2% hi,  0.0% si
Mem:   2072636k total,  1991040k used,    81596k free,    49816k buffers
Swap:  2000084k total,        0k used,  2000084k free,  1274688k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25130 root      39  19 55184  51m 1812 R 99.9  2.5   8:00.74 DockWin.exe
22728 root      39  19 55200  51m 1812 R 98.1  2.5  84:19.66 DockWin.exe
  308 root      16   0  2480 1356 1940 S  0.0  0.1   0:01.33 screen
  309 root      39  19  2092 1012 1964 S  0.0  0.0   0:00.04 D2OL
  350 root      35  19  279m  38m  37m S  0.0  1.9   0:00.39 java
  351 root      34  19  279m  38m  37m S  0.0  1.9   0:00.90 java
  352 root      34  19  279m  38m  37m S  0.0  1.9   1:37.00 java
  353 root      34  19  279m  38m  37m S  0.0  1.9   0:00.75 java
  354 root      34  19  279m  38m  37m S  0.0  1.9   0:01.07 java
  355 root      34  19  279m  38m  37m S  0.0  1.9   1:24.50 java
  356 root      36  19  279m  38m  37m S  0.0  1.9   0:00.00 java
  357 root      36  19  279m  38m  37m S  0.0  1.9   0:00.00 java
  358 root      34  19  279m  38m  37m S  0.0  1.9   0:02.17 java
  359 root      35  19  279m  38m  37m S  0.0  1.9   0:00.77 java
  362 root      36  19  279m  38m  37m S  0.0  1.9   0:00.00 java
  363 root      34  19  279m  38m  37m S  0.0  1.9   0:12.26 java
  364 root      39  19  279m  38m  37m S  0.0  1.9   0:00.00 java
  367 root      16   0  2484 1360 1940 S  0.0  0.1   0:01.16 screen
  368 root      39  19  2092 1012 1964 S  0.0  0.0   0:00.04 D2OL
  409 root      35  19  279m  39m  37m S  0.0  1.9   0:00.42 java
  410 root      34  19  279m  38m  37m S  0.0  1.9   0:03.23 java
  411 root      35  19  279m  38m  37m S  0.0  1.9   6:10.53 java
  413 root      34  19  279m  38m  37m S  0.0  1.9   0:07.30 java
  416 root      34  19  279m  39m  37m S  0.0  1.9   0:01.02 java
  417 root      34  19  279m  39m  37m S  0.0  1.9   1:36.20 java
  418 root      34  19  279m  39m  37m S  0.0  1.9   0:00.70 java
  419 root      34  19  279m  39m  37m S  0.0  1.9   0:01.08 java
  420 root      34  19  279m  39m  37m S  0.0  1.9   1:24.54 java
  421 root      37  19  279m  39m  37m S  0.0  1.9   0:00.00 java
  422 root      39  19  279m  39m  37m S  0.0  1.9   0:00.00 java
  423 root      34  19  279m  39m  37m S  0.0  1.9   0:02.17 java
  424 root      36  19  279m  39m  37m S  0.0  1.9   0:00.84 java
  427 root      36  19  279m  39m  37m S  0.0  1.9   0:00.00 java
  428 root      34  19  279m  39m  37m S  0.0  1.9   0:12.27 java
  429 root      39  19  279m  39m  37m S  0.0  1.9   0:00.00 java
  431 root      34  19  279m  39m  37m S  0.0  1.9   0:03.26 java
  432 root      35  19  279m  39m  37m S  0.0  1.9   6:35.49 java
  434 root      34  19  279m  39m  37m S  0.0  1.9   0:07.79 java
  496 root      34  19  279m  38m  37m S  0.0  1.9   0:00.00 java
  517 root      34  19  279m  39m  37m S  0.0  1.9   0:00.00 java
22677 root      35  19  279m  39m  37m S  0.0  1.9   0:00.02 java
22725 root      34  19  279m  39m  37m S  0.0  1.9   0:00.07 java
22726 root      34  19  279m  39m  37m S  0.0  1.9   0:00.03 java
22727 root      37  19  279m  39m  37m S  0.0  1.9   0:00.00 java
25094 root      35  19  279m  38m  37m S  0.0  1.9   0:00.02 java
25127 root      34  19  279m  38m  37m S  0.0  1.9   0:00.02 java
25128 root      34  19  279m  38m  37m S  0.0  1.9   0:00.00 java
25129 root      37  19  279m  38m  37m S  0.0  1.9   0:00.00 java

[Lancer]

Dat die processen het geheugen claimen hoeft op zich geen probleem te zijn. Als ze het maar weer teruggeven als een ander proces het nodig heeft. Ik denk dat je het beste alleen naar de performance kan kijken.

Een goede indicatie of het geheugengebruik een probleem is kun je krijgen met sar. Als je de gegevens voor de indicatoren paging en swapping vergelijkt met en zonder de client krijg je wat meer inzicht. Idealiter staat swapping altijd op 0. Als de client echt alle geheugen claimt, dan zou ik verwachten dat swapping daarna niet meer op 0 staat. (sar -BW geloof ik)

(paging: process data wordt uitgewisseld naar het swap geheugen. Iets dat ieder UNIX systeem altijd doet met processen die voor een langere tijd niet zijn aangesproken
swapping: data en proces header worden beide naar swap overgebracht. Dit zorgt voor veel vertraging.)

[Lief Adje]

Lancer schreef op 28 april 2004 @ 07:55:
Dat die processen het geheugen claimen hoeft op zich geen probleem te zijn. Als ze het maar weer teruggeven als een ander proces het nodig heeft. Ik denk dat je het beste alleen naar de performance kan kijken.

Hij gebruikt idd die hoeveelheid geheugen, en geeft die ook vrij als het ergens anders nodig is.

[Papillon]

Interpreteer de gegevens die free geeft wel op de juiste wijze:

code:

 horus:~# free -m
             total       used       free     shared    buffers     cached
Mem:          2024       1944         80          0         48       1244
-/+ buffers/cache:        650       1373
Swap:         1953          0       1953
horus:~#

In jouw situatie wordt wel 1944 MB aan memory gebruikt. Maar het deel dat door de applicaties gebruikt wordt is "slechts" 650 MB. De rest is voor buffers en cache. Zodra de applicaties meer ruimte nodig hebben zal deze door de buffers/cache worden vrijgegeven.

De praktijk heeft nl. geleerd dat de performance winst van de cache en buffers (anders staat de memory ook maar niets te doen) opwegen tegen de performance loss als gevolg van het moeten vrijgeven van memory (uit de cache/buffers) ter allocatie van de applicaties.

Maar om antwoord te geven op je vraag. Ik weet zelf nog niet van memory restricites aan applicaties. Wellicht kan je ook instellen hoeveel java threads (die slokken aardig wat mem weg) er mogen ontstaan om de memory gebruik door de applicaties terug te dringen.

[RemcoDelft]

Zoek eens op "limits"!

Verder heeft cache-gebruik niets met het programma te maken; dat doet je kernel. Enig nadeel zou zijn als een programma zeer veel diskactiviteit geeft, waardoor je "normale" filecache leeg is, en al je progjes weer van disk moeten komen...

[aKra]

Overigens, er zijn ook andere servers die wel gaan swappen, maar als ik het zo lees hoef ik dus nergens zorgen over te maken en is het dus zo dat het probleem ergens anders ligt?

(Er laggen hierdoor Counter-Strike gameservers, schijnt...)

[ajvdvegt]

offtopic:
Ik zou zo'n proggie niet als root gaan draaien trouwens...

[Wilke]

FAQ gelezen? FAQ Non-Windows Operating Systems - Overige vragen

[aKra]

Wilke schreef op 28 april 2004 @ 10:03:
FAQ gelezen? FAQ Non-Windows Operating Systems - Overige vragen

Waarom deze vraag

Er staat echt niks over een programma waar ik bijv. geheugen mee kan limiteren, overigens de vraag is niet wat het verschil is tussen gebruik/cachen etc., daar snap ik zelf wel genoeg van... Maar ik heb het idee dat het programma/linux gewoon de cache's niet loslaat.

ajvdvegt schreef op 28 april 2004 @ 09:30:

offtopic:
Ik zou zo'n proggie niet als root gaan draaien trouwens...

Zou ik mogen vragen waarom

(D2OL is niet remote bereikbaar, maar evt. met resources?)

[ Voor 23% gewijzigd door aKra op 28-04-2004 10:18 ]

[igmar]

aKra schreef op 28 april 2004 @ 10:17:
Waarom deze vraag

Omdat jouw vraag al tig keren is voorbijgekomen, met antwoorden.

Er staat echt niks over een programma waar ik bijv. geheugen mee kan limiteren, overigens de vraag is niet wat het verschil is tussen gebruik/cachen etc., daar snap ik zelf wel genoeg van... Maar ik heb het idee dat het programma/linux gewoon de cache's niet loslaat.

Limiten kun je doen met behulp van ulimit, hetgeen overigens niet werkt als dat proces als root draait. Verder is Java threaded, dus het gebruik wat er staat is totaal voor de threads, en niet per process / thread.

De caches worden geregeld door de kernel, en die is prima in staat dat zelf te regelen

[aKra]

Als deze vraag al zo vaak is langsgekomen, waarom kan ik dan niks vinden met Google/GoT search...

[Verwijderd]

wellicht omdat je de verkeerde search query's gebruikt. Iig is het zoals igmar zegt: Mbv ulimit kun je allerlei process limitaties instellen. Een voorbeeld van de limitaties in een normale shell sessie hier:

code:

sasami [r3boot]$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) unlimited
virtual memory        (kbytes, -v) unlimited

Lees de manual page ervan ook nog eens na, die leggen uit wat de limieten precies inhouden, en waar je rekening mee moet houden (hard/soft limits). Overigens is het file caching algoritme van linux niet echt tunebaar, maar dat doet normaal gesproken altijd z'n werk. Ook zouden normale memory allocaties prioriteit moeten hebben over filesystem cache..

[ Voor 7% gewijzigd door Verwijderd op 28-04-2004 10:48 ]

[aKra]

Ik zocht inderdaad naar 'ulimit', het zat ergens diep in mijn achterhoofd (vroeger nog wel eens shell providertje gespeeld namelijk ).

Overigens ga ik het nog eens proberen als ik D2OL als een normale user installeer, en anders gaan we maar eens met ulimit aan de slag

[Wilke]

aKra schreef op 28 april 2004 @ 10:17:
Waarom deze vraag

Nou, hierom: je zegt in je openingspost:

Maar ik zit nu met een probleem, op elke LINUX server/pc gebruiken ze gewoon al het overgebleven RAM als cache?

Nu blijkt in de praktijk meestal dat mensen die aangeven dat ze dit zien als een 'probleem' in plaats van een 'geweldig voordeel', meestal niet precies snappen hoe het caching/memory management in Linux werkt. Daarom dus die link.

ik heb het idee dat het programma/linux gewoon de cache's niet loslaat.

Hoe bedoel je dat? Al je geheugen is cache of gealloceerd (nou ja...meteen na startup is er nog een deel leeg omdat er gewoon nog niks te cachen viel). "Niet gebruikt" geheugen is totaal nutteloos geheugen, het verhoogt slechts je energierekening zonder dat je er verder iets aan hebt. Normaalgesproken zal een malloc() dus altijd ten koste gaan van een stukje cache, en wel bij voorkeur een stuk wat al lang niet is gebruikt. Zo hoort het te werken, en ik snap dus absoluut niet waarom je dat als een 'probleem' ziet. Je legt dat ook niet uit


Als je bedoelt dat je specifieke processen hebt die erg veel mem gebruiken (Java is daar soms idd vrij goed in) dan moet je dat zeggen. Java kun je bv. zelf opties meegeven die de hoeveelheid ruimte die hij maximaal neemt beperkt (-Xmx128m etc.). Zoals al opgemerkt lijkt het alsof elke thread veel geheugen gebruikt, maar dat is gewoon het totaal van al die threads. Ik zie dus dat je 2GB RAM in die bak hebt en dat er 1 java proces is dat 40 MB gebruikt. Waar maak je je dan druk over?

Lees kortom ook even de FAQ-vraag door die volgt op degene waarnaar ik linkte, want ook het geheugengebruik van processen is niet altijd even makkelijk af te lezen.

En nog een heel andere vraag: tenzij die machine aan het trashen is, waarom ben je je hier uberhaupt druk over aan het maken? Als je denkt dat je het memory management met de hand beter kunt doen dan het OS, dan is de kans zeer groot dat je je daarin vergist, of je moet echt een ultieme expert zijn.

[aKra]

Juh...
_{(Op een of andere manier kan ik deze tekst niet verwerken tot een antwoord , verder wel begrepen )}

Overigens, ik tel toch wel meer dan 1 java process (zie ook PID's, was geen hangende rechtermuisknop ofzo, of CTRL+V )

[Wilke]

Ja, omdat elke thread wel een eigen process ID heeft.

Het spijt me wel hoor, maar misschien is het tijd om eens wat documentatie te gaan doorlezen?

En dat je mijn 'tekst' niet kunt lezen als een 'antwoord' komt vermoedelijk omdat ik niet begrijp wat nu precies het probleem is en dus ook geen antwoord kan geven. Je zegt dat het een probleem is dat Linux geheugen als cache gebruikt. Dat lijkt mij niet een probleem maar juist erg handig. Dus mijn vragen aan jou zijn:

• Waarom zie je het als een probleem dat Linux het geheugen als cache gebruikt?
• Wat is nu concreet het probleem waarom je je hiermee bezig bent gaan houden? Ik neem aan dat er een of andere aanleiding is, bv. dat er iets trager gaat dan je zou verwachten, die computer continu loopt te swappen, dat soort dingen. Als dat niet aan de orde is, waarom dan?

[aKra]

Ik bedoel eerder, ik heb moeite zo'n reeks met texten te lezen op het moment...

Hoofdpijn, oorpijn und enorm verkouden... Geen situaties om alles goed te kunnen lezen & te snappen... Ligt dus niet aan jouw vorm van tekst, of dat je het niet begrijpt...

Ik heb nooit gezegd dat ik het als een probleem zie dat LINUX het geheugen als "cache" gebruikt. Waar ik wel een probleem in zie is dat het lijkt dat er geen geheugen vrij komt, ik ben eens gaan testen met wat programma'tjes, om de 0.1 seconden een 'free -m' update en wat blijkt is dat hij meteen gaat swappen, dit betekend dus dat dat cached dus niet vrijkomt...

Ik denk dus dat elke java-thread daadwerkelijk 38mByte aan geheugen gebruikt.

Edit:
_{(Op een of andere manier kan ik deze tekst niet verwerken tot een antwoord , verder wel begrepen )}

[ Voor 13% gewijzigd door aKra op 28-04-2004 13:25 ]

[Verwijderd]

aKra schreef op 28 april 2004 @ 13:24:
Ik denk dus dat elke java-thread daadwerkelijk 38mByte aan geheugen gebruikt.

Doen ze ook. Er zijn 2 kolommen in de ps output die interesant zijn:

VSZ: Shared memory tussen alle java processen
RSS: De hoeveelheid geheugen in gebruik per proces.

Lees ook de manual page van ps er eens op na. Overigens ben ik wel benieuwt hoe jij je java threading doet. Doe je dat native of green? (als ik me niet vergis was dat het verschil tussen threading en forking van java processen)

[aKra]

Geen flauw idee, standaard D2OL gewoon

[igmar]

Verwijderd schreef op 28 april 2004 @ 13:35:
Doen ze ook. Er zijn 2 kolommen in de ps output die interesant zijn:

Threads delen geheugen. Alle threads samen gebruiken dus 38 meg.

[Verwijderd]

Dat is dus volgens mij afhankelijk of ie threads of forks gebruikt. In het laatste geval word er per process 38M gealloceerd, daar een fork het text+data segment van het geforkte process kopieert. (als ik me niet vergis hoor)

[ Voor 19% gewijzigd door Verwijderd op 28-04-2004 17:02 ]

[Verwijderd]

aKra schreef op 28 april 2004 @ 13:24:
IWaar ik wel een probleem in zie is dat het lijkt dat er geen geheugen vrij komt, ik ben eens gaan testen met wat programma'tjes, om de 0.1 seconden een 'free -m' update en wat blijkt is dat hij meteen gaat swappen, dit betekend dus dat dat cached dus niet vrijkomt...

Hoogstens enkele bytes. Daarna wordt de cache losgelaten en komt het weer terug in je RAM. De cache komt vrij zodra dat nodig is, en niet eerder. Elke byte niet-gebruikte RAM is een byte verspild geld aan ongebruikt en dus onnodige RAM-chipjes, vandaar de caching. Linux geeft je waar voor je geld. .

[igmar]

Verwijderd schreef op 28 april 2004 @ 17:01:
Dat is dus volgens mij afhankelijk of ie threads of forks gebruikt. In het laatste geval word er per process 38M gealloceerd, daar een fork het text+data segment van het geforkte process kopieert. (als ik me niet vergis hoor)

Nope. Linux gebruikt copy on write, en standaard delen geforkte processen dus alle pages. Zodra je schrijft naar een page wordt er pas een kopie gemaakt. De linux JVM is threaded, en gebruikt geen fork()'s AFAIK.