"Ugyanannyi munkával jár, csak közben nem növekszik a load lassan, nem csökken a responsivity, nem lesznek latency problémák és nem húzol be teljese megjósolhatatlan válaszidőket, mert épp valami swap-en van, aminek nem ott kellene lennie."
Értem, akkor rossz a monitorunk, mert jelenleg ezeken a gépeken nincs és nem is szokott lenni semmiféle load, latency, perf probléma, pedig szerinted ennek kéne lennie. Biztosan van olyan scenario amikor igazad van, de párszáz gép működési adatai most engem igazolnak.
"Ez úgy van megoldva a "swap-szekta" szerint nem normális helyeken (vagyis kb. a jelenlegi élvonalban), hogy az orchestrator ..."
Oké, akkor most végy egy nagy levegőt, és gondold végig, hogy mikor írtam én olyat, hogy van orchestrator? Segítek: sehol.
"Memleak szinte mindenhol van, a különbség az, hogy megvárod-e, amíg a rendszer agonizálni kezd a swap használat miatt (lásd megnő a load, satöbbi), vagy még akkor megoldod, amikor nincs a kiszolgálást érintő mérhető jele."
Köszönöm! Pont erről beszéltem végig, örülök, hogy végre te is megértetted. Monitorozom a swap telítődést, és még mielőtt zavaró lenne, vagyis mielőtt megnőne a load, megoldom úgy és akkor, hogy az ne zavarja a kiszolgálást. Tudod, volt itt egy csávó, aki szerint az OOM killer a megoldás a memory leakre, most már csak neki kéne elmagyarázni, hogy ennél azért van szakmaibb hozzáállás arra a problémára, amit te is írsz, hogy: "Memleak szinte mindenhol van"
"Ha egy szoftver lefoglal teszem azt 1 GB memóriát és aztán nem használja, az nem memory leak, hanem determinisztikus és ugyanakkor felesleges memória használat, üzemeltetés szempontjából teljesen jól kezelhető, nem növekszik a memória igénye az idő/terhelés függvényében."
Keresztkérdés: ha nem használja, akkor mikor rántja vissza a lemezről? :-)
Ha nem használja, és a memóriában tartja, akkor elpocsékoltál 1 GB memóriát. Gratulálok.
Ha használja, akkor nem megy ki a swapre. Ilyen egyszerű.
BTW, én azt látom, hogy a leakelő processzek a swapet nem gigákkal terhelik amilyen a te példád, hanem apró morzsákkal, néhány KB/MB -os növekményekkel szemetelik tele, szépen lassan.
A te példád egy olyan abszolút programozói hülyeség erőltetése, ami egyébként megbukna a perf teszten, hiszen a lánc hosszával együtt nő a feldolgozás sebessége, ez alapvetően elég hamar kiderül, élesbe álláskor meg pláne.
Az a scenario ami írsz, hogy a memória szűkössége miatt gigákat rángat a gép a lemezről, és emiatt belassul, az szerinted rosszabb, mintha jön az OOM (mert nincs swap) és kicsapja a fenébe? Ember, adatvesztésről beszélsz! Jó esetben egy másik rétegben még megvan az adat, de ez már feldolgozási architektúra függő, cirka olyan bemondás, mint hogy majd az orchestrátor... És ha nincs orchestrátor. Tudod, sok olyan szoftver létezik, amit nem így terveztek.
Szóval ne erőltesd, hogy a swap ördögtől való, csak mert egy alulméretezett gépen a sűrűn használt gigás láncolt listák feldolgozásakor... Nincs alulméretezés. Viszont nincs pazarlás sem.