本文分享自华为云社区《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;