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;