Служба підтримки: Аналіз проблем управління пам'яттю за допомогою Memory Dump Diagnostic for Java (MDD4J)

1. Серія контенту:
2. Цей контент є частиною серії: Служба підтримки
3. Вступ
4. Що таке дамп купи
5. Аналіз дампов купи
6. Запуск і використання MDD4J
7. Малюнок 1. Поняття витоку пам'яті
8. Оцінка результатів аналізу
9. Малюнок 2. MDD4J в інструментальному середовищі IBM Support Assistant
10. Підозрілі місця витоку за розміром зоною досяжності
11. Підозрілі місця витоку в інтегрованій даних
12. Малюнок 5. Підозрілі об'єкти витоку на рівні об'єднаних структур даних
13. Підозрілі об'єкти витоку на рівні об'єктів / класів
14. Малюнок 6. Підозрілі об'єкти витоку на рівні об'єктів / класів
15. Використання уявлень підозрілих об'єктів витоку
16. таблиці об'єктів
17. Малюнок 7. Таблиця об'єктів, відсортована за кількістю примірників
18. Малюнок 8. Представлення Data Structures
19. Малюнок 9. Великі структури даних
20. Малюнок 13. Огляд всієї купи
21. Малюнок 15. Загальний стан EvaluateServlet
22. Малюнок 17. Розміри структур даних
23. Малюнок 18. Зведена інформація про EvaluateServlet
24. Дослідження схеми вмісту
25. Малюнок 19. Вибір типу структури даних
26. Малюнок 20. Схема вмісту EvaluateServlet
27. Малюнок 21. Складна схема вмісту
28. Малюнок 22. Граф типів Hashtable
29. Малюнок 23. Подання схеми полів
30. Малюнок 24. Виконання MDD4J поза ISA
31. Ресурси для скачування

Наша взаимовыгодная связь https://banwar.org/

Служба підтримки

Серія контенту:

Цей контент є частиною # з серії # статей: Служба підтримки

https://www.ibm.com/developerworks/ru/library/?series_title_by=**auto**

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Служба підтримки

Слідкуйте за виходом нових статей цієї серії.

У статтях серії "Служба підтримки" (Support Authority) обговорюються ресурси, інструментальні засоби та інші елементи технічної підтримки IBM®, доступні для продуктів WebSphere®, а також методики і нові ідеї, які можуть підвищити ваші можливості в області технічної підтримки.

Як завжди, ми почнемо з деяких новин, які зацікавлять співтовариство WebSphere в цілому:

• Оновлення своє ПО! вийшов IBM Support Assistant V4.1.1! Це інтегральний пакет виправлення помилок, який можна встановити в IBM Support Assistant V4.1. У вас ще немає IBM Support Assistant V4.1.0? Завантажте останню версію інструментального середовища IBM Support Assistant з Web-сайту, потім оновіть її до версії V4.1.1 (див. Сторінку IBM Support Assistant Download Page ).
• Підключайтеся до спільноти WebSphere Online Support Virtual Community на WebSphere.org , Щоб зустрітися з іншими користувачами WebSphere і відвідувати наші щомісячні збори. Щомісяця ми запрошуємо доповідача по інструментальним засобам, що допомагає підтримувати сімейство продуктів WebSphere.
• тепер портал IBM Support Portal працює для всіх брендів IBM Software Group. Це важливий крок до заміни наших поточних сторінок підтримки єдиним порталом IBM Support Portal. Тепер можна використовувати Support Portal і відсилати свої зауваження на [email protected] . Прочитайте статтю IBM Support Authority Введення в новий портал IBM Support Portal (EN), в якій наведено докладний опис можливостей IBM Support Portal.
• Чергове повідомлення 2009 3rd Quarter Proactive Email відправлено 17-го вересня! Щоквартальна поштова розсилка Proactive Email містить посилання на технічну документацію та інформацію, яка може допомогти вам краще використовувати програмне забезпечення IBM. Підпишіться на розсилку, відправивши на [email protected] лист з темою: <product>. Додаткова інформація розміщена на сторінці Proactive Email .
• WebSphere Support Technical Exchange тепер є на Facebook ! Пропонуйте теми для обговорення та слідкуйте за оновленнями.
• Продовжуючи тему WebSphere Support Technical Exchange: використовуйте в повній мірі можливості продуктів IBM, приєднавшись до наших Web-трансляцій WebSphere Support Technical Exchange, в яких технічні фахівці і експерти IBM по різним темам діляться своїми знаннями і відповідають на питання. Ви знайдете тут методики пошуку проблем, додаткову інформацію про продукти, поради та прийоми роботи з WebSphere Application Server, CICS® Transaction Server, WebSphere MQ, WebSphere Message Broker і багато іншого:

