Как записать и построить график времени жизни объекта для приложений Java? - PullRequest
3 голосов
/ 09 июня 2011

Мы хотим настроить размеры пула генерации памяти для нашего Java-приложения.Для этого нам нужно сначала понять, как используется куча.По сути, нам нужно знать число, размер и время жизни для каждого объекта в куче JVM.После того, как мы соберем эти данные, мы сможем найти более подходящие размеры для наших пулов молодого и опытного поколения.

Мы основываем наши усилия по настройке на информации, найденной в документе «Настройка сборки мусора с 5.0 JVM» отвС / Oracle.В разделе 3 (http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.%20Generations%7Coutline) они обсуждают размеры генерации и показывают пример на графике времени жизни объекта. В значительной степени то, что мы пытаемся достичь для нашего приложения.

Пока мы смогли записатьколичество экземпляров для данного класса и их соответствующие размеры в памяти. Однако я не могу найти способ извлечения средней продолжительности жизни экземпляра. Сейчас мы изучаем jProfiler, но пока безуспешно.

Кто-нибудь был успешным в графике среднего времени жизни объекта для приложений Java?

1 Ответ

2 голосов
/ 17 июля 2011

Для настройки GC вам обычно не требуется время жизни каждого объекта, а хороший обзор пулов в реальном времени.Первое, что я обычно делаю, это смотрю на различные пулы, используя visualgc, который является частью jvmstat (http://java.sun.com/performance/jvmstat/).). Затем я перехожу к проверке на возможные утечки памяти. Это, безусловно, лучший способ, с которым я столкнулся.

А. В jconsole вы можете увидеть, не перетекали ли вы в старый род преждевременно (это означает, что eden был слишком большим, чтобы поместиться в оставшегося в живых даже после его gc). Если это так, проверьте свой молодой размери соотношение выживших и попытайтесь отрегулировать их так, чтобы оно не переполнялось.

B. Кроме того, во время «нормальной» работы рекомендуется взглянуть на гистограмму поколений выживших в visualgc и убедиться, что поколенияопустошены задолго до того, как станут слишком старыми.

Если они все-таки разойдутся таким образом, у вас может возникнуть утечка памяти. Затем я бы сбросил память с помощью jconsole и взглянул бы на нее с помощью MAT (http://www.eclipse.org/mat/):

  1. Запустите jconsole.exe и вызовите операцию dumpHeap () в HotSpotDiagnostic MBean (убедитесь, что имя файла заканчивается на .hprof)
  2. Откройте дамп в MAP и посмотрите, узнаете ли вы какой-либо объект, занимающий больше места, чем вы ожидаете.

Удачи.

...