Java Garbage Collection- CPU Spikes - Более длительное время установления соединения

Question

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

На клиентских машинах наблюдается всплеск среднего времени подключения к серверу почти на 10% в течение дня.

Теория: CPU занят выполнением GC, и поэтому не может выделить соединение быстрее.

Это действительная теория?

JVM: IBM GC алгоритм: gencon Детская комната: 5 ГБ Размер кучи: 18 ГБ

Answer 1

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

У вас есть доступ к этому коду? Можно ли переписать его для повторного использования объектов и быть более разумным в распределении? Я сделал несколько встроенных систем, и хитрость заключается в том, чтобы НИКОГДА не вызывать новое, когда система запущена и работает (вполне выполнимо, если у вас есть контроль над всей системой)

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

Answer 2

Возможно, я думаю.

Учитывая, что сборка мусора является настолько интенсивным процессом, есть ли причина, по которой он происходит каждые 6 секунд? Я не знаком с IBM JVM или конкретным алгоритмом сбора, который вы используете, поэтому я не могу комментировать их. Тем не менее, существует несколько хороших документов по настройке, предоставленных Sun (теперь предлагаемых Oracle), в которых обсуждаются различные типы коллекторов и время их использования. См. эту ссылку для некоторых идей.

Одним из способов доказать свою теорию может быть добавление некоторого кода, который регистрирует время, когда было запрошено соединение, и время, когда оно фактически было выделено. Если кажется, что пики ЦП, связанные с ГХ, совпадают с более длительными временами при распределении соединений, то это подтвердит вашу теорию. Тогда вашей проблемой станет то, как ее обойти.