Продовжуйте стежити за різними web-сайтами підтримки , А також за цією рубрикою, де публікуються новини про інших інструментальних засобах.

А тепер - наша головна тема ...

Вступ

Дана стаття являє собою введення в програму діагностики Memory Dump Diagnostic for Java (MDD4J), яка допомагає аналізувати Java-купу з метою виявлення проблем пам'яті. Результати аналізу програмою MDD4J надаються в зведених звітах по використанню додатком Java-купи.

Існують три основні ситуації, в яких може бути корисна програма MDD4J:

• Витоку пам'яті. Якщо додаток страждає від виняткових ситуацій java.lang.OutOfMemoryError або докладні дані про збірку сміття вказують на поступове зростання споживання пам'яті, програма MDD4J дозволяє точно визначити структуру даних (і компоненти всередині цієї структури), які відповідальні за це зростання.
• Надмірне споживання пам'яті. Якщо програма не масштабується нормально або використовує більше пам'яті, ніж необхідно для його роботи, MDD4J може показати загальну картину структур даних, що займають надмірний обсяг пам'яті. Звіти MDD4J демонструють, як реалізація колекцій і інше моделювання даних можуть сприяти надмірного споживання пам'яті.
• Регресійне тестування. Різні аналітичні звіти та подання структур даних, що забезпечуються MDD4J, можуть допомогти стежити за змінами споживання пам'яті при виправленні помилок і додаються або видаляються нових функціональних можливостей.

Програма MDD4J доступна на IBM Support Assistant . Оскільки при аналізі дампов пам'яті використовується великий обсяг ресурсів процесора і системи введення / виводу, програму також можна запускати поза інструментального середовища IBM Support Assistant. Виконання аналізів дампов пам'яті на машині серверного класу, особливо на 64-розрядної, дозволяє обробляти дампи практично необмеженого розміру і звільняє на робочої станції достатньо ресурсів, щоб виконувати інші завдання.

Призначення MDD4J - отримання інформації, достатньої для ідентифікації проблем, без перевантаження зайвими даними. Цей пакет не надає надто докладних, низькорівневих, спеціалізованих функцій для ручного дослідження всього графа об'єктів в купі. Для ретельного аналізу дампов купи слід використовувати продукт IBM Monitoring and Diagnostic Tools for Java - Memory Analyzer .

Що таке дамп купи

Дамп купи (heap dump), також відомий під назвою знімка купи (heap snapshot), являє собою дамп посилань між об'єктами в пам'яті і інформацією про ці об'єкти. Дампи купи не містять такої інформації, як назви змінних, значення або вихідний код.

Дамп купи використовується для аналізу купи. Існує три способи генерування дампа купи:

• Автоматично. JVM зазвичай генерує дамп купи, коли пам'ять закінчується і JVM припиняє роботу.
• Вручну. Можна відправити в JVM сигнал із запитом згенерувати дамп купи. (В документації MDD4J наводиться інформація про те, як згенерувати дамп купи на різних платформах.)
• Програмно. IBM SDK for Java містить клас com.ibm.jvm.Dump. Використовуйте його статичний метод Heapdump () для генерування дампа купи під час роботи програми.

Аналіз дампов купи

