Portál AbcLinuxu, 27. dubna 2024 15:49
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:
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.
Tiskni
Sdílej:
"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.
), 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.
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 
14.6.2007 23:06
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.