Pašácí SAPácí čili ještě o limitech

14.6.2007 22:55 | Přečteno: 1564× | pro temnou strunu | poslední úprava: 14.6.2007 23:33

Skorem před dvěma týdny jsem psal o analýze téměř dvougigového heapdumpu javovského programu a o tom, jak to s jhatem na 32bitové architektuře není žádná sranda (lépe řečeno, že to ani nejde). A před pár dny se na TheServerSide objevila informace o volně dostupném (nikoliv opensource) SAP Memory Analyzeru. Jásáme?

Tak předně: SAM slibuje analýzu heapdumpů větších než 1 GB s více než 20 miliony objektů. Na běžném 32bitovém stroji. To zní dobře. Hůř už zní, že download je k disposici pouze pro Windows. Jde ovšem o čistě javovskou aplikaci postavenou nad Eclipse RCP, a v diskusi na TSS se ergo dozvídáme, že by SAMeček neměl mít proti Linuxu protesty. Ale jak na to?

Pokus první: instaluju wine a zjišťuju, že v Debianu testing je nějaká prehistorická verze (tuším 0.9.25). No nic, dejme mu šanci. Spouštím SAPMemoryAnalyzer.exe (moje první exe v Linuxu, už nejsem panic, ach, všechno končí…) a zírám: plocha zčernala, uprostřed se objevilo zcela nenativně vypadající okno instalátoru. Chtivě mačkám Next (ať to poprvé teda stojí za to!) a jsem zdrcen: ta kráva vyžaduje Javu už při instalaci.

Pokus prvý a půltý: zkouším v ~/.wine/dosdevices/c:/Program Files/Java vytvořit adresář bin a v něm prázdné soubory java.exe a javac.exe. Naivní, ale za pokus to stojí. Samozřejmě bez šance, on tu Javu chce taky spustit.

Pokus druhý: potvrzuji si, že jsem těžký zvrhlík, a zkouším do wine nainstalovat Javu. No, pojďme dál, tohle nemá smysl rozvádět.

Pokus třetí: vzdávám to dřív, než jsme se pořádně rozjeli, a pokorně se uchyluji k VMware Serveru s nainstalovanými Windows XP Home (inu samohana – není to sice ono, ale aspoň člověk bez větších překážek dosáhne svého). Jako správný perverzák kopíruji instalačku do virtuálního stroje přes SCP, a poslušen návodu z TSS se snažím instalačku rozbalit WinZipem. Zdálo se mi to jako nesmysl, a zdání nezklamalo.

Pokus čtvrtý: instaluji do virtuálních Windows Javu, spouštím znovu instalaci SAMa a – ne, tohle ještě není vrchol. Nainstaloval se bez keců a já se jmu kopírovat, opět přes SCP (dost podobné zkratce SM), balíky z features a plugins do Eclipsu pod Linuxem.

Co mi fungovalo: použít kompletní Eclipse SDK a nakopírovat do něj všechny fíčury a plužiny se slovem sap v názvu, a kromě nich ještě ty týkající se xercesu. Nevím, k čemu mu jsou, ale když je s sebou táhne, snad ví, co dělá. Zkoušel jsem to i s prostým Eclipse RCP, ale napoprvé to nevyšlo a podruhé už jsem to nezkoušel.

Fajn, instalaci máme za sebou, zapotili jsme se, ale teď přijde to nejlepší. Tak doufejme, že ještě máme dost sil, čeká nás to, kvůli čemu celé tohle martyrium podstupujeme. V dobré náladě si uděláme ze SAMce vtip a v eclipse.ini mu nastavíme omezení na 1024 MB paměti (-Xmx1024M). Ten se ovšem neohrožene vrhá do díla, dvacet minut se snaží něco dělat, načež spadne na OutOfMemoryError. To dá celkem rozum. Zkusme přijatelných 1536 MB (1 + 0,5 = 1536, a vysvětlujte to někomu).

Dalších dvacet minut čekáme a tradá: je to tam! Ten šikula opravdu byl schopný zpracovat heapdump v paměti, která je menší, než ten dump samotný. Na disku po něm zůstane asi deset souborů o celkové velikosti necelé 2 GB, ovšem veškerá další práce je už poměrně svižná.

Nuže: jhat je mrtev, ať žije SAM! Jinak onen heap dump, jak SAM vtipně informuje, obsahuje asi 30 milionů objektů. Nájs!

Dál snad jen pár rozdílů, které jsou sice na první pohled patrné, ale abych celou tu pornografii nepopisoval pro nic za nic:

• O paměťových nárocích už jsem se rozepsal výše; SAM sice provádí mnohem komplexnější analýzu, ovšem předzpracovaná data si ukládá na disk, zatímco jhat drží všechno v paměti.
• Předzpracování samotné trvá SAMovi o poznání déle: s těmi 20 minutami vůbec nepřeháním. No, počáteční režie se snad dá překousnout.
• jhat nastartuje webový server a pracujete s ním tedy v prostředí prohlížeče, zatímco SAM je běžná desktopová aplikace.
• jhat obsahuje dotazovací jazyk založený na JavaScriptu, SAM zato zobrazuje některé podrobnější informace (ta asi nejdůležitější: kromě toho, kolik objekt samotný zabírá v paměti, také celkovou velikost paměti, kterou by bylo možné uvolnit, kdyby byl uvolněn daný objekt!).
• jhat umí vzít dva heapdumpy a udělat diff, což může být v některých situacích velmi užitečné. SAM nikoliv.
• Bez alkoholu versus v řeči. Hm, však vy víte. Mne osobně to až tak nepálí.

