Создание Pivotal Gemfire Index занимает слишком много времени - PullRequest
Новая
       72

Создание Pivotal Gemfire Index занимает слишком много времени

2 голосов
/ 08 апреля 2019

Мы используем 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

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

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

Ответы [ 2 ]

4 голосов
/ 08 апреля 2019

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

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

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

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

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

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

  4. Если у вас еще не включена статистика для GemFire, включите ее.

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

3 голосов
/ 08 апреля 2019

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

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

Однако вы можете значительно ускорить создание индекса с помощью этой конфигурации, если в своих индексах будет установлен флаг 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 для получения дополнительной информации об определении индексов.

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

...