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

[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