bsnmp a RAM

Miroslav Prýmek m.prymek at gmail.com
Mon Jan 6 16:12:37 CET 2014


Dne 6. ledna 2014 15:41 David Pasek <david.pasek na gmail.com> napsal(a):
> Takze volne pameti je opravdu jen cca 671MB, ale tu neaktivni pamet je
> v podstate take mozne brat jako skoro volnou, protoze ta se uvolni a
> pouzije jeste pred tim, nez se zacne swapovat. [...]
> Shrnul bych to tak, ze OS by byl hloupy, kdyby nevyuzival tak drahy
> zdroj jako je pamet, takze kdyz ji ma, tak ji prote vyuzije a uvolnuje
> az kdyz je potreba :-)

Tohle je mi doufam celkem jasny, problem vidim jinde:

Pokud vec chapu spravne, v principu (z "vysokourovnovyho pohledu") muze pamet
nabyvat nekolika stavu:
1. fyzicka nepouzivana - OS na ni jeste nesahl
2. dynamicky naalokovana procesy (malloc apod.) - procesy tam maji
nejaka svoje data
3. vracena procesem - OS ji ma v jakemsi "poolu pameti, kterou muze
znovu dat procesum"
4. sdilena mezi procesy (ro namapovane binarky a knihovny)
5. vsechno ostatni = hlavne diskova cache, ale i ruzne buffery,
struktury jadra atd. atd.

Z hlediska provozu systemu je pro me dulezity asi hlavne pomer (2) k
cele fyzicke pameti. Zbytek me moc nezajima, protoze je bud celkem
konstantni, nebo si ho naopak OS nafukuje a smrstuje podle potreby,
takze to o nicem nevypovida (diskova cache).

Otazka teda je, jak se k tomu (2) dopracovat. Popripade i (2+4),
protoze (4) se snad nijak moc menit nebude.

> Proto sledovani pouzivani volne pameti a swapu, jak navrhoval Dan, je
> asi nejlepsim identifikatorem nedostatku fyzicke pameti.

To urcite, ale je to trochu s krizkem po funuse, byl bych radsi mel
nejakej indikator, kterej by me svym trendem upozornil na problem
predem a ne az v dobe, kdy hori...

> Kdybys toto chtel, tak bys to
> mohl zkusit odhadnout podle trendu aktivni pameti.

Presne tam jsem miril. Je teda zaver, ze pro hrubou kontrolu _trendu_
by mi stacilo sledovat
 vm.stats.vm.v_active_count + vm.stats.vm.v_wire_count  popr. jenom
prvni z nich?

Pod "hrubou kontrolou trendu" si predstavuju neco jako "poznam, ze se
nejak podezrele splasilo MySQL a zacalo si najednou alokovat nejak moc
pameti".

Sorry za neodborne vyrazivo, snad si porozumime :)

M.


More information about the Users-l mailing list