Particionálás (túlbonyolítása)

Mivel a particionálás a téma: annyit érdemes előre megtennni, hogy már az elején hozzuk létre a swapet (mert utólag átparticionálni sokkal nagyobb szopás, mint előre eldönteni, hogy xG -t levonunk a diszkből) és kikapcsolva tartani, amíg nem kell. Mert amikor mégiscsak kell, akkor nem mindegy, mennyi kiállással jár a bekapcsolása (a swapon 1s alatt fut le, egy partició átméretezés meg esetleg 10-20p is) és milyen rizikói vannak pl egy partició shrinkingnek. 

Ezzel abszolut egyetertek. De sajnos a valosag gyakran nem olyan, mint amilyennek szeretnenk.

Ahogy ezt nalam okosabbak is leirtak mar: "Az utikalauz tevedhetetlen. Azonban a valosag gyakran pontatlan."

:-)

A rohadás folyamata észlelhető, és kezelhető. Az OOM killer az _is_ lehet megoldás, de előtte azért még célszerű tervezett leállásra lehetőséget adni.

Várj, ezt hogyan? A java annyi memóriát fog használni amit adsz neki (-Xmx paraméterrel). Ha ezt eléri, akkor jön az OutOfMemoryException, és elhal az egész JVM úgy, ahogy van.

"Nem, a leak definíciója az, hogy funkcionálisan felszabadítható memóriaterület foglalt marad. Arról, hogy időnként ráolvas-e a program vagy sem, arról a leak semmit nem mond."

Én itt önellentmondást érzek. A funkcionálisan felszabadítható területet azért nevezzük funkcionálisan felszabadíthatónak, mert biztosan nem olvasunk rá többet. Amire még ráolvashatunk, az nem szabadítható fel.

A láncolt listás példád nem leak, hanem csupán egy szuboptimális memóriastruktúra, hiszen kell a lánc összes tagja, valamikor, valahova fel fogja használni. Az, hogy emellett az új elem végére rakásához neki végig kell gyalogolnia a listán, az csak sima programozói balfaszság. Lehet láncolást a másik irányból is csinálni, foglalsz egy elemet, és az előzőleg foglalt elem címét adod meg neki, így a lánc lefele lóg, te mindig a tetejét látod, így nem kell mindig végigolvasni az utolsó elemet keresve. De ez tökmindegy, értem, hogy csak példa volt.

Szóval maradva a példádnál, van egy lánc amit mindig fel kell olvasni, mert csak. Oké. Ez milyen perfomancia vesztéssel jár? Az attól függ, hogy milyen gyakran és menyit kell olvasni a lemezről. Ha gyakran olvasod, akkor nem kerül ki a swapre. Ha kikerül, mert csak naponta egyszer olvasnak rá, akkor meg naponta egyszer villan egyet az SSD/storage oldalán a LED. Ha nagyon hosszú a lánc, és minden eleme egy külön IO, akkor igazad van, lehet, hogy érezhető lesz a várakozás.

De ez egy nagyon kisarkított példa, amit szerintem te is tudsz, hiszen írod, hogy "Ha ezt rendszeresen kiteszed swap-re, akkor percenként latency vesztésed lesz, ha nem teszed ki swap-re, akkor meg más aktív dolog fog kikerülni és felváltva latency problémáid lesznek.". Namármost amit percenként használsz, az soha nem lapozódik ki, kivéve, ha nincs elég memória a gépben. Szerintem te is képben vagy afelől, hogy napjainkban a programok rettenetesen erőforrásigényesek, de ez nem csoda, mert a programozó ideje több fabatkába kerül mint még egy giga memória, amiből 100 MB azért megy pocsékba, mert a hülyéje fix méretű timestampeket egyesével láncolgat, ahelyett, hogy értelmesen tárolná ezeket. Vagy láncot használ verem helyett. Vagy akármi, amit az ember elkövet, ha kevés idő alatt kell ha nem is készre, de működőre csinálni valamit.

A sima leak szerintem sokkal gyakoribb dolog (fun fact: google: "java leaking" 26 millió találat) mert ez ugye akkor van, amikor egy függvényben van egy malloc/new amin valamit csinál a függvény, majd a végén valamit ellenőriz, és például ha jó az érték akkor kibányássza a lefoglalt memóriából amire szüksége van, jön a free, és visszatér az eredménnyel, viszont ha az ellenőrzés során valami nem jó, akkor visszatér egy konstans hiba értékkel, és mivel ehhez már nem kell a lefoglalt memóriához nyúlni, a programozó simán elfelejti a free utasítást.

Ez a függvény csak néha fut hibára, és olyankor is csak néhány kilobyte ami elvész, viszont ez valóban leak, mert a függvény lokálisan tárolta, hogy hol volt a lefoglalt memória, így miután visszatért, ez az infó elveszett. Vagyis garantáltan nem lesz ráolvasva erre a memóriára, szemben az általad írt láncolt listára ami nem leak, hiszen minden cím elérhető, és jó eséllyel még használva is lesz, elvégre nem ok nélkül gyűjti az adatokat.

"Nincs kontrollod. Azt hiszed, hogy van kontrollod, de nincs."

