Блог

Мы используем Pivotal Gemfire в качестве кэша для наших данных. Недавно мы перешли с gemfire 8.2.1 на 9.5.1 с точно такими же регионами, данными и индексами. Но создание индексов, в частности, в одном регионе, занимает слишком много времени, а количество записей составляет 7284500. Мы использовали Spring data gemfire версии v2.4.1.RELEASE для определения сервера кэша. Ниже приведена конфигурация проблемной области:

 <gfe:replicated-region id="someRegion"
            shortcut="REPLICATE_PERSISTENT" concurrency-level=100
            persistent="true" disk-synchronous="true" statistics="true">
            <gfe:eviction action="OVERFLOW_TO_DISK" type="ENTRY_COUNT"
                    threshold=1000></gfe:eviction>
</gfe:replicated-region>
  

Ниже приведены определения индексов:

 <gfe:index id="someRegion_idx1" expression="o1.var1" from="/someRegion o1" />
<gfe:index id="someRegion_idx2" expression="o2.var2" from="/someRegion o2"/>
<gfe:index id="someRegion_idx3" expression="o3.var3" from="/someRegion o3"/>
<gfe:index id="someRegion_idx4" expression="o4.var4" from="/someRegion o4"/>
<gfe:index id="someRegion_idx5" expression="o5.var5" from="/someRegion o5"/>
<gfe:index id="someRegion_idx6" expression="o6.var6" from="/someRegion o6"/>
<gfe:index id="someRegion_idx7" expression="o7.var7" from="/someRegion o7"/>
<gfe:index id="someRegion_idx8" expression="o8.var8" from="/someRegion o8"/>
  

Ниже приведено определение кэша:

 <gfe:cache
    properties-ref="gemfireProperties"
    close="true"
    critical-heap-percentage=85
    eviction-heap-percentage=75
    pdx-serializer-ref="pdxSerializer"
    pdx-persistent="true"
    pdx-read-serialized="true"
    pdx-ignore-unread-fields="false" />
  

Ниже приведены параметры Java:

 java -Xms50G -Xmx80G -XX: UseConcMarkSweepGC 
-XX: UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=70 
-XX: ScavengeBeforeFullGC -XX: CMSScavengeBeforeRemark 
-XX: UseParNewGC -XX: UseLargePages 
-XX: DisableExplicitGC 
-Ddw.appname=$APPNAME 
-Dgemfire.Query.VERBOSE=true 
-Dgemfire.QueryService.allowUntrustedMethodInvocation=true 
-DDistributionManager.MAX_THREADS=20 
-DDistributionManager.MAX_FE_THREADS=10 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=11809 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false 
-Dconfig=/config/location/ 
com.my.package.cacheServer
  

При запуске без XX: ScavengeBeforeFullGC -XX: CMSScavengeBeforeRemark -XX: DisableExplicitGC мы обычно получали следующую ошибку при применении индексов:

org.apache.geode.Исключение ForcedDisconnectException: участник не отвечает на запросы сердцебиения gemfire pivotal

Мы попытались увеличить member-timeout свойство с 5000 до 300000, но та же проблема сохранялась.

После добавления вышеуказанных параметров Java, связанных с GC, для применения каждого индекса требуется около 24 минут, но на этот раз без ошибок. В результате сервер занимает слишком много времени, чтобы появиться вместе с примерно 15 другими регионами. В других регионах такой проблемы нет.(Рассматриваемый регион имеет наибольшее количество данных. В других регионах количество записей составляет от 500 тыс. до 3 млн.)

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

1. Xmx должен быть равен Xms, установленному как на 80g, так как увеличение кучи может вызвать серьезные проблемы
2. Явно установите NewSize = MaxNewSize . Если бы я мог видеть журналы GC, я мог бы помочь, но я собираюсь предоставить эту конфигурацию в качестве отправной точки.

Установите NewSize и MaxNewSize на 9 ГБ, установите SurvivorRatio на 1, Установите TargetSurvivorRatio на 85, Добавьте флаг PrintTenuringDistribution, чтобы помочь нам выполнить точную настройку.

3. Я не поклонник флагов очистки, поскольку они вызывают еще больше проблем, когда не настроены точно. На данный момент вы можете оставить их, но я бы удалил ScavengeBeforeFullGC и ScavengeBeforeRemark. Сохраните флаг DisableExplicitGC. Что еще более важно, хотя я читал, что ваше поведение меняется в зависимости от использования этих флагов, найти корреляцию между временем создания индекса и этими флагами сложно. Более вероятно, что участники перестают отвечать на запросы из-за плохой конфигурации кучи, поэтому давайте решим это.

4. Что касается вашей конфигурации удаления, я вижу, вы говорите, что у вас более 7 миллионов записей в этой «проблемной» области, и все же у вас есть алгоритм удаления, при котором вы переполняете на диск все, кроме первых 1000?? Почему? Переполнение на диск — это то, что можно использовать для обработки всплесков активности, а не как «заданное». Возможно, у вас возникли проблемы с диском, связанные с некоторыми аспектами вашей проблемы. Возможно, проблема заключается в необходимости доступа ко всем этим записям на диске. Сталкивались ли вы с этой проблемой, когда все записи фактически находятся в куче?

5. Включите журналы GC со всеми установленными флагами для печати сведений о gc, меток даты и т. Д.

6. Если у вас еще не включена статистика для GemFire, пожалуйста, включите и ее.

7. Если вы обнаруживаете, что время ожидания участника недостаточно, вполне вероятно, что у вас проблемы в вашей среде. Их следует решать, а не думать об увеличении времени ожидания участника, чтобы скрыть эти проблемы.

Что касается времени создания индекса — как отметил Дэвид, вы настроили этот регион так, чтобы почти все данные были на диске.

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

Однако вы можете значительно ускорить создание индекса с помощью этой конфигурации, если используете define флаг в своих индексах

 <gfe:index id="someRegion_idx3" expression="o3.var3" from="/someRegion o3" define="true"/>
  

Это приведет к созданию всех ваших индексов за один проход в конце инициализации вашего ApplicationContext. Так что, надеюсь, ваше общее время будет ближе к 24 минутам, потому что GemFire придется сканировать все ваши данные на диске только один раз.

См. https://docs.spring.io/spring-gemfire/docs/current/reference/html/#_defining_indexes для получения дополнительной информации об определении индексов.

На самом деле это не объясняет ваши проблемы со сборкой мусора — я бы посмотрел на ответ Дэвида для получения более подробной информации.