Dne 6. ledna 2014 15:41 David Pasek <[email protected]> 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. -- FreeBSD mailing list ([email protected]) http://www.freebsd.cz/listserv/listinfo/users-l
