首页 > 编程学习 > GPDB OOM问题

GPDB OOM问题

发布时间:2023/1/25 12:26:46

前文,我们分析了gp_vmem_protect_limit参数的意义,仅统计gp_malloc中申请的,它并没有统计共享内存的部分,所以仍旧有操作系统OOM的风险,详情:GPDB中gp_vmem_protect_limit参数的意义。

但经测试验证,仍不足以对上GP占用的内存总额。这样,也就是说仍有其他内存没有被gp_vmem_protect_limit统计进去。

猜想,仍有malloc函数申请的内存没有统计进去,继续在该函数上打断点,进行跟踪。经排查,发现大部分额外的malloc都是压缩、解压缩函数中调用的,也就是zstd库函数。

最开始猜想,是因为GP列存压缩表的压缩导致,但是业务的SQL不涉及修改,都是查询。那这个压缩来自哪里?查看堆栈发现是排序、HASH AGG和HASH JOIN中的。我们将HASH AGG和HASH JOIN关闭掉,发现有效果,但是最后因为磁盘空间不够保存退出了,排序的临时文件有点大。那么继续更进一步,查看堆栈,分析压缩使用场景。发现,排序、hash agg、hash join的临时文件需要压缩:调用的函数为BufFilePledgeSequential,我们查看该函数:

09c1b58daada4d2d556cdc8e1576fa22.png

有个参数gp_workfile_compression控制是否压缩:如果有很多溢出文件,则设置gp_workfile_compression来压缩这些溢出文件。压缩溢出文件可能有助于避免IO操作导致磁盘子系统过载:Specifies whether the temporary files created, when a hash aggregation or hash join operation spills to disk, are compressed。

那么我们将这个参数关闭,将临时文件全部软连接到一个大盘中,这样使用同样的执行计划,仅临时文件是否压缩不同。这样,将SQL成功跑完,但是中间跟踪过程,临时文件非常大。所以业务中压缩是必须的。

hash agg和hash join中的临时文件压缩导致内存过大,且内存的申请在zstd库函数中,并不是GP代码中,所以并没有被gp_vmem_protect_limit跟踪到。

另查到姚总早期分享的内容:https://www.infoq.cn/article/iAdFEBtb1Y0MOJlvrScU?utm_source=related_read_bottom:

执行器优化:目前 Greenplum 使用 zstd 压缩 AO 数据和临时数据,zstd造成的一个问题是内存消耗较大,如何优化操作大量压缩文件时的内存消耗是一个很有挑战的课题。有关更多细节可以参考这个讨论(最后部分有简单的问题重现方法)。链接地址:https://github.com/greenplum-db/gpdb/pull/6508

临时解决方案可以通过限制gp_workfile_limit_files_per_query、gp_workfile_limit_per_query、gp_workfile_limit_per_segment等参数来控制一个查询中临时文件个数,从而规避zstd压缩占用的内存。另外,若zstd压缩接口的参数中有可以统计其申请内存的成员变量,那么可以通过修改代码,将这部分内存也统计到gp_vmem_protect_limit参数中,不过估计改动影响会比较大,zstd是第三方库,首先需要了解它的内存申请及管理机制,其次若压缩、解压缩接口中没有相关统计参数,那么就需要尝试修改zstd库,这造成的影响就更大了。

zstd压缩造成的内存消耗问题确实是一个有挑战的课题,感兴趣的同学们可以深入探讨!


本文链接:https://www.ngui.cc/article/show-841454.html
Copyright © 2010-2022 ngui.cc 版权所有 |关于我们| 联系方式| 豫B2-20100000