我们正在使用Pivotal Gemfire作为数据的缓存。最近,我们从gemfire 8.2.1迁移到了具有完全相同的区域,数据和索引的9.5.1。但是,特别是在一个区域上创建索引要花费太多时间,其条目计数为7284500。我们已经使用Spring数据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-timeout
属性从5000增加到300000,但是仍然存在相同的问题。添加了上述与GC相关的Java参数后,每个索引大约需要24分钟才能得到应用,但这一次没有错误。这导致服务器花费太多时间与大约15个其他区域一起使用。其他区域没有这样的问题。(该区域的数据量最大。其他区域的条目数约为500K至3M)
最佳答案
我从您的配置中看到一些需要调整的内容。对于其中一些,我将需要推测,因为我不知道您的总的持久堆消耗。
Xmx必须等于Xms将两者都设置为80g,因为增大堆可能会导致重大问题
显式设置您的NewSize = MaxNewSize。如果我可以看到GC日志,则可以提供帮助,但是我将以该配置为起点。
将NewSize和MaxNewSize设置为9gb
将SurvivorRatio设置为1
将TargetSurvivorRatio设置为85
添加PrintTenuringDistribution标志以帮助我们进行微调。
我不是Scavenge标志的粉丝,因为如果不进行微调,它们会引起更大的抖动。现在,您可以保留它们,但是我将删除ScavengeBeforeFullGC和ScavengeBeforeRemark。保留DisableExplicitGC标志。更重要的是,虽然我读到您的行为会因使用这些标志而改变,但在索引创建时间和这些标志之间找到相关性是一个负担。更有可能的是,由于堆配置错误,成员变得无响应,所以让我们解决这个问题。
关于您的逐出配置,我看到您说您在此“问题”区域中有7+百万个条目,但是您有一种逐出算法,除了前1000个外,其余全部溢出到磁盘上。为什么?磁盘溢出是用来处理突发事件的方法,而不是“给定的”方法。可能是磁盘问题导致了问题的某些方面。可能需要访问磁盘上的所有这些条目是一个问题。当所有条目实际上都在堆中时,您是否遇到过此问题?
启用所有设置为可打印gc详细信息,日期戳等标志的GC日志。
如果您尚未为GemFire启用统计信息,请同时启用这些统计信息。
如果您发现成员超时不足,则可能是您的环境存在问题。应该解决这些问题,而不是考虑增加成员超时来掩盖这些问题。