Как помочь процессам Java Tomcat восстановить использованную память?

Question

Мы запускаем веб-приложение, которое использует Java 64bit 5 гигов -Xmx максимального размера кучи. Мы не имеем никакого контроля над кодом Java. Мы можем только настроить параметры конфигурации. Ситуация, с которой мы сталкиваемся, заключается в том, что java-процессы после того, как он занимает всю кучу, выделенную при запуске, начинает работать очень медленно, очень медленно реагируя на запросы веб-сайтов. Я предполагаю, что GC ожидает сбора неиспользуемых объектов памяти.

Изображение ниже покажет вам изображение top в linux, которое показывает критическую ситуацию процессов.

верхнее изображение процесса Java http://cp.images.s3.amazonaws.com/ForumImages/java-gc-issue.jpg

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

РЕДАКТИРОВАТЬ 1: Я использовал некоторые из ответов ниже, чтобы получить ответ на свой вопрос. С моим вопросом было слишком сложно ответить, и это оказалось обсуждением. Я опубликую, как мне удалось контролировать циклы GC, и я выберу ответ с большим количеством голосов. Я использовал jconsole через реальный просмотрщик vnc, чтобы иметь возможность подключаться с моей машины с Windows к моей машине с Linux, работающей на tomcat.

Я использовал эти параметры для запуска процессов Java:

-Djava.awt.headless=true -server -Xms512m -Xmx5120m -Dbuild.compiler.emacs=true -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=4999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

Это тип вывода, который я получил, из jconsole через vnc viewer. GC Образец изображения http://cp.images.s3.amazonaws.com/ForumImages/Sample_GC_Image.jpg

Answer 1

Я бы порекомендовал вам не догадываться. Получить некоторые данные, чтобы точно узнать, что происходит. Вы можете использовать visual gc , чтобы увидеть, что происходит.

Если заполнено пространство для перми, вы ничего не сможете сделать.

Какая JVM? Если оно 5 или выше, есть дополнительные параметры, помимо максимального размера кучи, который вы можете настроить. Проверить http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

Answer 2

Похоже, у вас утечка памяти, если ваше приложение становится все медленнее. GC всегда начнет очищать неиспользуемые объекты, как только это потребуется. Если вы добавите -verbosegc, вы сможете увидеть, как часто выполняется сборщик мусора, а после сборщика памяти много свободного места. Если используется куча более 80%, вам нужно либо увеличить максимальную память, либо исправить программу, чтобы она не использовала так много.

Можете ли вы сделать numactl --hardware? Я советую вам не использовать более 80% одного банка памяти, иначе время GC резко возрастет.

Answer 3

Попробуйте запустить приложение с параметрами -verbose:gc -Xloggc:/path/to/where/you/want/gc.log и изучите полученный gc.log; он должен сказать вам, сколько времени тратится на сборку мусора. Или, как предлагает Даффимо выше, используйте visualGC, чтобы получить те же данные.

Убедитесь, что вы используете соответствующий коллектор - вам, вероятно, нужны коллекторы с параллельной или малой паузой (CMS), если вы используете Java 5.

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

Answer 4

Похоже, вам нужно узнать подробности о том, что использует стек. Для этого я рекомендую JMAP (http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html), который можно запустить по идентификатору процесса (PID), чтобы увидеть, что использует память. Несколько раз делайте снимки JMAP во время работы приложения и смотрите, какие классы не освобождают стек.

Приветствия

-Ричард