Normális memória korlátozás Ubuntu alatt hogyan?

"A. rootként futtatod a progidat (ulimit = unlimited)."

Ez nem igaz. 1x se futtattam rootként.

Egyébként meg default-ba ezek vannak:

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 13484

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 1024

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 8192

cpu time (seconds, -t) unlimited

max user processes (-u) 13484

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

Csak magát a process-t próbáltam korlátozni, nem a konfigot átírni,de azt hittem ez kiderült abból amit írtam próbálkozásokra az összes példám rá. Terminálba futtattam. Mint mondtam vagy irreálisan korlátozta vagy hagyta felélni az összes memóriát vagy csak a szerencsén múlott ha pont jól korlátozta. Szóval nem az, hogy hatástalan volt mert igen is volt hatása az ulimit-nek, de nem az elvárt hatása volt.

"Az biztos, hogy a progid szervezése eleve rossz. Ez az, ami garantált. A többit csak feltételezem."

Az most másodlagos. Az igaz hogy rossz, de nem az a kérdés. Választ igazából nem kaptam. Máskor is jól jönne egy processt korlátozni.

Teljesen más vizek, gyönyörűen beparaméterezhető a java virtuális gép memória használata, értelmesen korlátozza, nem kell vele semmit kínlódni.

"A. rootként futtatod a progidat (ulimit = unlimited)."

Egyszer se futtattam rootként.

"B. nem loginolsz újra az ulimit rekonfigja után."

Nem rekonfigolom, hanem ha nem derült volna ki az előzőből, hogy az ulimitet beparaméterezve korlázotom és igen is csinál valamit csak nem azt amit kéne. Vagy irreálisan korlátozza vagy hagyja felélni az összes memóriát beparaméterezéstől függően, csak szerencse ha pont jól csinálta,de nem találtam egy biztos beparaméterezést, hogy biztosan ne engedje elérni az elkerülhetetlenségi szakaszt ami után elkerülhetetlen hogy befagyjon tőle az egész rendszer.

Vagyis lefordítom akkor közérthetőbbre hogy mit csinált az ulimit. A baj az hogy nem kezelte le hogy melyik része a memóriának amit ő saját maga foglalja a rendszertől és más processek elől és mennyi az osztott memória, ami miatt nem növekszik a tényleges memóriahasználat. Az ulimit korltázása nem különbözteti meg a kettőt, pedig nagyon nem mindegy. Vagyis ha 1 gigára korlátozom akkor egyből "kihal" mert elérte a limitet, ha 2 gigára akkor megy, de könnyedén "kihalhat" akkor is hogy elérte a 2 gigát, amikor monitorozón meg látszik hogy egy hajszálnyit se ugrott a rendszerbe a memóriahasználat a processem indítása előtthöz képest. Eddig én magam voltam a legbiztosabb módja hogy ne forduljon elő ilyen úgy, hogy amikor a nagy lefagyások voltak akkor nem figyeltem illetve nem indítottam erre jól felkészülve, azóta ha látom a használati diagrammon, hogy baj lesz akkor a már előre bekészített módon csak küldök egy kill szignált időbe.

"Az biztos, hogy a progid szervezése eleve rossz. Ez az, ami garantált. A többit csak feltételezem."

Igen, de nem ez a lényeg most, nem is ez a kérdés. Máskor is jól jönne process memória korlátozása.

Más vizek : A java virtuális gép gyönyörűen beparaméterezhető, hogy mennyi memóriát használhat, be is tartja az elvárt módon.

"A linuxnak, mint más unix jellegű rendszereknek is, az a legértékesebb tulajdonsága, hogy egy user (aki nem root) egyszerűen nem képes a rendszer megfektetésére.

Persze ennek előfeltétele a megfelelő bekonfiguráltság, az erőforrások optimális elosztása, kiosztása, felügyelete."

Ez abból a szempontból amennyire igaznak mondanám, nem a linux / unix sajátossága. Egy pénzfelvevő bank terminál is simán megy még win xp alól, hiába nem adnak ki biztonsági frissítéseket rá, nincs a támadási felület meghagyva, az se látszik rajta hogy win alól fut. Csak ami minimálisan szükséges az fut rajta értelmes kereteken belül. Bár ez egy speciális példa volt, nem specializált beágyazott rendszer esetében nem biztonságos az xp.

