Úniky paměti – měření frekvence a závažnosti

Tento příspěvek je součástí naší otevřené kultury – nadále sdílíme poznatky z naší každodenní práce. Tentokrát se podíváme na samotné jádro naší hodnotové nabídky, konkrétně – hledáme odpověď na tyto otázky:

• Jak často dochází k únikům paměti v aplikacích Java?
• Jak velký je únik paměti?
• Jak rychle narůstá únik paměti?

Pokud se mnou zůstanete dalších pár minut, otevřu odpovědi jednu po druhé, na základě dat shromážděných agenty Plumbr pro detektor úniku paměti za posledních ~šest měsíců.

Analýza je v první řadě založena na 2 180 různých aplikacích běží s Plumbr Agents. Definice „jiné aplikace“ je poněkud ošidná a ušetřím vás světských detailů, ale udělali jsme, co bylo v našich silách, abychom na základě dostupných dat identifikovali jedinečné JVM.

V těchto 2 180 aplikacích Plumbr našel 754 různých úniků paměti haldy . Vzhledem k tomu, že některé aplikace obsahovaly několik úniků paměti, počet unikátních aplikací, u kterých byl únik zjištěn, byl o něco nižší – přesněji 682. Na základě těchto údajů můžeme dojít k závěru, že 31 % Java aplikací obsahuje únik paměti na haldě . Berte to s rezervou – připouštíme fakt, že aplikace, které Plumbr nakonec monitoruje, budou pravděpodobně obsahovat únik paměti než ty, které nesledujeme.

Nyní, když víte, že máte zhruba jednu ze tří možností, že ve vaší aplikaci dojde k úniku paměti haldy, uvidíme, zda byste se měli těchto úniků vůbec obávat. Za tímto účelem se podívejme na dvě různé charakteristiky, které máme pro těchto 754 úniků paměti haldy.

Velikost úniku paměti

Když Plumbr nalezne nevracení paměti, spustí složitý výpočet k určení uchované velikosti úniku. Nebo ještě jednodušeji – Plumbr vypočítá, jak velký je konkrétní únik v megabajtech. Tato data jsou vidět v následujícím grafu:

Z dat můžeme vidět, že Plumbr detekuje mnoho úniků již v zárodku – například zjistil 187 úniků (25 % z celkového počtu úniků), zatímco únik byl v době odhalení stále menší než 1 MB . V druhém extrému trvá detekce některých úniků déle, takže ve 31 případech byl únik detekován až poté, co narostl na 1 GB. Největší úniky se před odhalením podařilo vyeskalovat na velikost 3 GB.

Dalším zajímavým závěrem z výše uvedeného je, že většinu úniků zachytí Plumbr dříve, než koncoví uživatelé aplikace pocítí jakýkoli dopad – 70 % úniků je stále menších než 100 MB v době, kdy Plumbr únik nahlásil jako incident. .

Rychlost úniku paměti

Skutečnost, že aplikace obsahuje únik zabírající méně než 100 MB, není něco, s čím by se mělo jednat. Spojením velikosti úniku s rychlostí úniku je závažnost incidentu jasnější:

Informace ve výše uvedené tabulce lze interpretovat takto:pro 6 % (37 výskytů) případů byla rychlost úniku v době zjištění mezi 100 a 500 MB/hod.

V extrémních případech máme buď velmi pomalé nebo extrémně rychlé úniky. Ve 398 případech (53 % odhalených úniků) únik eskaloval rychlostí 1 MB za hodinu nebo méně. Na druhém konci spektra jsme měli31 úniků eskalujících rychlostí až 1 GB/hod nebo rychleji . „Rekordman“ v tomto ohledu dokázal uniknout více než 3 GB za hodinu.

Spojením informací o rychlosti s aktuální velikostí úniku a maximální hromadou dostupnou pro vaši aplikaci můžete pomocí OutOfMemoryError odhadnout množství času, které konkrétní aplikaci zbývá do zhroucení. .

Jeden konkrétní příklad z minulého pátku:Plumbr nahlásil incident, kdy velikost úniku byla 120 MB. Rychlost úniku byla skromných 160 MB/den. Spojením těchto informací s aktuálním využitím haldy a maximální dostupnou haldou bychom mohli předpovědět, že konkrétní JVM bude mrtvé do úterý 14:00. Spletli jsme se o šest hodin, což, pokud vezmeme v úvahu, že vzorce používání aplikací mají tendenci se v průběhu času měnit, je součástí prediktivní hry, je dostatečně blízko předpovědi.