bsnmp a RAM

[Miroslav Prýmek]

Dne 6. ledna 2014 20:11 Dan Lukes <dan na obluda.cz> napsal(a):
> Nevim co znamena "pouziva preventivne". [...] 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.

Nejsem odbornik na memory management, natoz na jejich srovnavani, ale
zkusenost mam takovou, ze Linux miva _stabilni_ nenulove vyuziti swapu
_bez_ jakychkoli
podminek, ktery's popsal vys, ciste pri normalnim provozu. V
zavislosti na nastaveni vm.swappiness. Prave proto, ze swapuje predem,
kdyz se mu zda, ze by to mohl udelat.
Ale to je OT.

> Kdyz to je prakticky nemozny. Napriklad kvuli copy-on-write.

Jo, ale ja jsem nechtel zabihat do detailu, kterym ani nerozumim
- slo mi ciste jenom o uvahu nad realnou, praktickou heuristikou -
predpokladam, ze
typicky server s jakztakz konstantnim (popr. periodickym) zatizenim bude proste
mit spustene procesy, ktere budou mit naalokovane vesmes porad stejne
mnozstvi pameti. Pokud zacnou pamet alokovat nejak "jinak", je to znamka
toho, ze neco nehraje.
Takze se ptam vas zkusenejsich harcovniku, jestli byste neumeli
tu moji chabou predstavu toho "jinak" prevest na nejake konkretni
metriky, na ktere bych se mel zamerit.

Zatim to na me pusobi, ze nejsnadnejsi by bylo si fakt jenom vyexportovat
"sysctl vm.stats.vm.v_active_count" pres snmp, ukladat do RRD a
pro hrubou predstavu to bude uplne dostacujici a pro me prakticky bez prace,
protoze na to nastroje uz beztak mam zprovozneny.

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

To neni stopro jasny ani mne :) Mam namysli opravdu velmi hrubej pohled na
"mnozstvi pameti aktualne naalokovane procesy" vs. "mnozstvi pameti, kterou
procesy maximalne muzou naalokovat". Pro zjednoduseni klidne uvazujme, ze
system proste swap vubec nema.

> Takze vyse uvedene si netroufam zacit ani upresnovat ;-)

Myslim ze nez upresnovat bych spis potreboval co nejvic zjednodusit :)

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

Ja to takhle delat nemuzu, protoze  systemy, se kteryma pracuju, maji
konstantni zatez, takze nejake vetsi pouziti swapu znicehoznic by
znamenalo, ze je potreba dokoupit RAM nebo ze nejaka aplikace se
zblaznila a je potreba ji debuggovat, coz je oboje na dlouhy lokte a
rad bych se o tom prave dovedel co nejdriv aspon v nejakem hrubem a
mlhavem naznaku :)

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

Trendy jsou fajn v tom, ze muzes odhadovat, jestli to timhle tempem
rustu kompletne vytuhne do nepouzitelnosti cca zitra nebo za rok :)

M.