Інструмент для аналізу великих кучок Java

У мене є дамп купи HotSpot JVM, який я хотів би проаналізувати. Віртуальна машина працювала з -Xmx31gфайлом дампа купи, розміром 48 ГБ.

• Я навіть не намагатимусь jhat, оскільки для цього потрібно приблизно в п’ять разів більше пам’яті (у моєму випадку це буде 240 ГБ), і це дуже повільно.
• Eclipse MAT аварійно завершує роботу ArrayIndexOutOfBoundsExceptionпісля аналізу дампа купи протягом декількох годин.

Які ще інструменти доступні для цього завдання? Найкращим буде набір інструментів командного рядка, що складається з однієї програми, яка перетворює дамп купи в ефективні структури даних для аналізу, у поєднанні з декількома іншими інструментами, які працюють над попередньо структурованими даними.

Зазвичай те, що я використовую, ParseHeapDump.shвходить до складу Eclipse Memory Analyzer і описується тут , і я роблю це на одному з наших більш посилених серверів (завантажую та копіюю через дистрибутив Linux .zip, розпаковую там). Сценарію оболонки потрібно менше ресурсів, ніж розбір купи з графічного інтерфейсу, а також ви можете запустити його на своєму мускулистому сервері з більшою кількістю ресурсів (ви можете виділити більше ресурсів, додавши щось на зразок -vmargs -Xmx40g -XX:-UseGCOverheadLimitкінця останнього рядка сценарію. Наприклад, останній рядок цього файлу може виглядати так після модифікації

./MemoryAnalyzer -consolelog -application org.eclipse.mat.api.parse "$@" -vmargs -Xmx40g -XX:-UseGCOverheadLimit

Запустіть це як ./path/to/ParseHeapDump.sh ../today_heap_dump/jvm.hprof

Після того, як це вдається, він створює ряд файлів "індексу" поруч із файлом .hprof.

Після створення індексів я намагаюся згенерувати з них звіти та обмінювати ці звіти на свої локальні машини і намагаюся зрозуміти, чи можу я знайти винуватця саме за цим (не лише звіти, а не індекси). Ось підручник зі створення звітів .

Приклад звіту:

./ParseHeapDump.sh ../today_heap_dump/jvm.hprof org.eclipse.mat.api:suspects

Інші варіанти звіту:

org.eclipse.mat.api:overview і org.eclipse.mat.api:top_components

Якщо цих звітів недостатньо, і якщо мені потрібно ще копати (тобто, скажімо, через oql), я сканую індекси, а також файл hprof на свою локальну машину, а потім відкриваю дамп купи (з індексами в тому ж каталозі, що і дамп купи) з моїм графічним інтерфейсом Eclipse MAT. Звідси для роботи не потрібно занадто багато пам'яті.

EDIT: Мені просто сподобалось додати дві нотатки:

• Наскільки мені відомо, лише генерація індексів є інтенсивною частиною пам'яті Eclipse MAT. Після того, як ви отримаєте індекси, більшій частині вашої обробки з Eclipse MAT не знадобиться стільки пам'яті.
• Робити це на сценарії оболонки означає, що я можу це робити на безголовому сервері (і зазвичай я це роблю також на безголовому сервері, оскільки вони, як правило, найпотужніші). І якщо у вас є сервер, який може генерувати дамп купи такого розміру, швидше за все, у вас є інший сервер, який також може обробити таку велику кількість дампа купи.

Прийнята відповідь на це пов’язане питання повинна забезпечити вам хороший старт (використовує живі гістограми jmap замість купи дампів):

Метод пошуку витоків пам’яті у великих дампах Java

Для більшості інших аналізаторів купи (я використовую IBM http://www.alphaworks.ibm.com/tech/heapanalyzer ) потрібно щонайменше відсоток оперативної пам'яті більше, ніж купа, якщо ви очікуєте гарного інструменту графічного інтерфейсу.

Крім цього, багато розробників використовують альтернативні підходи, такі як аналіз стека в реальному часі, щоб отримати уявлення про те, що відбувається.

Хоча я мушу запитати, чому ваші купи такі великі? Вплив на розподіл та вивезення сміття повинен бути значним. Б'юся об заклад, що великий відсоток того, що знаходиться у вашій купі, насправді повинен зберігатися в базі даних / постійному кеші тощо тощо.

Я пропоную спробувати YourKit. Зазвичай йому потрібно трохи менше пам'яті, ніж розмір дампа купи (він індексує її та використовує цю інформацію для отримання бажаного)

Ще кілька варіантів:

Ця особа http://blog.ragozin.info/2015/02/programatic-heapdump-analysis.html

написав власний аналізатор купи Netbeans, який просто виставляє інтерфейс "стилю запиту" через файл дампа купи, замість того, щоб фактично завантажувати файл у пам'ять.

https://github.com/aragozin/jvm-tools/tree/master/hprof-heap

Хоча я не знаю, чи "мова запитів" краща за OQL eclipse, згадану у прийнятій відповіді тут.

JProfiler 8,1 ($ 499 для користувача ліцензії) також сказав , щоб мати можливість перетинати великі купи , не використовуючи багато грошей.

Перший крок: збільште обсяг оперативної пам'яті, який ви виділяєте для MAT. За замовчуванням це не дуже багато, і він не може відкривати великі файли.

У разі використання MAT на MAC (OSX) у вас буде файл MemoryAnalyzer.ini у MemoryAnalyzer.app/Contents/MacOS. Мені не вдалося внести корективи в цей файл і змусити їх "взяти". Ви можете замість цього створити модифікований сценарій команди запуску / оболонки на основі вмісту цього файлу та запустити його з цього каталогу. У моєму випадку я хотів купу 20 ГБ:

./MemoryAnalyzer -vmargs -Xmx20g --XX:-UseGCOverheadLimit ... other params desired

Просто запустіть цю команду / сценарій із каталогу Contents / MacOS через термінал, щоб запустити графічний інтерфейс із більшою кількістю доступної оперативної пам'яті.

Не дуже відомий інструмент - http://dr-brenschede.de/bheapsampler/ добре працює для великих куп. Це працює шляхом вибірки, тому йому не доведеться читати все, хоча і трохи вибагливо.

Остання збірка знімків Eclipse Memory Analyzer має можливість випадковим чином відкинути певний відсоток об'єктів, щоб зменшити споживання пам'яті та дозволити аналіз решти об'єктів. Див. Помилку 563960 та нічну збірку знімків, щоб протестувати цю можливість, перш ніж вона буде включена до наступного випуску MAT.

Це не рішення командного рядка, однак мені подобаються інструменти:

Скопіюйте дамп купи на сервер, достатньо великий для її розміщення. Цілком можливо, що можна використовувати оригінальний сервер.

Введіть сервер через ssh -Xдля віддаленого запуску графічного інструменту та використовуйте jvisualvmз двійкового каталогу Java для завантаження.hprof файлу дампа купи.

Інструмент не завантажує повний дамп купи в пам’ять відразу, але завантажує деталі, коли вони потрібні. Звичайно, якщо ви оглянете достатньо файлу, потрібна пам’ять нарешті досягне розміру дампа купи.

Спробуйте використати jprofiler, він добре працює при аналізі великого .hprof, я спробував із файлом розміром близько 22 ГБ.

https://www.ej-technologies.com/products/jprofiler/overview.html

Я натрапив на цікавий інструмент під назвою JXray. Він надає обмежену пробну ліцензію на оцінку. Дуже корисно виявити витоки пам'яті. Ви можете спробувати.