Как понять причину частой сборки мусора?

Question

jstat -gc 27539
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
901632.0 468480.0  0.0    0.0   911360.0 911360.0 5464064.0  5463748.3  21632.0 20948.0 2944.0 2777.7    153   33.727  401   782.598  816.325

jstat -gccapacity 27539
 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC       MCMN     MCMX      MC     CCSMN    CCSMX     CCSC    YGC    FGC 
171008.0 2732032.0 2714624.0 901632.0 468480.0 911360.0   343040.0  5464064.0  5464064.0  5464064.0      0.0 1069056.0  21632.0      0.0 1048576.0   2944.0    153   404

Я добавил EU и OU, чтобы найти общую используемую кучу. Похоже, используется 6 ГБ. Я сослался на это

Но там 400+ FG C произошло. Сейчас он достиг 700+. Через некоторое время он просто выполняет G C. Сейчас это 850+.

Моя работа:

Это многопоточность. 100 читателей, 100 писателей. У каждого есть собственное подключение к базе данных. Каждый поток чтения читает 100000 записей и сохраняет в LinkedList и отправляет потоку записи. Writer записывает данные в другую коллекцию той же базы данных. LinkedList не используется повторно, что означает, что каждый 1L создает новый LinkedList.

Это многопоточность на основе akka. Поэтому я не обрабатываю сбой потока, порождение потока, то есть управление потоками.

Но я сомневаюсь, почему такой огромный FG C происходит, когда у меня 32 ГБ ОЗУ? какие-либо указатели для дальнейшего поиска?

Он столкнулся с G C Overhead LIM Иногда превышалась ошибка.

Я не устанавливал явных минимальных и максимальных объемов памяти для работы.

РЕДАКТИРОВАТЬ:

Согласно моему анализу, исправлены некоторые EU и OU. Он заполнен, поэтому он продолжает выполнять G C. Возможно ли это, и я прав?

Edit2

Спасибо @emotionlessbanans, @Cascader. У меня есть следующее.

    uintx ErgoHeapSizeLimit                         = 0                                   {product}
    uintx HeapSizePerGCThread                       = 87241520                            {product}
    uintx InitialHeapSize                          := 526385152                           {product}
    uintx LargePageHeapSizeThreshold                = 134217728                           {product}
    uintx MaxHeapSize                              := 8392802304                          {product}
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)

Какие-либо конкретные c причины останавливаться только на 6 ГБ, когда у меня 8 ГБ? Или мне чего-то не хватает?

Answer 1

Когда максимальный размер кучи не указан с помощью переключателя -Xmx, JVM выбирает значение по умолчанию. Это значение указано поставщиком JVM c и обычно зависит от архитектуры (32/64 бит) и общей доступной памяти.

Кажется, что ваше приложение использует всю выделенную память (определенную вашей JVM) и от в какой-то момент он тратит слишком много времени на G C, пока вы не получите ошибку «G C Overhead Limit Exceeded».

Вы должны явно установить максимальный размер кучи (например, -Xmx 10g), чтобы убедитесь, что вы используете всю доступную память.

Answer 2

Минимальный объем памяти по умолчанию не указан, а максимальный - 256 МБ. Проблема может быть в том, что для кучи выделено недостаточно памяти. (Это мое подозрение)

Также вы можете использовать VisualVM или любой другой инструмент, который может показать дополнительную информацию о том, что там происходит.