Сборка мусора Java7 против java5

Мы планируем перенести наше корпоративное приложение, работающее в настоящее время на стеке Java5, на стек Java7. У нас возникают проблемы с неявными вызовами сборщика мусора (в основном с основным сборщиком мусора), что приводит к нестабильной работе системы в течение короткого времени (от 5 минут до 30 минут). Проанализировав статистику сборщика мусора, мы обнаружили, что фаза Compact занимает довольно много времени по сравнению с фазой Mark и Sweeping. Я понимаю, что уплотнение довольно сложно и занимает много времени, но оно влияет на сервер приложений, с которым сталкивается клиент, и на этом этапе несколько соединений прерываются.

Теперь мой вопрос: когда мы переходим на Java7, есть ли лучший процесс сборки мусора по сравнению с Java5?

Серверы приложений обеспечены приличными системными ресурсами.

  1. Каждый сервер приложений содержит 32 процессорных ядра.
  2. содержит 64 гб оперативной памяти
  3. Сервер приложений — сервер IBM webpshere.
  4. Операционная система — 64-разрядная IBM AIX.

Как было сказано ранее, gc происходит из-за неявных системных вызовов. Никаких явных системных вызовов, вызывающих gc.


person harshavmb    schedule 20.12.2015    source источник
comment
Можете ли вы предоставить журналы и настройки GC для вашей конфигурации java5?   -  person the8472    schedule 20.12.2015


Ответы (3)


Теперь мой вопрос: когда мы переходим на Java7, есть ли лучший процесс сборки мусора по сравнению с Java5?

В целом да, хотя, как @Pushkar, вам действительно следует перейти на Java 8.

Что касается специфики вашего приложения (приложений), похоже, вам нужно настроить/перенастроить сборку мусора на Java 5. Если вы периодически испытываете от 5 до 30 >>минут‹‹ нестабильности из-за GC, есть что-то скорее неправильно. Текущее поведение может быть связано с вашим приложением или Websphere (например, утечка памяти, чрезмерное кэширование и т. д.) или может быть связано с плохой настройкой сборщика мусора.

Короче говоря, переход на Java 7 (или 8) может улучшить ситуацию «из коробки», но вполне вероятно, что вам придется приложить больше усилий для устранения основной причины ваших проблем.

Наконец, я бы посоветовал очевидные вещи.

  • Внедряйте изменения небольшими шагами. Не обновляйте свое приложение, версию веб-сферы, версию Java и т. Д. Все время.

  • Выполняйте обновления серверов по одному. Имейте план отката на случай, если вы получите неприемлемую производительность.

  • Если возможно, сначала протестируйте все это ... включая тестирование производительности / нагрузки.

person Stephen C    schedule 28.12.2015
comment
Спасибо, Стивен. Ваши предложения действительно сработали. Мы не можем перейти на java8, так как обновляемая среда не поддерживает java8. Итак, нам придется придерживаться java7. Мы слишком много кэшировали в нашем приложении. Это может быть одной из веских причин частого вызова сборщика мусора. В качестве обходного пути мы отключили кэширование результатов поиска, и результаты оказались положительными. Серверы приложений, которые принимают запросы от ботов, по-прежнему имеют проблемы, и проблема возникает нечасто. Большое спасибо за ваш ответ. - person harshavmb; 31.12.2015
comment
Я рад, что мои предложения (на самом деле догадки) были вам полезны, но вам действительно нужно сделать миграцию вашего фреймворка на Java 8 первоочередной задачей. - person Stephen C; 01.01.2016

По умолчанию java 7 использует parallelGC на машинах серверного класса. Если вы используете JDK 7, обновление 4 или более позднюю версию, переключитесь на сборщик мусора G1, который может повысить производительность. Но, как предложил @the8472, было бы неплохо узнать, какие настройки вы использовали в java 5 и теперь в вашей текущей среде.

person Balaji Sukumaran    schedule 20.12.2015

Срок службы Java 7 истек примерно в апреле 2015 года. Почему бы не перейти на версию 1.8?

Производительность GC обычно улучшается с основными выпусками Java (и в некоторых случаях с второстепенными GC).

Вы должны взглянуть на разницу флагов настройки GC, следующая ссылка может помочь вам http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.html

http://stas-blogspot.blogspot.com/2011/07/самый-полный-список-из-xx-options-for.html

person Pushkar    schedule 28.12.2015
comment
Спасибо Пушкарь за ответ. Мы не можем перейти на java8, так как обновляемая среда не поддерживает java8. Итак, нам придется придерживаться java7. Мы отключили кеширование результатов поиска, и это действительно помогло серверам приложений пережить частый сбор мусора. Спасибо и Спасибо за ваш ответ. - person harshavmb; 31.12.2015
comment
С 2020 года рекомендуется перейти на Java 11. Если вы все еще застряли на Java 7, вам следует избавиться от зависимости от старого фреймворка (или чего-то еще), который вас сдерживает. - person Stephen C; 25.05.2020