Какая у меня хорошая стратегия настройки gc для вывода gc? - PullRequest
Новая
       11

Какая у меня хорошая стратегия настройки gc для вывода gc?

0 голосов
/ 16 февраля 2010

Это выход после работы в течение примерно 10 минут. 

Heap
 PSYoungGen      total 7040K, used 0K [0x24060000, 0x247c0000, 0x26790000)
  eden space 6528K, 0% used [0x24060000,0x24060000,0x246c0000)
  from space 512K, 0% used [0x246c0000,0x246c0000,0x24740000)
  to   space 512K, 0% used [0x24740000,0x24740000,0x247c0000)
 ParOldGen       total 48896K, used 43303K [0x06990000, 0x09950000, 0x24060000)
  object space 48896K, 88% used [0x06990000,0x093d9d80,0x09950000)
 PSPermGen       total 12288K, used 3737K [0x02990000, 0x03590000, 0x06990000)
  object space 12288K, 30% used [0x02990000,0x02d366c0,0x03590000)
[GC [PSYoungGen: 0K->0K(7040K)] 43303K->43303K(55936K), 0.0005129 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System) [PSYoungGen: 0K->0K(7040K)] [ParOldGen: 43303K->43303K(48896K)] 43303K->43303K(55936K) [PSPermGen: 3737K->3737K(12288K)], 0.1964557 secs] [Times: user=0.36 sys=0.00, real=0.19 secs]

Заранее спасибо

Ответы [ 3 ]

2 голосов
/ 16 февраля 2010

Я бы рекомендовал использовать что-то вроде JConsole (JDK 1.5+) или jVisualVM (JDK1.6).Одного вывода printgc недостаточно, чтобы дать хорошую рекомендацию.

Обычно есть две проблемы: вы создаете слишком много новых объектов, новые поколения быстро заполняются, и, таким образом, gc перемещает все эти объекты в пространство выживших или даже в поколение перми.Если это то, что происходит (они удаляются со следующим полным gc, что занимает больше времени), я бы порекомендовал увеличить поколение Young / New.(-XX: NewSize).Это позволяет объектам получать ссылки и удаляться обычным gc.

Если у вас много долгоживущих объектов, я бы проверил, действительно ли это необходимо.Это может означать, что вы должны изменить код.

Имейте в виду, что большая куча занимает больше времени для gc по сравнению с маленькой кучей.

1 голос
/ 17 февраля 2010

Если у вас недостаточно памяти, проблема не в GC, а в том, что вы используете слишком много объектов и не освобождаете их.

В последний раз я беспокоился о сборке мусора в Java в 1998 году.

0 голосов
/ 12 января 2011

Возможно, вам нужно слишком много больших объектов, создаваемых (и не выпускаемых) из вашего приложения? Я действительно не знаю Java GC, но, исходя из .NET, большие объекты помещаются в отдельную кучу больших объектов, которая не сжимается GC. В приложении, использующем шаблон распределения занятости, это может привести к фрагментации в LOB ->, что, в свою очередь, часто вызывает те неприятные исключения OutOfMemory (OOM). Более того, коллекции LOB всегда являются коллекциями второго поколения. Это значит, они дорогостоящие! Таким образом, чистым решением будет внедрение пула. Реализуйте шаблон удаления для ваших больших объектов и убедитесь, что они будут добавлены в пул после использования. Повторно используйте их для новых объектов, возвращая их из пула. Еще раз, это применимо, только если у вас слишком много больших выделений. Таким образом, вы можете очистить это в первую очередь.

...