Závěr? Až budu mít čas, možná se tomu dumpu budu víc věnovat. Teď mám bohužel horší věci na práci. Díky za trpělivost při čtení těch výmyslů výše.

       

Komentáře

[fx-95]

Ten dvougigový dump udělal hello world? :)

[Ladicek]

Jasně, třicet miliónů helou worldů a máš to tam taky. Musíš si je samozřejmě všechny strčit do seznamu, i když ti k ničemu nejsou. A to se vyplatí!

[dustin]

Gratuluji k rozlousknutí problému, o kterém už jsem něco slyšel :)

[Kyosuke]

"Ten šikula opravdu byl schopný zpracovat heapdump v paměti, která je menší, než ten dump samotný."

Inu, já jen dodám, že dbm-like knihovny, databázové servery, implementace souborových systémů a mmap jsou další příklady neprasáckého SW, který nemusí mít celý svůj dataset v paměti.

[Filip Jirsák]

A já zase dodám, že různé grafické nebo video editory jsou příklady prasáckého SW, který si myslí, že když nebude mít celý svůj dataset v paměti, něco tím vylepší.

Mimochodem, jmenoval jste jen databáze a souborové systémy, což je software specifický tím, že řeší přístup k datům na vlastní pěst – protože má zpravidla o struktuře dat daleko lepší přehled, než operační systém, takže toho dokáže náležitě využít ve prospěch rychlosti a náročnosti na úložný prostor. Zajímavé je, že oba druhy užití zároveň zpravidla umožňují používat diskové oblasti přímo, bez souborového systému. Ani při nejlepší vůli nedokážu nástroj na analýzu dumpu zařadit mezi databáze a/nebo souborové systémy. Takže to, že nějaký nástroj pro analýzu dumpu dnes užívá soubory místo paměti beru jako aktuální obezličku, která umožňuje obejít limit 32bitové platformy. Těžko bych to ale nazval systémově správným přístupem.

[Kyosuke]

Nechápu, proč by nástroj na analýzu dumpu nešel klasifikovat jako databáze. Nad tím blobem dat přeci existuje nějaká struktura, nad kterou se dá navigovat. Ba co hůř (pro Vás ), objektové databáze mají přesně charakter perzistentního heapu, takže buď objektové databáze nejsou databáze (podle vašich představ), nebo je analýza heapu databázovou aplikací. Nevím, jak Vy, ale já volím to druhé.

Mimochodem, video se v polovodičové paměti (načtené celé) editovat opravdu nedá. Při seriózní práci je leckdy těžké nacpat to i třebas do diskového pole, viz Quantel. A na páskách snad editovat nechcete.

[Filip Jirsák]

S tímhle přístupem je ovšem databáze skoro všechno Ovšem databáze ani souborový systém se nestará jen o uložení dat, to zvládne jádro opravdu samo, ale hlavně má indexy, podle kterých je možné ta data rychle hledat. To má dump taky? A platí u něj, že jednoúčelová aplikace dokáže k datům z dumpu přistupovat výrazně efektivněji přímo, než pokud jádro načítá stránky do paměti dle obecných algoritmů?

Přístup do paměti z aplikace nemá s polovodičovou pamětí zas až tolik společného – je věcí jádra, zda data ponechá v polovodičové paměti nebo budou na swapu. Pokud dnes programátor uvažuje o rozdílech mezi malloc a open primárně jako o rozdílech mezi polovodičovou pamětí (rychlou a malou) a diskem (velkým a pomalým), je to podle mne špatně. Protože ona ta paměť může být taky pomalá, protože je uložena ve swapu, nebo disk může být rychlý, protože je to ramdisk. Do paměti podle mne patří datové struktury "rozbalené" tak, jak se používají během provozu aplikace. Na disk se pak uloží v "zabalené" formě, přenositelné na jinou platformu nebo do jiné aplikace. Samozřejmě, není to striktní rozdělení, někdy má aplikace tak specifický přístup k datům, že opravdu výkonově strčí jádro do kapsy. Ale myslet si u obecných dat, že vývojáři jádra jsou hlupáci a já ten swap naprogramuju daleko lépe, to je myslím trochu mimo.

[Ladicek]

Ale jo, však jsem psal už v komentářích k minulému zápisku, že analyzátor heapdumpu je v podstatě databázová aplikace. Já jen že mne to potěšilo

[podlesh]

Tak to ta instalace byla docela v pohodě, na SAP poměry.

[Trained.Monkey]

Linux build asi neudelali jen z lenosti, pokud pouzivaji pure javu a eclipse rcp je to zalezitost minuty.

Lepsi zpusob instalace: vezmi adresar, nakopiruj do nej SWT implementaci pro GTK (mozna je treba udelat grep a nahradit reference). Aplikace pak jde spustit pres startup.jar