时间戳

首页 > 解决方案 > 创建关键 gemfire 索引需要太多时间

java - 创建关键 gemfire 索引需要太多时间

问题描述

我们使用 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，但同样的问题仍然存在。

添加上述 GC 相关的 java 参数后，每个索引大约需要 24 分钟才能被应用，但这次没有错误。这导致服务器需要太多时间才能与大约 15 个其他区域一起出现。其他地区没有这样的问题。（有问题的地区数据量最大。其他地区大约有500K到3M的条目数）

标签： javagarbage-collectiongemfirespring-data-gemfire

解决方案

我从您的配置中看到了一些需要调整的地方。对于其中的一些，我需要推测，因为我不知道你一般的终身堆消耗。

  1. Xmx 必须等于 Xms 将两者都设置为 80g，因为堆的增长可能会导致重大问题
  2. 明确设置您的 NewSize = MaxNewSize。如果我能看到 GC 日志，我可以提供帮助，但我将以这个配置作为起点。

将 NewSize 和 MaxNewSize 设置为 9gb 将 SurvivorRatio 设置为 1 将 TargetSurvivorRatio 设置为 85 添加 PrintTenuringDistribution 标志以帮助我们进行微调。

  1. 我不喜欢 Scavenge 标志，因为如果不进行微调，它们会导致更多的抖动。现在，您可以保留它们，但我会删除 ScavengeBeforeFullGC 和 ScavengeBeforeRemark。保留 DisableExplicitGC 标志。更重要的是，虽然我读到您的行为会因使用这些标志而发生变化，但要找到索引创建时间与这些标志之间的相关性是一个延伸。更有可能的是，由于堆配置错误，成员变得无响应，所以让我们解决这个问题。

  2. 关于您的驱逐配置，我看到您说您在这个“问题”区域中有 7+ 百万个条目，但是您有一个驱逐算法，除了前 1000 个之外，您都溢出到磁盘？为什么？溢出到磁盘是用来处理突发活动的东西，而不是“给定的”。也许您遇到了驱动问题某些方面的磁盘问题。也许需要访问磁盘上的所有这些条目是一个问题。当所有条目实际上都在堆中时，您是否遇到过这个问题？

  3. 启用 GC 日志并设置所有标志以打印 gc 详细信息、日期戳等。

  4. 如果您还没有为 GemFire 启用统计信息，请也启用它们。

  5. 如果您发现 member-timeout 不足，则可能是您的环境存在问题。应该解决这些问题，而不是考虑增加成员超时来掩盖这些问题。

推荐阅读