DWS 内存问题定位三板斧

1 内存相关知识

数据库节点中使用内存包括：

存储引擎使用的缓存（参数shared_buffers（行存）和cstore_buffers（列存））

通信库使用的缓冲区（参数comm_usable_memory）

内存上下文管理的内存（max_process_memory – shared memory(>shared_buffers) – cstore_buffers – comm_usable_memory）

其他（动态库申请的内存，一般很少，如果模块使用较多，请自行控制）

2 内存问题可能原因

问题原因大类

问题原因小类

集群参数配置

OS配置

业务层面

业务并发度增加

业务SQL计划变化（含有hash、sort、agg等）

是否新增业务

CN报错

SQL是否下推

参数优化

集群内存相关参数

并发控制参数

业务优化

增加内存

集群扩容

内存泄漏

软件BUG

3 内存问题定位方法

如果为CN报内存不可用错误，很大程度上是因为某个SQL的不下推导致。直接可从报错CN的pg_log中查找到报错信息下面的STATEMENTS就能找到SQL。在CN上执行explain verbose可以确认SQL是否存在不下推；

查看集群配置情况和关键参数

a. 集群每个物理节点内存、每个节点dn个数；

b. 在一个CN和DN上“show max_process_memory”，“show work_mem”，“show enable_dynamic_workload”；

业务SQL如果存在多表jion&sort&多个group by语句，这几个算子都是高内存操作，并且单算子内存使用上限为work_mem值，因此如果这几个算子的内存都达到使用上限，可能会报内存不足的问题。

4. 登录任一DataNode节点，观察分析此节点的内存消耗信息(视图pv_total_memory_detail) ，主要为dynamic_used_memory/ max_dynamic_memory信息，发现dynamic_used_memory持续增长，在接近max_dynamic_memory的时候就会报错；详细查看内存上下文

5. 根据日志报错时间点确认是否为单个SQL执行使用内存大导致（此情况下，该SQL一般都是比较复杂的SQL）。

先查找CN pg_log中对应报错时间点第一次报该错误对应的statement（即执行的sql语句）；如果确认该SQL比较复杂，可以通过在gsql中打印explain verbose 的方式查看该SQL的查询计划，确认是否存在使用work_mem比较大的算子；

6. 确认是否存在作业大量并发的场景，如存在该场景，可以通过调整max_active_statements限制全局并发

7. 业务执行过程中动态查看并发SQL和内存使用情况,

（1）监控某一sql运行过程中DN的内存使用情况

select sessid, contextname, level,parent,totalsize,freesize,usedsize,  datname,query_id  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid and b.state='active' order by usedsize desc limit 20 ;

（2）监控session total memory size占用最多的TOP20 session 。

select sessid, sum_total, sum_free,sum_used, query_id, query_start, state, waiting, enqueue,query from (select sessid, sum(totalsize) as sum_total, sum(freesize) as sum_free, sum(usedsize) as sum_used from pv_session_memory_detail group by sessid  order by sum_total desc limit 20 ) a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid;

（3）监控session中占用内存最多的context TOP20 session.

select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize),  datname,query_id, query  from pv_session_memory_detail a , pg_stat_activity b  where  split_part(a.sessid,'.',2) = b.pid  order by totalsize desc limit 20 ;

（4）监控当前实例总totalsize memroy大小

select pg_size_pretty(sum(totalsize)) from pv_session_memory_detail;

（5）监控当前实例总usedsize memroy大小

select pg_size_pretty(sum(usedsize)) from pv_session_memory_detail;

（6）监控当前实例内存总体使用情况

select * from pg_total_memory_detail;

（7）监控共享内存实时使用情况

select * from pg_shared_memory_detail;

4 建议措施

1. 如果确认为配置不合理导致，可以通过调高单节点逻辑内存(max_process_memory )上限；

2. 如果确认业务SQL中使用work_mem的算子较多，可以通过降低work_mem上限(需要注意观察对其它业务SQL性能的影响，如果某SQL因此导致性能下降，需要分析后此query执行时的work_mem设置)

3. 如果是由于业务并发量大，而每个业务使用的内存实际并不大导致，可以通过调整max_active_statements（全局SQL并发数，该参数仅对普通用户有限制，对管理员用户执行的SQL不限制）

4. 通过打开active sql开关来分析某一时间段并发量和单个sql执行使用的内存信息（如果enable_resource_track和enable_resource_record为off表示该功能关闭）

SQL 数据仓库服务 GaussDB(DWS)

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。