2010-02-16 2 views
0

Это выход после работы около 10 минут.Что такое хорошая стратегия настройки gc для вывода gc, которую у меня есть?

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] 

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

+2

Итак ... в чем проблема? – cletus

+0

Проблема заключается в том, что у приложения заканчивается память после запуска некоторое время. Я думаю, что это связано с gc. В моем модульном тесте, если я вызываю gc явно, я восстанавливаю выделенную память, но этого не происходит, когда запущено полное приложение. поэтому я хотел бы знать, как настроить gc – Guru

+0

Просьба предоставить немного больше информации, например, JVM Version, Hardware, JVM Arguments – phisch

ответ

2

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

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

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

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

+0

Спасибо за комментарий. Но на выходе я замечаю, что текущее пространство для молодых поколений вообще не используется. Не уверен, насколько это поможет. Я проверю другие инструменты, о которых вы упоминали. – Guru

1

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

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

0

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

Смежные вопросы