Три часа, потраченных на то, чтобы GC сбила 1,2 Гбайт кучи, что может быть причиной?

на одном из наших серверов Garbage Collection заняла почти три часа, чтобы попытаться сбить (успешно) 1,2 ГБ памяти кучи. От 1,4 ГБ до 200 МБ.

За это время загрузка процессора была высокой, почти 80-100%. Что может быть причиной? У нас есть 4 таких сервера с одинаковой конфигурацией (настройки JVM, конфигурация сервера, аппаратное обеспечение, сеть), предполагая, что никто не внес каких-либо изменений в это, что может быть причиной того, что конкретный сервер выполнил 3 часа GC.

Все остальные серверы занимали от 5 до 10 минут для каждой деятельности GC.

Пожалуйста, приложите график от HP BAC для удобства использования. Показывает время, когда я предполагаю, что GC зашел, и когда GC остановился.

(Как Стивен указывает на более убедительные выводы) Предоставление этих сведений, когда администратор сервера вернется ко мне:

Точная версия JVM, которой вы являетесь с помощью. (стандартный Java SE 1.4.2)
Параметры JVM. (Coming)
Подробная информация о база веб-контейнера/сервера. (Coming)
Информация о том, что служба делает. Любые соответствующие подсказки из файлы журнала сервера/службы (Coming)
Любые соответствующие шаблоны в журналах запросов (Coming)
Журналы GC на время мероприятие. (Если вы в настоящее время не имеете Включение протокола GC, возможно, потребуется включить его и подождать, пока проблема повторяется.) (Coming)

Ответ 1

Вы не предоставляете много информации, но возможны следующие причины:

Ошибки в вашем приложении; например утечка памяти с некоторыми довольно своеобразными характеристиками или задача, которая продолжала заканчиваться из памяти и затем перезагружалась.
Случайное или преднамеренное нападение на отказ в обслуживании; например некоторый клиент, который продолжает повторять запрос сверхразмера с параметрами, которые каждый раз уменьшают "размер проблемы".
Один чрезвычайно длительный запрос с определенными характеристиками.
Thrashing - см. ответ @Trent Gray-Donald. (Если у вас есть общая память, тогда алгоритмы GC, которые связаны с просмотром множества объектов, разбросанных случайным образом по множеству страниц, могут вызвать раздражение. Я просто не уверен, что это приведет к постепенному падению использования кучи, как вы смотрят.)
Патологическая комбинация настроек JVM.
Ошибка в сборщике мусора в конкретной JVM, которую вы используете.
Некоторая комбинация из вышеперечисленного.

Это та проблема, которая гарантировала бы получение контракта на поддержку Oracle/Java.

Следующая информация может помочь диагностировать это:

Точная версия используемой вами JVM.
Параметры JVM.
Подробная информация о базе веб-контейнера/сервера.
Информация о том, что делает служба.
Любые соответствующие подсказки из файлов журнала сервера/службы
Любые соответствующие шаблоны в журналах запросов
Журналы GC на время события. (Если в настоящее время нет регистрации протокола GC, вам может потребоваться включить его и дождаться, пока проблема не повторится.)

Ответ 2

Здесь не так много данных, но моя догадка: вы меняете. Единственный раз, когда мы когда-либо видели GC-времена, - это то, когда вы перегружаете ящик, и он подкачки на диск. Это может превратить вещи в порядок (или более) деградации производительности.

Вам нужно собрать ОС (и, возможно, гипервизор, если она применяется), свопинг статистики, чтобы доказать или опровергнуть эту теорию.

(Я знаю, что время процессора выше, чем я ожидал бы для обмена, но вы никогда не знаете.)

Было бы полезно, если бы вы разместили конфигурацию оборудования, информацию о java -version и аргументы командной строки JVM (например: -Xmx и -Xms), чтобы сузить то, что вы действительно выполняете.