内存不可用报错：memory temporarily unavailable 的排查方法-英雄云拓展知识分享

1.当出现memory temporarily unavailable报错时，首先针对报错信息确认具体是哪一个cn/dn报的，如果报错信息前面没有类型dnxxxx_xxxx这样的信息，就是cn报的，需要去每一个cn的日志里排查是哪一个cn

2.经过free -g或top查看当前内存的使用情况，确认是操作系统内存耗尽，还是由于cn/dn的内存使用到达限制，如果已没有现场，可以经过查看/var/log/osinfo中的meminfo来确认当时操作系统的可用内存；

meminfo日志：

下面我们分两类场景讨论

场景一：

操作系统没有可用内存

对操作系统内存耗尽的场景，常常会触发操作系统的oom保护机制，这个在/var/log/message中可以搜索关键字‘kill’可以找到相干信息；

操作系统在oom杀掉进程时，会打印各个进程的内存使用情况，需要注意的是，rss列的单位其实不是b，而是page，在x86服务器上需要乘以4k来计算得到进程实际使用内存大小，在arm服务器上要乘以16k

经过比较进程被杀时的内存和max_process_memory，如果被杀时仍未到达max_process_memory，则需斟酌max_process_memory是不是设置过大，可调剂参数解决

如果进程被杀时内存已超过了max_process_memory，可以使用下面两个语句进一步分析

经常使用的监控语句

1）查看各类内存使用情况

select * from PV_total_memory_detail;

2）查看占用dynamic内存最高的语句

select * from (
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 ) a
,pg_stat_activity b
where
split_part ( a.sessid,'.' , 2 ) = b.pid )
order by
sum_total desc
limit 10;

注：上述第2条监控语句只是排查dynamic内存高的场景，如果第一条语句查出来的结果不是dynamic_used_memory或dynamic_peak_memory高，而是其他内存（other_used_memory、sctpcomm_used_memory等），则需另做排查，以后再开帖子详细介绍

场景2：

操作系统仍有可用内存，cn/dn实例的dynamic内存使用到达上限

对有现场的情况，可使用上面的第2条sql语句找到占用内存最高的语句，杀掉该语句并进行整改

对没有现场的情况，可以部署监控脚本等待下次复现

另外，如果实例是cn，常常是由于有大量的不下推语句，可以在日志中搜索can't be shipped查看不下推的语句，并进行整改