问题现象：
1.查看数据库日志，每十分钟就会报一次内存耗尽，报错时间点与跑不出来作业的时间点一致
2. 查看pgxc_total_memory_detail中各个cn和dn历史最高内存，发现只有cn5004的内存会达到瓶颈，cn5004为ccn
定位过程：
在现场部署脚本，监控十分钟，抓到占用内存高的语句
| #!/bin/bash
while true do date >> mem.log gsql -d postgres -p 25308 -ar -c “select * from pv_total_memory_detail” >> mem.log gsql -d postgres -p 25308 -ar -c “select * from PV_SESSION_MEMORY_DETAIL order by totalsize desc limit 100” >> mem.log gsql -d postgres -p 25308 -ar -c “select split_part(pv_session_memory_detail.sessid,’.’,2),sum(totalsize),count(*) from pv_session_memory_detail group by split_part(pv_session_memory_detail.sessid,’.’,2) order by sum(totalsize) desc;” >> mem.log gsql -d postgres -p 25308 -ar -c “select sessid, contextname, level,parent, pg_size_pretty(totalsize),pg_size_pretty(freesize),pg_size_pretty(usedsize), datname,query_id, query from pv_session_memory_detail a , pg_stat_activity b where split_part(a.sessid,’.’,2) = b.pid order by totalsize desc limit 100; ” >> mem.log sleep 5 done |
4. 抓到占用内存最高的语句为：autovacuum：analyze 某库.某表，占用内存37GB
5. 查看这张表的表定义，发现表定义很不合理，很多字段类型都为character(2147483),单个tuple过大，导致analyze时内存溢出
应急措施：
1. 对这张表进行整改，并排查其他定义不合理的表；
2. 关闭autovacuum。现场数据量并不大，打开autovacuum并没有太大意义，还会带来不必要的资源消耗；关闭autovacuum之后，即使再次出现表定义不合理的场景，也不会频繁触发内存满的问题；
已通过修改参数的方式关闭了autovacuum，观察半小时，内存未再飙升；
3. 现场反馈此表的表定义和客户预期不符，建议上层平台进行排查，是否存在bug
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/tech/bigdata/316613.html