www.elektronik.si

[Glitch]

Umnik, to resujejo razlicni file sistemi. Mene bolj motijo stevilke iz zacetka. To, da je potrebno uporabljati tako aplikacijo oz. da se generirajo tako velike datoteke samo pomeni, da imate napacno metodo resevanja problemov.


Ce prav razumem, uporabljate aplikacijo, ki analizira neko drugo aplikacijo? Imate probleme z memory leaki? Je ta tezavna memory leak aplikacija vasa, tuja, koda je na voljo?

[mucek4]

Da. Gre za reševanje Memmory leak-ov.

Imamo svojo aplikacijo, ki teče na strežniku. Heapa za aplikacijo je 6GB. Aplikacija ima memmory leak, ki ga ne znamo odkriti. Po memory leaku izpljune heap dump in potem se z HD analyzerjem to odpre in analizira. HD analyzer pa ni naša aplikacija in za velike heape potrebuje veliko pomnilnika. Trenutno sem dobil virtualno mašino na strežniku s 25GB memorije. Porabljenih je 22

[Glitch]

Tako kot sem predvideval. S temi dumpi lahko porabite preveč časa, ker ste se namesto problema v kodi lotili problema z novo strojno opremo in kot kaže nikoli ne bo dovolj dobra. Najbolje bo, da dobro pogledate kodo, korak po korak in preden naredite prvi korak naprej, najprej stopite nazaj. Od blizu se včasih nič ne vidi. Tako kot pred tablo v šoli ali kakšno sliko v muzeju.

[mucek4]

Če gledaš od blizu ali daleč.... Pri več kot 100MB java kode ne moreš začeti pri kodi...

[Glitch]

Govorim ti iz izkušenj. Podoben problem sem imel sam, sicer zelo kompleksna embedded zadeva. Zal nimam informacij o stevilu vrstic izvorne kode. Skratka... ogromno, res ogromno. Debuger/tracer metoda se ni obnesla, zadeve sem se lotil kot sem povedal.

Zal si tudi z razlicnimi revizijami nisem mogel pomagati, ker se je napaka pojavila kar tako, navidez zelo nedeterministicno.

Seveda da ne zacnes direktno pri kodi. Raje si izmislite par testov s katerimi boste izlocili posamezne dele kode v katerih ni napake oz. se bolje, naredis test s katerim takoj povzrocis in ponovis napako v delovanju. Ker je test ciljan na doloceno delovanje bi se dalo ugotoviti kateri del kode je zadolzen za dolocena opravila. Potem pa naprej...

[Brane212]

Kar se SWAP-a tiče, ta ni nujno slab in ni nujno, da bo drugače pisana aplikacija delovala hitreje.

Mnogokrat lahko komot take stvari prepustiš SWAP-u, predvsem če program zna držati lokalnost dostopa k pomnilniku in tako recimo res rabi veliko RAM-a, vendar ga praviloma obdeluje v gručah, manjših od dejanjske količine RAM-a.

Takrat tudi z ročnim nalaganjem posameznih kosov ne bi veliko pridobil, če spoh kaj.

Poči gor velik swap ali če imaš itak več diskov pač več enakih manjših SWAP particij.

Kar se dela z SSDjem tiče, je to zelo odvisno od samega drajva. Baje da un tahud Intlov dela tako kot od drajva pričakuješ in posebne prilagodbe niso potrebne.

Elcheapo drajvi od konkurence so pa slabši.

A tudi tu se da pomagati. Linux ima kar nekaj FS-ov namenjenih direktno FLASh medijem, drugače pa lahko uporabiš kak FS tipa "rolling log".

Jaz sem uporabil recimo NILFS2 in dela na navadnem USB ključku SUPER.
Z njim brez problema zbootam mašino s ključka in jo na njem celo updatam, kar je bilo na navadnem ext3/4 noro početje.

[mucek4]

Brane, zadeva je bila potem rešena drugače. Dobil sem server z 25GB memorije in potem je zadeva delovala kot rožica.