Кто-нибудь нашел полезной настройку Garbage Collection?

Question

Я прочитал множество статей о настройке GC в Java и часто задавался вопросом, сколько людей действительно используют некоторые из более продвинутых функций.

Я всегда избегал настройки там, где это было возможно, и концентрировался на написании максимально простого кода, который я могу (совет Брайана Гетца) - до сих пор мне это удавалось.

Устойчивы ли эти стратегии настройки для разных версий виртуальных машин или они требуют постоянной переоценки?

Одна настройка, которую я использовал, это флаг -server.

Answer 1

Частью моей текущей работы является уход и поддержка большого Java-приложения, которое было разработано для работы с большим объемом памяти (в настоящее время около 8 Гб), в основном из-за текущих вычислений с большим количеством кэшированных данных. Первоначальное развертывание я выполнял со стандартной настройкой GC, в основном потому, что не было простого способа имитировать производственную среду, работающую с полным наклоном.

Постепенно, в течение следующих нескольких месяцев, я настроил параметры ГХ. Как правило, самая большая из доступных ручек, по-видимому, регулирует частоту и величину инкрементального gc - самое большое улучшение было в обмене больших периодических gc на более мелкие и более частые. Но мы определенно смогли увидеть улучшения производительности.

Я не собираюсь публиковать свои конкретные настройки, потому что а) они относятся к нашей настройке, и б) потому что они у меня не под рукой :). Но в общем то, что я нашел, это

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

Вот хорошая справка из пред. Обсуждение stackoverflow.

Answer 2

Подавляющему большинству разработчиков никогда не придется (или не захочет) настраивать GC. Я работал с людьми, которые должны были настроить это, и вот совет:

Прежде чем пытаться настроить мусор коллекционер уверен на 100% проверено, с профайлером. что такое продолжается. Как только вы начнете настраивать, сделайте с профилировщиком убедитесь, что это имело положительный эффект.

Вам также следует пересмотреть изменения с каждой версией виртуальной машины, на которой вы работаете (разные виртуальные машины будут иметь разные стратегии настройки).

Однажды я помог кому-то с проблемой GC, которая оказалась не закрывающей наборы результатов JDBC (или что-то подобное). Это привело к тому, что память никогда не освобождалась (его код почему-то держался за них) Исправление этой проблемы заставило программу работать с 20 минут до 30 секунд или пары минут. Использование памяти также сократилось.

Answer 3

Я должен сказать, что у меня не было необходимости самому сильно настраивать. Но я тесно сотрудничаю с людьми, которые пишут код, для которого важна задержка: они часто используют такую ​​настройку - указание, какой алгоритм GC использовать, максимальное время паузы, коэффициенты выживания и т. Д.

Я полагаю, что ответ таков: если задержка имеет решающее значение для приложения, вам, возможно, придется взглянуть на настройку своего GC

Answer 4

У меня есть, но не в последнее время. Приложение, над которым я работал, представляло в реальном времени рендеринг видеопотока, созданного из отдельных изображений JPEG в движении. В то время (около JDK 1.2 и 1.3) параметр -Xincgc переключал бы сборщик мусора клиента с большей очистки большого взрыва на режим, в котором часть мусора регулярно очищалась. В результате распределение задержек кадров было намного ниже, создавая впечатление более плавного видео (вместо 1-2-3-паузы, 1-2-3-паузы).

Я давно не смотрел этот код, но я сильно подозреваю, что с современными алгоритмами сбора мусора -Xincgc фактически снизит производительность.

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

Answer 5

Я бы сказал, что наиболее распространенная настройка - это максимальный объем памяти. Большинство других опций памяти имеют разумные значения по умолчанию и часто переустанавливаются IMHO. т.е. когда это действительно не имеет большого значения. Я часто вижу, что люди устанавливают много вариантов, когда половина из них по умолчанию в любом случае. ;)

Использование профилировщика является наиболее полезным способом улучшения поведения GC (за счет уменьшения количества создаваемых объектов)

Answer 6

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