Hát, lehet, hogy csak egy pillangó vagyok aki arról álmodik, hogy a gyakorlatban tök jól működik, és nemsokára felébredek, de most én tök nyugodtan alszom, mert a monitorban szépen tudom követni, hogy melyik process hány MB memóriát pazarolt el, és így azt is tudom, hogy nagyjából mennyi idő van még, amíg ez gondot okoz, így nem érnek meglepetések, miközben a hibás programok nem a drága memóriát pazarolják.

Figyelj. Értem amit mondasz. Teljesen egyet is értek veled elméletben, csak éppen a gyakorlat többnyire nem olyan tiszta és szép, mint az elmélet.

https://www.pinterest.com/pin/1829656073596075/

"Az egy nagyon nem optimális helyzet, ha a leak-re az a megoldás, hogy megpróbáljuk elfedni, érdemesebb lenne kijavítani, bejelenteni, lecserélni, vagy bármit."

Itt nem egy calc.exe -rol van szo, hanem olyan szoftver elemekrol, amelyeknek a fejlesztese sok szaz millio, es a teszteles, elesbe allas kulon tortenet.

Nehez ervelni amellet, hogy megeri tobb ember tobb heti munkajat meg nehany csaladi haz arat kiadni azert, hogy megsporoljak mondjuk 50-100GB lemezteruletet.

"Újraindítás előtt meg már be van állva az egész, swappel 1000-rel, vagy próbál valami takarítani."

Dehogy! A monitor folyamatosan figyeli a gepej swap allapotat, es jelez, ha valamelyik gepen gyulik a szemet. Igy meg azelott be lehet tervezni a szemetelo gep vagy process ujrainditasat, hogy barmi lassulas lenne, mert nem varjuk meg, hogy telitodjon a swap, vagyis, hogy a gep fizikai memoria nyomorodjon meg a leakelo process miatt.

A swap igy pont, hogy az uzembiztonsagot noveli, ugyanis egy jol viselkedo gepen gyakorlatilag mindig ures, (nehany KB, nehany MB mocorog benne a monitor szerint) ami nem okoz gondot, viszont ha leakelni kezd egy processz, akkor szepen oda gyulik a szemet, tisztan tartva a memoriat, igy idot adva nekunk, hogy betervezhessuk a javitas idejet.

Kulcsszó: monitoring. Még most 2024-ben is találkozom rendszeresen olyan cégekkel, rendszerekkel, ahol a monitoring használhatatlan, hiányos, nem létezik.

Nem mindegy, hogy egyből OOMkill tesz rendet vagy van idő és lehetőség a normális beavatkozásra, netalán debugolásra. Egy normális architektúrában pont előny a swap léte. Egy védőhálót ad.

A swap nem csodaszer. Ha visszarangatod a ritkan hasznalt memoriat, az ellen nem ved. De az ilyen jo esellyel ugy is bent marad a memoriaban, mar ha nem sporolod ki a gepbol a memoriat. Hint: ne sporolj, es akkor nem lesz bajod.

Viszont azoktol a memoria szegmensektol amiket valoban nem olvas mar vissza a processz, mert nincs meg a rajuk mutato pointer, az szepen kiurul a rambol, kimegy a swapre, es bekesen alszik. A felszabadult memoriat meg hasznalhatja mas, ergo a felgyulemlett szemet nem okoz performancia problemat okozni azzal, hogy elfoglalja a helyet a hasznosabb, gyakrabban valtozo dolgok elol.

Majd megmutatom néhánynak holnap, kezdődjön egy mosollyal a hetük :-D

Hajrá.

Egyébként a mindenki által írható területeken a noexec,nosuid,nodev kapcsán milyen "hetekig tartó szopást" tudsz való életből, normálisan összerakott alkalmazás/rendszer esetén mondani?

Több hibajegyem is volt ebből, változatos szoftverek és csomagok esetén, és akkor ilyen szopások tudnak lenni derült égből: https://www.elastic.co/guide/en/elasticsearch/reference/current/executa…

Ha nem találkoztál ilyennel, annak több oka van:

1, mégsem volt a szerveren noexec a mindenki által írható területeken,
2, kurva kevés szoftver futásával volt dolgod az ilyen szervereken,
3, kurva rég foglalkoztál ilyen dolgokkal,
4, esetleg mások megoldották a problémákat és hozzád már nem jutott el vagy kikapcsolták a tudtod nélkül.

Konkrétan volt időszak, amikor egy nyomorult Docker host nem indult el noexec /tmp esetén, olyan is, hogy a Debian saját maga nem tudott frissülni, Ubuntu pár éve szintén elhalt, mert az apt installer futtatott volna ezt-azt a /tmp könyvtárból, Gentoo same shit a /var/tmp kapcsán máig, és tudnám folytatni és egy csomó dobozos szoftver szintén alapoz erre. Desktop vonalon a Signal nem indult, a Discord szintén zenész, de biztos van sokkal több ezekből.

És hozzáteszem újra, hogy a noexec nem véd se a scriptek, se a sok egyéb módon meghívható binárisok ellen, ajánlott olvasnivaló, főleg mosolygóknak: https://book.hacktricks.xyz/linux-hardening/bypass-bash-restrictions/by…

Röviden: a noexec egy régóta meghaladott csökevény, amit el kellene végre felejteni és helyette olyan dolgokat használni, amelyek valóban védenek. A noexec pusztán egy hamis biztonságérzet.