JVM Tenured / Old gen достиг предела и зависания сервера
Наше приложение требует очень большой памяти, так как оно имеет дело с очень большими данными. Поэтому мы увеличили максимальный размер кучи до 12 ГБ (- Xmx).
Ниже приведены детали окружающей среды
OS - Linux 2.6.18-164.11.1.el5
JBoss - 5.0.0.GA
VM Version - 16.0-b13 Sun JVM
JDK - 1.6.0_18
Мы имеем над env & конфигурацией в нашем QA & prod.
В QA у нас есть max PS Old Gen (Heap memory), выделенный как 8,67 ГБ, тогда как в Prod это всего лишь 8 ГБ.
В Prod для конкретного задания старый Gen Heap достигает 8GB, зависает там и веб-URL становится недоступным. Сервер спускается.
Но в QA он также достигает 8,67 ГБ, но полный GC выполняется, и его возвращение составляет 6,5 ГБ или что-то в этом роде. Здесь его не повесят.
Мы не смогли найти решение для этого, потому что и среда, и конфигурация на обоих ящиках одинаковы.
У меня здесь 3 вопроса,
2/3 максимальной кучи будет выделено для
старый / арендованный ген. если это так
почему это 8GB в одном месте и 8.67 GB
в другом месте?
Как обеспечить допустимое соотношение для Новый
а срок пребывания в этом случае (12 ГБ)?
Почему он полон GCed в одном месте и
а в другой-нет?
Любая помощь была бы действительно ощутимой. Спасибо.
Пожалуйста, дайте мне знать, если вам нужны дополнительные сведения о env или conf.
2 ответов:
По вашим конкретным вопросам:
Соотношение по умолчанию между новым и старым поколениями может зависеть от системы, и то, что JVM определяет, будет лучшим.
- , чтобы определить конкретное соотношение между новым и старым поколениями с помощью
-XX:NewRatio=3.- Если ваш JVM висит, а куча полна, он, вероятно, застрял, делая постоянные GC.
Похоже, что вам нужно больше памяти для prod. Если на QA запрос заканчивается, то, возможно, что дополнительные 0.67 ГБ-это все, что ему нужно. Тот хотя, похоже, это не оставляет вам большого пространства для маневра. Вы выполняете тот же тест на QA, что и на prod?
Поскольку вы используете 12 ГБ, вы должны использовать 64-разрядную версию. Вы можете сэкономить объем памяти 64-разрядной адресации, используя опцию
-XX:+UseCompressedOops. Он обычно экономит 40% памяти, поэтому ваши 12 ГБ пойдут намного дальше.В зависимости от того, что вы делаете, параллельный коллектор также может быть лучше, особенно для сокращения времени длительной паузы GC. Я бы рекомендовал попробовать эти варианты, поскольку у меня есть нашел, что они хорошо работают:
-Xmx12g -XX:NewRatio=4 -XX:SurvivorRatio=8 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68
Вам нужно получить больше данных, чтобы знать, что происходит, только тогда вы будете знать, что нужно исправить. На мой взгляд, это означает
Получите подробную информацию о том, что делает сборщик мусора, эти параметры являются хорошим началом (замените некоторый предпочтительный путь и файл вместо gc.log)
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime -Xloggc:gc.log -verbose:gcПовторите запуск, просмотрите журнал gc за период, когда он висит , и отправьте назад с этим выводом
Рассмотрим наблюдая за выводом с помощью visualgc (требуется jstatd, работающий на сервере, одна случайная ссылка, которая объясняет, как сделать эту настройку, является Эта ), которая является частью jvmstat , это простой способ увидеть, как различные поколения в куче имеют размер (хотя, возможно, не для 6 часов!)
Я также настоятельно рекомендую вам тоже немного почитать, чтобы вы знали, к чему относятся все эти переключатели, иначе вы будете слепо пробовать вещи без реального понимания почему 1 вещь помогает, а другая нет. я бы начал со страницы настройки oracle java 6 gc, которую вы можете найти здесь
Я бы предложил изменить параметры только после того, как у вас есть базовая производительность. Сказав, что
CompressedOops, скорее всего, будет легкой победой, вы можете отметить, что он был по умолчанию включен с 6u23.Наконец, вы должны рассмотреть возможность модернизации jvm, 6u18 становится немного и производительность продолжает улучшаться.
Выполнение каждого задания займет 3 часа и почти 6 заданий, выполняемых одно за другим. Последнее задание при запуске достигает 8GB max и получение зависания в prod
Связаны ли эти рабочие места вообще? это действительно похоже на постепенную утечку памяти, если они не работают с одним и тем же набором данных. Если использование кучи продолжает расти и в конечном итоге взрывается, то у вас есть утечка памяти. Вы должны рассмотреть возможность использования
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/some/dir, чтобы поймать дамп кучи (хотя обратите внимание, что с кучей 13G это будет большой файл, поэтому убедитесь, что у вас есть дисковое пространство), если/когда он взорвется. Вы можете затем используйте jhat , чтобы посмотреть, что было в куче в то время.
Comments