gpt4 book ai didi

java - Pivot gemfire 索引创建花费了太多时间

转载 作者:行者123 更新时间:2023-12-02 14:14:12 25 4
gpt4 key购买 nike

我们使用 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: Member isn't responding to heartbeat requests gemfire pivotal

我们尝试将 member-timeout 属性从 5000 增加到 300000,但同样的问题仍然存在。

添加上述与 GC 相关的 java 参数后,每个索引大约需要 24 分钟才能应用,但这次没有错误。这导致服务器需要花费太多时间才能与大约 15 个其他区域一起启动。其他地区不存在这样的问题。(该地区的数据量最大。其他地区的条目数约为500K到3M)

最佳答案

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

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

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

  • 我不喜欢 Scavenge 标志,因为如果不进行精细调整,它们会导致更多的颠簸。现在,您可以保留它们,但我会删除 ScavengeBeforeFullGC 和 ScavengeBeforeRemark。保留DisableExplicitGcflags。更重要的是,虽然我读到您的行为会根据使用这些标志而发生变化,但找到索引创建时间和这些标志之间的相关性是一件很困难的事情。更有可能的是,由于堆配置错误,成员变得无响应,所以让我们解决这个问题。

  • 关于您的逐出配置,我看到您说您在这个“问题”区域中有超过 700 万个条目,但您有一个逐出算法,除了前 1000 个之外,所有条目都溢出到磁盘?为什么?溢出到磁盘是用来处理突发 Activity 的,而不是作为“给定”的。也许您遇到的磁盘问题导致了您问题的某些方面。也许需要访问磁盘上的所有这些条目是一个问题。当所有条目实际上都在堆中时,您是否遇到过此问题?

  • 启用 GC 日志,并将所有标志设置为打印 GC 详细信息、日期戳等。

  • 如果您尚未为 GemFire 启用统计信息,请也启用这些统计信息。

  • 如果您发现成员超时不足,则您的环境中可能存在问题。这些问题应该得到解决,而不是考虑增加成员超时来掩盖这些问题。

  • 关于java - Pivot gemfire 索引创建花费了太多时间,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/55567753/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com