DWS临时内存不可用报错: memory temporarily unavailable

原创
2023/10/27 11:19
阅读数 47

本文分享自华为云社区《DWS临时内存不可用报错: memory temporarily unavailable》,作者:漫天。

1、定位报错的DN/CN

当出现memory temporarily unavailable报错时,首先根据报错信息确认具体是哪个cn/dn报的,如果报错信息没有类似dnxxxx_xxxx这样的信息,就是cn报的,需要去每个cn的日志里排查是哪个cn。

2、DWS813以前的版本内存报错定位

通过free -g或者top命令查看操作系统内存使用情况,确认是操作系统内存耗尽导致,还是cn/dn的内存使用达到限制,导致内存可不用报错。如果没有现场,需要查看操作系统的内存监控。

如果是cn/dn的内存使用达到限制,可以按照以下步骤定位:

步骤一:分析内存视图 pv_total_memory_detail(实例级别内存视图)

select * from pv_total_memory_detail ;

判断(1)如果dynamic_peak_memory大于max_dynamic_memory,说明是cn/dn dynamic内存使用达到上限,导致内存可不用报错。PS:要求历史上dynamic_peak_memory 没有超过max_dynamic_memory,即dynamic_peak_memory 首次超过max_dynamic_memory时,该判断方式有效。

判断(2)dynamic_used_memory接近max_dynamic_memory,大概率是cn/dn dynamic内存使用达到上限,导致内存可不用报错。

判断(3)比较dynamic_used_memory、dynamic_used_shrctx、sctpcomm_used_memory大小,如果dynamic_used_shrctx非常大,说明多线程共享的动态内存太大,如果sctpcomm_used_memory非常大,说明通信库使用的内存非常大,如果dynamic_used_shrctx和sctpcomm_used_memory都很小,说明session占用的内存最多。

步骤二:分析内存视图 pv_session_memory_detail(会话级别内存视图)和活跃会话视图 pg_stat_activity

执行如下SQL-X,查看每个session占用的内存大小:

 

-- 查看每个session占用的内存大小
select split_part(pv_session_memory_detail.sessid,'.',2) pid,pg_size_pretty(sum(totalsize)) total_size,count(*) context_count from pv_session_memory_detail group by pid order by sum(totalsize) desc;

如果SQL-X查询结果中,某个session占用内存特别高,说明该session上执行的SQL占用内存过高,可以找到对应的SQL,杀掉该语句并进行整改:

 

-- 查看语句占用内存大小
select b.state, a.sessid, b.query_id, substr(b.query,1,80) as query, sum(totalsize) as totalsize, sum(freesize), sum(usedsize) from pv_session_memory_detail a, pg_stat_activity b where split_part(a.sessid,'.',2) = b.pid group by state,sessid,query_id,query order by totalsize desc limit 100;
​
-- 到对应的CN节点查杀对应的线程
select pg_terminate_backend(pid);

如果SQL-X查询结果中,每个session占用内存都不大,但session总量大,大概是空闲线程太多导致dynamic内存较高。

 

-- 查看idle线程数量
SELECT count(*) FROM pg_stat_activity WHERE state='idle';
​
-- 查看各个线程状态的内存使用
select b.state, sum(totalsize) as totalsize, sum(freesize) as freesize, sum(usedsize) as usedsize from pv_session_memory_detail a, pg_stat_activity b where split_part(a.sessid,'.',2) = b.pid group by b.state order by totalsize desc limit 100;
​
-- 查询各个应用的内存使用
select b.application_name, sum(totalsize) as totalsize, sum(freesize) as freesize, sum(usedsize) as usedsize from pv_session_memory_detail a, pg_stat_activity b where split_part(a.sessid,'.',2) = b.pid group by b.application_name order by totalsize desc limit 100;
​
-- 查询各个用户的内存使用
select b.usename, sum(totalsize) as totalsize from pv_session_memory_detail a, pg_stat_activity b where split_part(a.sessid,'.',2) = b.pid group by b.usename order by totalsize desc limit 30;
​
-- 查看各类型等待线程的数量
select wait_status,wait_event,count(*) from pg_thread_wait_status group by 1,2 order by 3 desc;

如果是空闲用户线程导致dynamic内存高,可以临时清理下空闲用户线程:

gsql -d postgres -p 25308 -c "clean connection to all for database xxx;"

如果是空闲stream线程导致dynamic内存高,可以将参数max_stream_pool改小(stream线程池的作用是缓存stream线程,stream线程是用来进行dn之间数据的传输,一般多表join的时候stream线程会较多),减小max_stream_pool的影响是短查询的性能会降低,对复杂查询几乎没影响。

3、DWS813及以后的版本内存报错定位

可以使用813以前版本的定位方式,也可以使用下面的方式。

步骤一:查看报错日志

813及以上版本会打印出debug的信息,可以通过搜关键字abnormal来找到当时使用最高的语句,找到thread id,再查找thread id 找到对应query id

步骤二:查看topsql

上一步可以找到占用内存最大的sql,如果该sql占用内存确实很大,通过topsql查找对应的query id,从而找到对应的SQL语句,并通过unique_sql_id找到同一类型的SQL,进行分析整改。

如果不是某个sql占用内存太高导致,分析方法和813以前的版本一样。

另外,813及以后的版本可以使用如下方式清理空闲用户线程:

-- 清理空闲用户线程,每次清1/4
-- 显示清理了多少,还剩多少
select * from pgxc_clean_free_conn;

点击关注,第一时间了解华为云新鲜技术~

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部