Осторожно .... GC может быть волосатым предметом, если вы не будете осторожны. В любой среде выполнения (JVM для Java / CLR для .Net) происходит несколько процессов. Как правило, существует ранняя стадия оптимизации памяти (Сборка мусора молодого поколения / Сборщик мусора молодого поколения и Сборка мусора старого поколения / Сборщик мусора старого поколения). Молодой ген gc происходит регулярно и обычно приписывается вашим меньшим паузам / сбоям. Старый gen gc - это обычно то, что происходит, когда вы видите длинные паузы "останови мир".
Почему вы можете спросить? Причина, по которой вы получаете паузы с вашей средой выполнения / JVM, заключается в том, что когда среда выполнения очищает от кучи, она должна пройти через то, что называется изменением фазы. Он останавливает потоки, выполняющие ваше приложение, чтобы помечать и менять местами указатели для оптимизации доступной памяти. Yong gen быстрее, поскольку он в основном выпускает объекты, которые являются только временными. Однако, старый ген оценивает все объекты в куче, и когда у вас закончится память, он пойдет, чтобы освободить столь необходимую память.
Почему осторожно? Старый ген экспоненциально ухудшается во время паузы, чем больше кучи вы используете. при общем объеме кучи 2-4 ГБ у вас все будет хорошо в современных средах выполнения, таких как Java 6 (JDK 1.6+). Когда вы выйдете за пределы этого предела, вы увидите экспоненциальное увеличение времени паузы. Я столкнулся с некоторыми клиентами, которым приходится перезапускать серверы - как в некоторых редких случаях, когда куча велика, время приостановки GC может занять больше времени, чем полный перезапуск.
Есть несколько новых инструментов, которые довольно круты и могут дать вам преимущество в оценке, если GC - ваша боль. JHiccup - один из них, и он бесплатный с сайта azulsystems . В настоящее время я думаю, что это только для Linux. У них также есть JVM с восстановленным алгоритмом GC, который работает без пауз ... но если вы используете развертывание на одном сервере с некритическим приложением, это может быть экономически не выгодно (это не бесплатно).
Подводя итог - если ваша куча времени выполнения / JVM / CLR меньше 2 ГБ, добавление дополнительной памяти поможет. Не забудьте дать себе немного накладных расходов. Вы никогда не захотите достичь 100% размера кучи / объема памяти, если это возможно. Это когда длинные паузы самые длинные. Дайте себе дополнительно 20% + памяти сверх того, что, по вашему мнению, вам понадобится. Таким образом, у алгоритмов GC есть место для перемещения объектов для оптимизации. Если вы когда-нибудь планируете стать крупным ... есть один инструмент, который исправляет технологию JVM примерно 1990 года (Azul Systems Zing JVM), но она не бесплатна. Они предлагают инструмент с открытым исходным кодом для диагностики проблем GC. В JVM (как я уже пробовал) также есть действительно классный инструмент видимости на уровне потоков, который позволяет вам сообщать о любых утечках, ошибках или блокировках в работе без дополнительных затрат (некоторый прием с выгрузкой данных, с которыми JVM уже имеет дело, и отметками времени). Это сэкономило тонны времени тестирования разработчиков ... но опять же, не для небольших приложений.
Оставайтесь ниже 4 ГБ. Дайте дополнительный запас. И если вы хотите, вы можете включить эти флаги для мониторинга GC для Java / JVM:
java -verbose:gc myProgram
java -Xloggc:D:/log/myLogFile.log -XX:+PrintGCDetails myProgram
Вы можете попробовать другие коллекторы, которые использует Hotspot. Их больше одного.
Если вы работаете в Linux, попробуйте и инструмент JHiccup. Это бесплатно.