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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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