MDD4J використовує різні терміни для файлів з дампом купи в залежності від того, коли вони були сформовані:

• Базовий дамп купи

  Незважаючи на те, що JVM генерує дамп купи при аварійному припиненні роботи, можна багато чого довідатися про використання пам'яті, порівнюючи цей дамп з дампом, що згенерував відразу після запуску програми. Такий дамп пам'яті, згенерований на ранньому етапі циклу життя програми, називається базовим дампом купи (baseline heap dump) і використовується при виконанні порівняльного аналізу.

• Первинний дамп купи

  Первинний ламп купи - це дамп, згенерований при виникненні проблеми, наприклад, при нестачі пам'яті або при надмірному використанні купи. Цей дамп пам'яті може генеруватися автоматично, коли у JVM закінчується пам'ять або вона завершується аварійно. Можна згенерувати його програмно або вручну, відправивши сигнал в JVM. Використовуючи первинний дамп купи, можна виконати окремий або порівняльний аналіз дампа купи.

  MDD4J дозволяє виконувати два різних типи аналізу дампа купи в залежності від кількості доступних дампов:

  • Як випливає з назви, окремий аналіз дампа купи виконується з одним дампом купи - первинним. Він показує загальну інформацію про купу, включаючи підозрілі на витік місця і значні за обсягом структури даних.
  • Порівняльний аналіз дампа купи використовує два дампа, базовий і первинний, і порівнює їх.

Під час аналізу MDD4J намагається виявити найбільш ймовірні підозрілі місця витоку пам'яті. Вони називаються підозрілими, тому що не існує точного способу ідентифікувати причину надмірного використання купи. Якщо при аналізі було ідентифіковано підозріле місце, це зовсім не означає, що є витік пам'яті саме в даному місці. Таке часто буває при реалізаціях кеш-пам'яті, які дуже схожі на типові витоку пам'яті.

Запуск і використання MDD4J

Щоб навчитися використовувати MDD4J, необхідно знати, що означають поняття, використовувані для опису витоків пам'яті. На малюнку 1 ці поняття показані на прикладі класу MyClass, що має HashSet, який містить рядкові об'єкти.

Малюнок 1. Поняття витоку пам'яті

• Джерело витоку - об'єкт, що містить посилання на ланцюжок об'єктів, що ведуть до контейнера витоку. Якщо в ланцюжку власників об'єктів класів не виявляється, відзначається кореневої об'єкт в дампі пам'яті, з якого можна досягти контейнера витоку.
• Контейнер витоку - об'єкт, який є винятковим власником всіх об'єктів, що викликають витік. В даному прикладі це HashMap.
• Модуль, що викликає витік - об'єкт в структурі даних, в якій присутні кілька екземплярів. В даному прикладі це об'єкти HashMap $ Entry всередині HashMap.
• Ланцюжок власників - ланцюжок об'єктів, починаючи з джерела витоку до об'єкта контейнера витоку.
• Вміст - реальні дані, відповідальні за надмірне споживання купи.

Інша інформація, що не показана на малюнку 1, але має відношення до витоку пам'яті:

• Розмір зони досяжності (reach size) - сумарний розмір усіх об'єктів, досяжних з даного об'єкта. В даному прикладі внесок в розмір зони досяжності джерела витоку все вносять об'єкти.
• Приєднаний розмір зони досяжності - різниця розмірів зони досяжності об'єкта і його дочірнього об'єкта. Ця різниця, разом з різницею в кількості примірників, є ключем для виявлення підозрілих місць витоку пам'яті.

