开发者社区> 问答> 正文

请教一个关于oom的问题,我按照上次课把mem打出来,发现 2022-07-15 18:19:57

请教一个关于oom的问题,我按照上次课把mem打出来,发现 2022-07-15 18:19:57 HKT,10/0,0,LOG,00000,"level: 1; 41262 more child contexts containing 98531328 total in 82498 blocks; 37707344 free (13786 chunks);

这里占用内存非常多。通过观察机器的内存,发现基本上内存以1G/3S的速度增长,但是当流量停止后,内存会缓慢的下降。使用的SQL都是简单的按照索引查询,没有开事务,表里面有一个json字段。内存分配了为什么不释放呢?

如果内存不够了,按照lru的策略,应该淘汰在加入需要的page吧。会释放是不是说明不是泄露,但是还是oom,是不是说明释放的速度比不上申请的速度,但是为什么申请的时候不先淘汰呢?我还有什么办法能分析这个问题,线上除了限流还有别的手段吗?

展开
收起
云上静思 2022-07-19 10:23:55 249 0
1 条回答
写回答
取消 提交回答
  • 根据你的描述,当流量停止后,内存会缓慢的下降,说明内存应该是释放了的,只是业务高峰时,内存占用太大导致OOM的。内存泄漏一般是调用malloc或plloc后,没有调用free函数释放内存,导致的使用的内存逐渐增加最后导致OOM,这种会更难解决。建议从以下方面看是否能解决内存问题:

    1. 平衡系统的内存占用。通常我们系统中内存可包括共享内存(如bufferpool占用内存)、Cache和动态内存(如MemoryContext占用的内存)、操作系统占用的内存,需要平衡下各部分大小。

      1. Page是放在bufferpool中,这部分内存是启动时设置好的,设大点会让系统变快,但性能要看缓存命中率,这个第一节课有讲过,如果命中率很高了,bufferpool设置太大了,也没有意义,可以适当减少点。
      2. Cache和MemoryContext的占用,如果没有内存泄漏,那执行业务时,增长是正常的,需要预留足够的内存给MemoryContext,防止峰值OOM。
      3. 操作系统内存占用,如min_free_bytes、drop_cache等参与可以控制系统的内存占用。
    2. 如您怀疑的jason类型导致的,可以考虑改写SQL,如何减少单次查询内存的大小吗?

    3. 很多Cache和MemoryContext内存是跟backend有关的,可以通过减少并发链接数,间接减少内存占用,之前150节点TPCC测试,PlanCache增大导致的OOM就是这种情况,除了从BufferPool省除内存外,就是要开发plancache来减少这部分内存占用。

    4. OOM时会有Core文件,也可以debug下core文件,更具体定位下内存问题的原因。

    此答案来自钉钉群“PG|POLARDB技术进阶”

    2022-07-19 10:40:42
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
低代码开发师(初级)实战教程 立即下载
冬季实战营第三期:MySQL数据库进阶实战 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载