GPDB-疑难杂症-使用资源组入库OOM

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: GPDB-疑难杂症-使用资源组入库OOM

GPDB-疑难杂症-使用资源组入库OOM
1、问题
GPDB6资源组可以使业务在事务级别控制资源的使用,业务侧启用资源组后,入库时查看数据库日志发现大量OOM报错:
ERROR...Out of memory...Resource group memory limit reached...INSERT INTO ... SELECT...
业务连接用户具备superuser权限,使用admin_group资源组。对memory_limit等资源组属性配置进行调整,仍持续报错。
gp_resgroup_memory_policy为eager_free,gp_ressource_group_memory_limit为0.7,statement_mem为200MB,gp_resource_group_bypass为off。
将memory_limit调整后,查看gp_toolkit.gp_resgroup_status_per_segment视图,发现全局可用内存memory_available还剩余很多,高达46GB,slot配额剩余36GB,资源组共享区没有使用。
2、分析
视图中可以看到资源组可用内存还剩余很多,为什么还会报错OOM呢?前文我们分析过,bypass模式下,QE上限制仅10MB,若INSERT数据量特别大并且复杂时,倒是有可能超过10MB。但是,通过对资源组机制进行分析,仅SET、RESET、SHOW语句才会bypass模式,通过日志可以看到时INSERT语句OOM。所以又是什么原因呢?
我们找到OOM报错日志的位置:
gp_failed_to_alloc函数中:
image.png

也就是错误码是MemoryFailure_SystemMemoryExhausted。根据该错误码向上回溯:该错误码由gp_malloc_internal函数调用VmemTracker_ReserveVmem时的返回值。进一步看代码,可知是VmemTracker_ReserveVmemChunks的返回值。VmemTracker_ReserveVmemChunks函数中返回该错误码的分支为:
image.png

也就是ResGroupReserveMemory函数返回false时才会报该错误。
前文已分析,返回false的场景也就两种,一种是bypass模式下的10MB限制,另一种是资源组定义的内存。
我们分别在这两个分支处添加打印日志,看下到底是哪个场景导致OOM的。
经测试复现,确实是INSERT语句,走bypass模式分支报的错。
Bypass模式只能是SET、RESET、SHOW语句才会用,前文我们也分析了,同一个事务内的SQL语句都使用同一个资源组,业务会不会将INSERT语句和SET/RESET/SHOW放在一起了?
返回来,查看业务的SQL,发现执行INSERT前确实有个SET statement_mem语句。询问业务侧,是否将这两个语句放到一个事务里了,但人家回应两个在单独事务里。有时候不能太相信业务端,还真得深究他们的代码:他们通过JDBC连接GPDB,默认情况下为自动提交,也就是说这两个是独立的两个事务。
始终怀疑,这两个语句在同一个事务中,好了,继续验证:修改代码,让jdbc连接服务后执行SET语句前sleep 30秒,这段时间足够我们ps看到服务端的进程ID,gdb跟踪该PID,在QD端StartTransaction和CommitTransaction处都打上断点,以及QE端资源组分配函数SwitchResGroupOnSegment上打断点。
业务JDBC执行后,StartTransaction仅执行了一次,QE端先执行SET语句,确实走的bypass模式,然后再执行INSERT,它确实在SET事务内,同样走bypass模式。
到此,十分清楚了,SET和INSERT在同一个事务内,而SET语句在前,它的事务分配资源组bypass模式,后续的INSERT命令继续使用该资源组,同样继续走bypass模式,所以限制仍旧是10MB。
那出问题的就是JDBC了,使用默认自动提交情况下,将SET命令和INSERT语句一起发送时,成为了一个事务。有可能是JDBC的bug。
怎么解决?将SET命令单独放在显式事务中:BEGIN;SET...;COMMIT;然后再执行INSERT,这样将其分开,INSERT独立一个事务,让其走资源组属性的限制。Ok,问题解决!

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
6月前
|
DataWorks 监控 API
dataworks公共资源组不可用时间,如何解决?
dataworks公共资源组不可用时间,如何解决?
41 3
|
6月前
|
SQL 数据管理 网络安全
数据管理DMS操作报错合集之DMS的CPU使用率达到100%,如何解决
数据管理DMS(Data Management Service)是阿里云提供的数据库管理和运维服务,它支持多种数据库类型,包括RDS、PolarDB、MongoDB等。在使用DMS进行数据库操作时,可能会遇到各种报错情况。以下是一些常见的DMS操作报错及其可能的原因与解决措施的合集。
|
6月前
|
DataWorks 机器人 调度
DataWorks的集成任务并发度设置主要影响的是**调度资源组**。
【2月更文挑战第34天】DataWorks的集成任务并发度设置主要影响的是**调度资源组**。
40 1
|
6月前
|
分布式计算 DataWorks 定位技术
DataWorks常见问题之资源组选择失败如何解决
DataWorks是阿里云提供的一站式大数据开发与管理平台,支持数据集成、数据开发、数据治理等功能;在本汇总中,我们梳理了DataWorks产品在使用过程中经常遇到的问题及解答,以助用户在数据处理和分析工作中提高效率,降低难度。
|
2月前
|
存储 Kubernetes Perl
资源配额ResourceQuota实战案例
关于Kubernetes资源配额(ResourceQuota)的实战案例分析,涵盖了资源配额的概述、工作方式、计算资源配额、存储资源配额、对象数量配额的详细介绍和案例演示。
43 2
|
3月前
|
数据采集 缓存 DataWorks
DataWorks产品使用合集之如何查看剩余资源
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
5月前
|
SQL 分布式计算 大数据
MaxCompute产品使用问题之等待上游执行的任务是否会占用资源组的资源
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
5月前
|
存储 DataWorks NoSQL
DataWorks产品使用合集之如果作业选了独享调度资源,后期任务阻塞,会自动分配到公共调度资源运行吗
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
41 8
|
5月前
|
SQL 数据采集 DataWorks
DataWorks产品使用合集之如何判断自己需要多大的独享资源组
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
21 1
|
5月前
|
存储 分布式计算 DataWorks
DataWorks产品使用合集之集成任务占用调度资源而不是集成资源组,一般是什么导致的
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
28 0