bsnmp a RAM

[Dan Lukes]

Miroslav Prýmek wrote:
> Pro me je ted momentalne asi nejproblematictejsi se vubec vyznat v
> tom, co ktery nastroj vlastne ukazuje pod jakym nazvem :)

> Swap je jasnej - celkem k dispozici a nepouzito. Rozdil je objem
> pouziteho swapu a mel by se drzet nizko. BTW, pokud jsem si dobre
> vsimnul, v tomhle se FBSD lisi od Linuxu, ktery swap pouziva
> "preventivne", takze se na nule nedrzi ani kdyz (jeste) neni potreba.
> V tomhle je (z hlediska monitoringu) FBSD sympatictejsi ;)

Nevim co znamena "pouziva preventivne". Takze misto toho zminim, ze i na
FreeBSD s velkym mnozstvim pameti a to prevazne nevyuzite se muzes
setkat s nenulovou obsazenosti pameti. System totiz udrzuje jen velmi
male mnozsti skutecne nevyuzite fyzicke pameti. Vetsina nevyuzite
fyzicke pameti je pouziva jako diskova cache. Pokud v prilis kratkem
casu prijde vetsi mnozstvi alikoacnich pozadavku, takove, ktere prevysi
objem drzene rezervy nastane situace, kdy paradoxne fyzicka pamet k
dispozici neni. Ulozeni diskove cache a uvloneni fyzicke pameti je
narocnejsi operace nez odswapovani, takze system v teto situaci sahne do
swapu. A pri trose stesti do nej zahodi neco, co fakt neni potreba - a
to tam tedy dlouhodobe zustava. Statistika pak ukazuje, ze swap byl pouzit.

Podstatnejsi jsou tedy trendy a, jak uz to padlo, swap-in/swap-out.

> Cisla ohledne RAM ale moc nechapu... Ciste z nazvu hadam asi takhle:
> TotalReal by mela byt asi celkova (fyzicka, instalovana) RAM.
> AvailReal fyzicka, naprosto nevyuzita pamet. Cim se lisi od TotalFree netusim...
> Shared snad pamet sdilena mezi procesy, takze hlavne binarky.
> Buffer hlavne diskova cache.
> 
> Chtel bych se nejak dopocitat k pameti, kterou si procesy postupne
> alokuji, ale nejak mi to teda z techto cisel nevychazi...

Kdyz to je prakticky nemozny. Napriklad kvuli copy-on-write. V davnych
dobach byl pametovy prostor procesu skutecne oddeleny. Pri forku se
udelala kopie pametovyho prostoru pro synovsky proces. To uz davno
neplati. Po forku zustava pametovy prostor obou procesu spolecny, jen se
obema procesum do nej zakaze zapis. Dokud stranku pameti jen ctou, je
furt jen jedna pro oba. Teprve v okamziku, kdy se jeden z nich pokusi
zapsat vyvola to vyjimku (nema zapisova prava) a v ramci jeji obsluhy se
z te konkretni stranky vytvori kopie (z te jedne), zapis se povoli
(obema procesum) a zrestartuje se instrukce, ktera vyjimku vyvolala.

No to ale znamena, ze poscitanim poctu stranek zabranych kazdym ze dvou
procesu nedostanes  pocet stranek zabranych obema dohromady. Pro vic
procesu uz je to jen a jen horsi.


Dalsi komplikace je kod - kod programu je pro vsechny synovske procesy
shodny a neni treba aby byl v pameti pritomny vickrat. U dynamickych
knihoven tohle plati dokonce i pro sdileni kodu mezi procesy
nesynovskymi. Mimochodem, programovy kod ze z pameti neswapuje, to nema
smysl, ten se zahodi a v pripade potreby znovu nahraje ze souboru odkud
se nahraval poprve.

> TotalReal by mela byt asi celkova (fyzicka, instalovana) RAM.
> AvailReal fyzicka, naprosto nevyuzita pamet. Cim se lisi od TotalFree netusim...

To, ze do systemu osadis pamet o nejake velikosti nutne neznamena, ze je
cela ta pamet taky pro procesor dosazitelna. Pitvat to budu az v pripade
zajmu, ted to zkusim odbyt prikladem - treba BIOS se historicky naleza
na adresach <1MB-64kB, 1MB). Pokud mas v pocitaci 1MB fyzicke pameti, do
tehle 64kB se nedostanes, protoze objevi-li se takova adresa na sbernici
hardware komunikaci naroutuje do svabu s BIOSem. Nebo treba RAM VGA
karty je dalsi podobny priklad ...

> 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.

Neni jasny, jestli mluvis o fyzicky, linearni nebo dokonce segmentovy
pameti. Skoro bych rekl, ze o realny, byt' to nekoresponduje se zminkou
o "vysokourovnovtym pohledu". Jenze "malloc" je zalezitost vnitrni
organizace pameti v ramci pridelenyho bloku, uz operacni system o nicem
takovem jako malloc nic nevi - takze to je jeste vejs nez segmentova
pamet. To je pak opravdu vysokourovnovej pohled, pak ale nemaji smysl
zminky o OS< protoze ten o tenhle organizaci uz nic netusi.

Takze vyse uvedene si netroufam zacit ani upresnovat ;-)

> Jak presne se k tomu cislu dopracovat?
> vm.stats.vm.v_active_count + vm.stats.vm.v_wire_count  ?

To, ze mam vymysleno co bych sledoval neznamena, ze mam vymysleno jak
bych to sledoval ;-)

> systemy, ktery jsou vetsinou spis naddimenzovany, takze nejakej narust
> vlivem memory leaku apod. mi tragicky nevadi a funkcnost nehrozuje,
> spis bych o nem jenom proste chtel vedet :)

Tak to presne delam, a delam to tak, ze sleduju vyuziti swapu. Dokud je
to cislo nizke, tak me to nezajima, pokud nizke byt prestane, zacnu se
tim v danem konkretnim okamziku zabyvat. Bez toho, ze bych mel ulozene
nejake historicke udaje - proste zacnu resit v tom okamziku kdo ma pamet
sezranou.

Beztak to bude mit na triku BIND nebo MySQL ;-)

> nepotrebuju nejaky vypocty, uplne by mi stacilo, kdybych se podival na
> rekneme tydenni graf a mohl rict "Ha! Tady ten graf nam porad roste.
> Co tototo?" :)

To je skoro co rikam. Kdyz vidim, ze je cislo vetsi nez male, muselo na
tu hodnotu narust. Na to nepotrebuju historickej graf ;-)

Cimz nerikam, ze to je nejlepsi zpusob sledovani nebo prevence. Je to
zpusob vyzadujici nejmene energie, ktery uz ale prinasi to co od toho
cekam ja.


Dan