Сколько времени должно быть потрачено на сборку мусора

У меня есть приложение, отвечающее за архивирование старых приложений, которое будет выполнять большое количество приложений одновременно, поэтому его нужно будет запускать в течение нескольких дней.

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

Похоже, что утечки памяти нет, поскольку, поскольку я отслеживаю ее с помощью jconsole, доступной памяти по-прежнему много, и, похоже, она не уменьшается.

Однако я заметил, что оставшееся пространство и постоянный генератор кучи могут очень быстро заполниться, пока не появится сборщик мусора и не очистит его, что, кажется, происходит довольно часто, и я не уверен, что это может быть источником видимого замедления.

Приложение работает уже 7 дней 3 часа и, по данным jconsole, оно потратило 6 часов на сборку копий мусора (772, 611 коллекций) и 12 часов 25 минут на уплотнение по разметке (145 940 коллекций).

Похоже, на сборку мусора уходит много времени, и мне просто интересно, кто-нибудь уже изучал что-то подобное раньше и знает, нормально это или нет?

Правки

Локальная обработка кажется медленной, например, я просматриваю одну часть в журналах, которая заняла 5 секунд, чтобы извлечь некоторый xml из конверта SOAP, используя xpath, который затем добавляется в строковый буфер вместе с корневой тег.. это все, что он делает.Я еще не профилировал его, так как он работает в производстве, мне придется либо вытащить данные по сети, либо настроить большую тестовую базу в нашей среде разработки, что может в конечном итоге сделать.

Запуск Java HotSpot Client VM версии 10.0-b23

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

Исправление

В конечном итоге, для этого был запущен профилировщик. Оказалось, что причиной замедления был какой-то код, который постоянно обрезал строки из окна состояния, выводя операторы журнала, что было довольно плохо сделано. Должен был понять, что сборка мусора была симптомом постоянного копирования текста состояния в память, а не фактической причиной.

Ура, ребята.