内存不可用报错：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;

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

场景二：

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

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

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

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