Что может быть причиной трех часов, затраченных GC на удаление 1,2 ГБ кучи? - PullRequest
Новая
       15

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

19 голосов
/ 09 мая 2011

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

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

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

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

enter image description here

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

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

Ответы [ 2 ]

11 голосов
/ 09 мая 2011

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

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

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

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

10 голосов
/ 09 мая 2011

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

  • Ошибки в вашем приложении; например утечка памяти с некоторыми довольно специфическими характеристиками или задача, которая продолжала исчерпывать память и затем перезапускаться.

  • Случайное или преднамеренное нападение на отказ в обслуживании; например некоторый клиент, который продолжает повторять слишком большой запрос с параметрами, каждый раз уменьшающими «размер проблемы».

  • Один чрезвычайно длительный запрос с определенными характеристиками.

  • Thrashing - см. Ответ Трента Грей-Дональда. (Если у вас есть перераспределенная память, то алгоритмы GC, которые включают просмотр большого количества объектов, разбросанных случайным образом по множеству страниц, с большой вероятностью вызовут перегрузку. Я просто не уверен, что это приведет к постепенному падению использования кучи, как вы видим.)

  • Патологическая комбинация настроек JVM.

  • Ошибка в сборщике мусора в конкретной JVM, которую вы используете.

  • Некоторая комбинация вышеперечисленного.

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

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

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