MDD4J запускається аналогічно будь-якій іншій програмі, встановленої в інструментальному середовищі IBM Support Assistant. На малюнку 2 показана програма MDD4J в інструментальному середовищі після її запуску і завершення аналізу. Analysis Summary (підсумки аналізу) - це перша вистава, що відображається після завершення аналізу. (Якщо виконати експорт MDD4J з інструментальної середовища на іншу машину, з'явиться пакетний файл або файл сценаріїв командної оболонки для запуску програми.)

У наступних розділах ми розглянемо, як аналізувати результати, що надаються MDD4J. Інформація наведена для первинного дампа.

Оцінка результатів аналізу

Analysis Summary - це перша вистава, що відображається після завершення аналізу. У ньому показується підсумкова інформація про результати аналізу і надається короткий огляд вмісту купи і того, що займає найбільший обсяг. На цій панелі можна ідентифікувати компоненти і типи, що займають найбільший обсяг пам'яті купи.

Малюнок 2. MDD4J в інструментальному середовищі IBM Support Assistant

Подання Analysis Summary має три розділи:

У поданні Analysis Summary можна також перейти до звіту у вигляді одного файлу HTML (HTML Report) (рисунок 2), який містить підсумки результатів аналізу. Цей звіт містить всю інформацію, що відображається в різних уявленнях MDD4J, за винятком графічної. Цей звіт можна використовувати для швидкого інформування ваших колег про результати аналізу.

Можна також завантажити частину призначеного для користувача інтерфейсу MDD4J (вкладка Data Structures, що розглядається в цій статті нижче) в якості автономного звіту, званого Yeti Report (див. Рисунок 2), і зберегти вихідний архівний .zip-файл. Вийміть вміст архіву в порожній каталог і відкрийте файл index.html в Web-браузері. Додаткова інформація про Yeti приведена в статті Аналіз великих куп (EN).

Підозрілі місця витоку за розміром зоною досяжності

Це уявлення є відправною точкою для ідентифікації витоків пам'яті. Аналіз практично завжди ідентифікує підозрілі місця, але не всі з них є справжньою причиною витоків пам'яті. Підозрілі об'єкти упорядковано відповідно до розмірів їхніх зоною досяжності в порядку убування.

При аналізі ситуації переповнення пам'яті це основне джерело інформації. Якщо має місце надмірне споживання пам'яті, це уявлення також може надати корисну інформацію. Однак більш детальну інформацію забезпечує подання Data Structures.

Є два дочірніх уявлення, що показують підозрілі місця витоку, але ідентифіковані на різних рівнях (малюнки 5 і 6). У більшості випадків самі підозрілі об'єкти будуть однаковими в обох виставах, але якщо вони різні, важливо проаналізувати ці об'єкти з обох вистав.

• Рівень об'єднаних структур даних (малюнок 5) працює з сумарними даними примірників одного і того ж типу в ланцюжку власників. Підозрілі на витік пам'яті об'єкти групуються в таблиці, по одній на кожен джерело витоку. Назва джерела витоку відображається безпосередньо над таблицею і є гіперпосиланням на схему вмісту (content schematic). Схема вмісту - це графічне представлення ланцюжка власників нижче джерела витоку.
• Рівень об'єктів / класів (рисунок 6) працює з реальними екземплярами в оригінальному графі посилань купи. У більшості випадків показана інформація буде такою ж, що і в поданні на рівні об'єднаних структур даних.

Підозрілі місця витоку в інтегрованій даних

Є кілька таблиць, по одній на кожен джерело витоку, що відображають підозрілі місця, виявлені в дереві посилань нижче джерела витоку. Джерело витоку відображається над таблицею (малюнок 5) і є посиланням на графічне представлення ланцюжка власників джерела витоку, зване також схемою вмісту. Це графічне представлення допомагає зрозуміти взаємини між джерелом витоку, контейнером (контейнерами) витоку і модулем (модулями) витоку, показаними в таблиці. Таблиця відображає пару контейнерів витоку і модуль витоку разом з кількістю примірників модулів витоку і їх сумарним розміром.

Наприклад, на малюнку 5 показаний екземпляр класу EvaluateServlet як контейнер витоку і екземпляр класу ArrayList як тип витоку в першому рядку. Часто виявляється, що модуль витоку в одному рядку таблиці є контейнером витоку в іншому рядку цієї ж таблиці. Це означає, що містить додаткові контейнери.

Наприклад, в третьому рядку на малюнку 5 показаний екземпляр класу Analyzer, що містить екземпляр HashMap, а в четвертому рядку показано, що цей же HashMap містить 1000 примірників класу Analyzer $ Chunk.

Малюнок 5. Підозрілі об'єкти витоку на рівні об'єднаних структур даних

Щоб інтерпретувати інформацію, потрібно читати таблицю зверху вниз (малюнок 5). У деяких випадках, таких як розглянутий, може бути кілька різних витоків. Кожне число далі відповідає номеру рядка в таблиці.

1. Примірник EvaluateServlet містить один екземпляр ArrayList (розмір 78MБ).
2. Цей ArrayList містить один екземпляр Analyzer.
3. Цей Analyzer містить один екземпляр Hashtable.
4. Цей Hashtable містить 629 примірників Chunk, які є внутрішнім класом Analyzer.
5. Кожен екземпляр Chunk містить один ArrayList.
6. Всі екземпляри ArrayList в 1000 примірниках Chunk містять 500000 примірників String із загальним розміром 76 МБ.
7. Наступний екземпляр Chunk містить один екземпляр Hashtable (розмір 49MБ).
8. Ця Hashtable містить 629 примірників Chunk.
9. Кожен екземпляр Chunk містить ArrayList.
10. Все ArrayList в 1000 примірниках Chunk містять 314500 примірників String загальним розміром 48 Мб.

Підозрілі об'єкти витоку на рівні об'єктів / класів

Це більш просте уявлення, ніж список підозрілих об'єктів витоку на рівні об'єднаних даних. Таблиця підозрілих об'єктів на рівні об'єктів / класів (рисунок 6) показує список джерел витоку і їх контейнери витоку разом з сумарним розміром контейнера і приєднаним розміром зоною досяжності всіх модулів витоку. Як згадувалося раніше, цей список буде містити ті ж самі підозрілі об'єкти, що і список в поданні на рівні об'єднаних структур даних (малюнок 5).

Малюнок 6. Підозрілі об'єкти витоку на рівні об'єктів / класів

На малюнку 6 показані ті ж витоку, що і на малюнку 5. Різниця сумарних розмірів виникає через те, що подання на рівні об'єднаних структур даних використовує сумарні кількості примірників, а уявлення на рівні об'єктів / класів використовує реальні кількості примірників і розміри.

Використання уявлень підозрілих об'єктів витоку

Читання інформації з обох уявлень підозрілих об'єктів витоку потрібно починати з першого рядка таблиць. Через складність ідентифікації витоків останні підозрілі об'єкти в списку можуть зовсім не бути витоками, якщо їх розмір контейнера витоку менше 5-10% розміру купи (показано в поданні Analysis Summary на малюнку 2). Такі невеликі витоку можна проігнорувати.

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

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

таблиці об'єктів

Подання Object Tables містить два дочірніх уявлення, які перераховують всі класи і екземпляри кожного класу в купі. Використовуйте уявлення у вкладці Object Tables для отримання додаткової інформації про кількість певних об'єктів і класів, які є в купі, або для перевірки розміру підозрілого об'єкту витоку.

Дані в обох таблицях можуть бути відсортовані за будь-якому стовпцю шляхом натискання на заголовок стовпчика. Повторне натискання лівою кнопкою миші на стовпці змінює порядок сортування. На малюнку 7 показана таблиця, відсортована за кількістю примірників в порядку спадання.

Малюнок 7. Таблиця об'єктів, відсортована за кількістю примірників

структури даних

Подання Data Structures (рисунок 8) містить додаткові подробиці про внутрішній устрій структур даних програми. Ці візуалізації засновані на технології Yeti, розробленої групою IBM Research.

Малюнок 8. Представлення Data Structures

Інформація, показана в цьому поданні, може допомогти зрозуміти вид і взаємозв'язок структур даних в дампі купи. Yeti-візуалізації автоматично групують разом екземпляри об'єктів в більші зв'язкові модулі. Це позбавляє від необхідності ручного навігації по окремих об'єктах і посиланнях, а також дає загальне уявлення про причини розростання обсягу структур даних. Ці візуалізації допомагають:

• Ідентифікувати найбільші структури даних в Java-купі.
• Відстежити зміни розміру цих структур даних у часі.
• Швидко розібратися у внутрішньому устрої структури даних.
• Виявити проблеми моделювання даних в додатку, що призводять до переповнення пам'яті.
• Дослідити структури даних по програмним компонентам, які беруть участь в споживанні.

Подання містить вкладки зліва і інформаційну панель праворуч. Є чотири вкладки: Big (рисунок 9), Growing (рисунок 10), Shrinking (рисунок 11) і Steady (рисунок 12).

Малюнок 9. Великі структури даних

Малюнок 10. Збільшуються структури даних

Малюнок 11. Скорочуються структури даних

Малюнок 12. Стійкі структури даних

При аналізі одного дампа купи буде заповнюватися тільки вкладка Big. При аналізі двох дампов купи вкладки Growing, Shrinking і Steady будуть містить списки структур даних, розмір яких змінився або залишився колишнім і при цьому вносить істотний внесок в розмір дампа купи. Разностная інформація відображається на схемі вмісту червоним кольором.

Інформаційна панель в правій частині подання Data Structures (рисунок 8) відображає інформацію або для всієї купи, або для обраної структури даних. Є дві вкладки - Overview (огляд) і Health Report (звіт про стан), - які містять інформацію для дампа купи в цілому (рисунок 13) або для структури даних, обраної у вкладці Big, Growing, Shrinking або Steady (рисунок 14).

Малюнок 13. Огляд всієї купи

Малюнок 14. Огляд однієї структури даних

На малюнках 15 і 16 наведені діаграми, розташовані в вкладці Health Report. В даному випадку вони показують загальний стан (health) примірника EvaluateServlet.

Малюнок 15. Загальний стан EvaluateServlet

Малюнок 16. Загальний стан EvaluateServlet (продовження)

Дослідження структур даних

Першим поданням, яке ви побачите, є стовпчасті діаграма, що відображає найдорожчі за витратами пам'яті структури даних в купі. Назви, відмічені словом "statics", вказують структури даних, що походять від статичного поля даного класу. Наведені нижче інструкції описують, як досліджувати структури даних; інструкції застосовні для структур даних, що відображаються у всіх вкладках.

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

Малюнок 17. Розміри структур даних

Загальний розмір показує, який обсяг структури даних можна досягти з інших структур даних. Іншими словами, він показує ті структури даних, які спільно використовуються іншими структурами даних. Можна вибрати структуру даних для більш детального дослідження її вмісту. При натисканні лівою кнопкою миші на прямокутнику в будь-який столбчатой ​​діаграмі структур даних права частина вікна буде оновлена, і в ній відобразиться вихідна зведена інформація про вміст обраної структури. На малюнку 18 показана інформація, яка відображається при натисканні прямокутника EvaluateServlet, показаного на малюнку 17.

Малюнок 18. Зведена інформація про EvaluateServlet

При відсутності спільного використання список розділів буде містити єдиний запис, що представляє всю структуру даних. Якщо частини структури даних використовуються спільно з іншими структурами даних, список розділів буде містити записи для кожної спільно використовуваної частини. Кожен розділ є дочірньою структурою даних (sub-data structure), в якій всі об'єкти є унікальними частинами цього розділу. У списку розділів ви побачите відмінності між розділами, які є частиною цієї структури і також частиною інших (відзначені в кінці словом "(shared)"), і тими розділами, які є унікальною частиною цієї структури (без цього суфікса).

Дослідження схеми вмісту

Щоб більше дізнатися про внутрішню структуру розділу, клацніть лівою кнопкою миші на підкресленому назві типу структури даних або натисніть посилання data structure для вибору структури колекції (рисунок 19). З'явиться спливаюче вікно зі схемою вмісту обрана Вами (рисунок 20).

Малюнок 19. Вибір типу структури даних

Схема вмісту коротко показує, що саме збільшує розміри структури даних. Вона показує, як структура даних використовує колекції (наприклад, HashMap або Vector) для структурування елементів структури даних. На малюнках 20 і 21 наведені приклади схем вмісту. Схема читається як UML- або ER-діаграма (Entity-Relation), де кожен вузол являє або інфраструктуру колекції (наприклад, як стандартна бібліотека реалізує HashMap), або що містяться суті цільової програми (наприклад, String-ключі в карті). В обох випадках, і для колекцій, і для містяться сутностей, схема вмісту приховує деталі реалізації і відображає число, яке є сумарним розміром деталей реалізації цієї сутності.

Малюнок 20. Схема вмісту EvaluateServlet

На малюнку 20 показана схема вмісту EvaluateServlet. Для деяких вузлів ім'я класу не відображається, оскільки ці екземпляри не приймають істотної участі в розмірі примірника кореневого класу. Ця схема вмісту показує виділення простору для 500 000 примірників String.

На малюнку 21 показаний приклад більш складної схеми вмісту.

Малюнок 21. Складна схема вмісту

Граф типів

Якщо вузол в схемі вмісту виглядає підозріло великою, можна опуститися до подання, що відображає деталі реалізації цієї сутності. Для цього двічі клацніть лівою кнопкою миші на будь-якому вузлі в схемі вмісту. З'явиться ще одне спливаюче вікно з графом типів обраної суті. На малюнку 22 показаний граф типів для Hashtable, посилання на яку розташована в ланцюжку власників нижче EvaluateServlet (рисунок 20). Граф типів показує, як взаємопов'язані класи (типи даних) сутності і як кожен тип бере участь у формуванні загального розміру цієї сутності в схемі вмісту обраної структури даних.

Малюнок 22. Граф типів Hashtable

Подання схеми полів

Якщо вузол в графі типів здається підозріло великою, можна двічі клацнути на ньому лівою кнопкою миші для переходу до подання схеми полів (малюнок 23). Для знімків купи, що підтримують ці дані (в даний час тільки HPROF), це уявлення показує, як поля обраного класу (і ієрархія успадкування цього класу) беруть участь у формуванні загального розміру його примірника. Часто розробники додають багато полів в класи, не усвідомлюючи, що кожне поле int, яке вони додадуть в клас, буде помножено багаторазово (на кількість примірників) під час виконання. Наприклад, розробники часто додають поля для кешованих обчислень або поля, необхідні тільки на етапі створення і зазвичай не потрібні на більш тривалому етапі використання програми.

Малюнок 23. Подання схеми полів

Виконання MDD4J поза IBM Support Assistant

IBM Support Assistant надає зручну централізовану платформу, що дозволяє виявляти, встановлювати, виконувати і отримувати регулярні оновлення для широкого різноманіття інструментальних засобів визначення проблем, тому слід продовжувати її використовувати для отримання регулярних оновлень MDD4J. Однак аналіз дуже великих дампов купи може зайняти значну частину ресурсів процесора і системи введення / виводу стандартної робочої станції на істотний період часу. У таких ситуаціях може бути бажано виконати аналіз на машині серверного класу. Детальні інструкції по запуску програми поза ISA можна знайти в довідковій системі MDD4J (рисунок 24).

Малюнок 24. Виконання MDD4J поза ISA

Висновок

Тепер, коли ви знаєте про потужні можливості інструментальної програми MDD4J (Memory Dump Diagnostic for Java) за визначенням витоків пам'яті і виявлення проблем використання пам'яті інших типів, ви готові вирішувати проблеми, якщо виникне підозра, що додаток некоректно управляє Java-купою. Вивчіть інші доступні в IBM Support Assistant інструментальні засоби для подальшого вдосконалення вашого арсеналу інструментів усунення проблем.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів