Изменение поведения сборщика мусора после перехода с Java5 на 6

Недавно мы перенесли наши системы с Sun Java 5 на виртуальную машину сервера Java6 (в частности, 1.6.0_16 в 32-разрядной версии Linux). Мы заметили, что поведение сборки мусора изменилось таким образом, что сработала наша система мониторинга предупреждений о куче.

Графики использования кучи указывают на гораздо более «пиковый» профиль использования памяти, чем мы видели с Java5, когда виртуальная машина позволяет использовать кучу очень высоко перед запуском большого сборщика мусора. Похоже, что это не проблема с самой прикладной системой (у нее никогда не заканчивается память), но она дает системе мониторинга случайные ложные сигналы «волосы в огне» всякий раз, когда всплеск использования приближается к пороговому значению.

Мы могли увеличить максимальный размер кучи и надеяться, что пик не станет больше, но я бы предпочел узнать, есть ли способ настроить параметры JVM таким образом, чтобы получить более плавный профиль, даже если мы немного потеряем производительность.

Я предполагаю, что может быть какой-то параметр -XX, который мы можем установить для этого, но я не вижу ничего такого в документации. Кто-нибудь знает о таком варианте?


person skaffman    schedule 03.12.2009    source источник
comment
Это также интересно и касается нового сборщика G1: blogs.sun.com/jonthecollector/entry / our_collectors   -  person skaffman    schedule 11.12.2009


Ответы (3)


Похоже, вы действительно хотели бы иметь что-то более похожее на concurrent коллекция (в отличие от стандартных коллекций большого взрыва):

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

Возможно, что еще более важно, вы должны убедиться, что используете правильную виртуальную машину с правильными параметрами, помимо определенных параметров сборки мусора. Например, я наткнулся на виртуальную машину клиента против сервера выдавать несколько раз в моей жизни.

person Bob Cross    schedule 03.12.2009
comment
Concurrent GC значительно улучшил профиль кучи, и вы правы, низкая задержка за счет пропускной способности лучше подходит для наших приложений. Спасибо за предложение и сохраните файл cookie. - person skaffman; 11.12.2009


Можете ли вы подтвердить, что используется та же схема / механизм GC? Вы рассчитываете более высокие накладные расходы на сборку мусора в версии 1.6 или время пауз больше в течение любой заданной продолжительности?

Директивы max и min без кучи также могут помочь с некоторой эргономикой вашей кучи.

-XX:MinHeapFreeRatio и -XX:MaxHeapFreeRatio

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#generation_sizing.total_heap

person Jé Queue    schedule 03.12.2009
comment
Похоже, заметного влияния на производительность нет. Я полностью ожидаю, что Java6 использует совсем другую схему сборки мусора, чем Java5, и я не особо разборчив в этом; Я просто не хочу, чтобы он летел так близко к проводу, как он летает. - person skaffman; 03.12.2009
comment
Схема означает, что IIRC в Java5 люди неожиданно заметили параллельную очистку, вводимую по умолчанию, если у них был ›1 ЦП, но значения по умолчанию, которые, как я думаю, должны быть такими же в 6, что и в 5. Вы могли бы скорее попробовать инкрементный или оптимизирован для пропускной способности GC, так как это должно примерно амортизировать GC немного больше. - person Jé Queue; 03.12.2009