Ellenpélda még a p2-es p3-as korszakból uhu linuxos p2-es gépen csak a zenelejszó ment hetekig, nem bírt ki egy hónapot hogy hirtelen ne fagyjon le az egész gép, szó szerint lefagyott szintén a num lock se reagált. Az altatást, hibernálást se nagyon bírták, úgy értve hogy 10-ből 1x lefagyott, bár most egész jó az arány már, nem is tudom mikor nem tudott felébredni belőle legutóbb.

Na ,de van még jobb példám is. Buszba sima digitális óra ahol 2 szám között villog a kettőspont. Na volt olyan hogy megállt a villogás folyamatosra váltott, majd 20 perc múlva is ugyanazt az órát és percet mutatta, aztán kivettük az elemet majd vissza rajtuk meg újra be kellett állítani akkor már jó volt. Pont erre gondoltam hogy az a mondás, hogy a linux nem fagy le, ugyan már. Nem azt mondom hogy linux volt az órán is, de még az is lefagyhat. Ott aztán logikusan nem volt semmi bonyolult rekurzió vagy túl sok calloc hívás.

Nem is számoltam hogy 2018-ban mennyi hardveres hibája derült ki az intel cpu-knak. Meg ugye volt a "mágikus szám" (magic number) java-ba amit már javítottak, de az már régebben ami konverziókor akár le is fagyasztotta a virtuális gépet. Mindig van kiskapu ami képes lefagyasztani a gépet.

"Első körben arra gondoltam, nálad a problémát az okozza, hogy rekurziót használsz, de ennek ellentmond az állításod, mi szerint a HEAP-et használod intenzíven (nem a stacket), tehát ez a vélelem kiesik."

Memória foglaláskor nem is használok egyáltalán rekurziót, csak felszabadításkor.

Ciklusonként 1 függvényhívás van mely függvényen belül csak 4 sor van függvény 2 calloc hívás egy pointer állítás egy return egy pointerrel.

A ciklusban ez a hívás is csak akkor van ha az adott részfa nem létezik, hibakezelés hogy nem e NULL értéket adott a függvény visszatérési értéke, ezen kívül még egy pointer állítás van. Szóval elég minimális maga a ciklus. A futási ideje meg a fa magasságával arányos ami egyébként 10, bár többféleképpen paramétereztem már, de ennél is már fagyott le. N-áris fa, konkrétan 256-áris fa. Azzal nem számoltam hogy mekkora lesz a memória igénye, csak a futási időre koncentráltam. Ebbe nincs sehol hash tábla, ez csak egy előfelmérés volt, egy teszt. A hash táblában minden "memóriacellának" a "címét" a fa elérési útvonala reprezentálta volna, de úgy látom túl memóriaigényes.

Azt hittem, hogy valamit felszabadítótanul hagyok elég durván a destruktor hívása után (igen objektumorientáltan csináltam annak ellenére hogy nem támogatja a nyelv nyelvi szinten), mert felszabadítás után nem csökken a szabad memória a rendszerbe. Ha foglalok egy ilyen pár ezer node-ot tartalmazó fát, majd fogalok másikat másikat, folyamatosan kezd elfogyni az összes memória. Viszont ha foglalok ilyen fát majd felszabadítok utána megint foglalok majd ismét felszabadítok akkor tart egy adott szintet, ami időnként lejebb is mehet felszabadítás után, de rendesen akkor megy vissza ha leáll a process. Csak tesztből próbáltam ki, hogy jóval több memóriát is kérhetek mint amennyi van swappal együtt is, de több calloc-al, egyel nem engedi. Ténylegesen akkor kezd fogyni a memóriahasználata hogyha elkezdem írni a kapott memóriaterületet. Trükkös lusta kiértékelést használ a rendszer szintű memóriamenedzser. A baj az vele hogy nem látja a kódom belőle hogy meddig lehet menni a foglalásokkal, a szándékos esettől eltekintve sose kaptam NULL-t a calloc hívással. Azt az illúziót próbálja kelteni mintha végtelen sok erőforrás lenne a memória, amikor meg elfogy akkor rendesen lefagyassza a gépet.