shuangquansq

Hi, ptupitsyn: our ignite run with k8s pod. pod have 8G memory and guest host memory is 64G. Our use defaultDataRegionConfiguration, but haven't set the maxsize memory for defaultDataRegionConfiguration. Native...

hi, ptupitsyn the error log: Caused by: java.io.IOException: java.lang.OutOfMemoryError**: Cannot reserve 131072 bytes of direct buffer memory (allocated: 2411594182, limit: 2411724800)**, is direct memory for off-heap, not he heap memory....

补充当时和益剑的沟通纪要，不太好翻译，直接贴中文了。 ts-store故障场景当前openGemini的实现实际不是按新建shardGroup来实现的，当前实现为： 1、ts-store节点故障后，ts-sql探测3次失败后，把新进来的数据写到了其他节点。 2、没有副本来顶替故障的主节点，副本功能正在开发，创建RetentionPolicy时的副本参数目前不生效。 3、故障恢复后，数据重新写回恢复后的原节点。 4、即故障场景不会新建shardGroup来区别故障前后的路由信息（shard信息），故障期间要查对数据就只能走广播方式。 缺点： 1、如果带时间线加hint查询，只会路由到特定的ts-store节点，导致查询数据不全或查不到。 扩容场景： 1、扩容时，新加进来的ts-store节点，需要等到下一个shardGroup的duration周期才能被纳管进来，形成新的周期内路由。 缺点： 如果shardGroup的周期间隔时间较大，会导致扩容后不能及时生效，需要等待很长时间才能生效。 缩容场景：不支持 讨论结果： 1、故障场景新建shardGroup的方案openGemini团队之前也考虑过，但因DFX相对复杂没有采用，比如如果ts-store不停的重启，会导致路由信息变多，内存存不下。 但个人认为重启场景通过手段是可以规避路由信息问题的。 2、沟通时我提到如果支持按需新建shardGroup，那么扩容场景就能做到及时生效，故障场景也能维护在一个shardGroup周期内路由信息时可靠的，不存在查不到数据的问题。且故障场景和扩容场景的处理方式是通用的。益剑答复是很好的建议，会再考虑。 3、目前openGemini倾向于只实现副本方案，故障场景由副本启动顶替，不再把新数据插入到别的节点。不再变更该周期内shardGroup中各shard的路由信息。此方案可以解决hint查不到数据的问题，但支持不了扩容及时生效。 4、最佳方案是即实现副本，又能触发式的创建shardGroup，以支持扩容及时生效。

our walSegmentSize is : 64MB. defaultDataRegionConfiguration: 1.2G -XX:MaxDirectMemorySize=1.8G system region: 100M checkpoint: 256M I try Adjust MaxDirectMemorySize to 3G，the issue haven't solve.