生产中一次内存使用过高排查过程

Posted joinbestgo

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了生产中一次内存使用过高排查过程相关的知识,希望对你有一定的参考价值。

本文参考

? https://blog.csdn.net/top_gun_1/article/details/50777329

  • 我这里知道这个消息是通过bearychart报警消息获得的,报警的信息是,当前服务器内存使用值已经达到了百分之九十二

  • 由于该机器我无法从外网连接,所以周六来公司看了下情况,通过htop命令看到是MongoDB在大量吃内存,物理内存吃掉14个G,虚拟内存吃掉16个G

一点解释:
目前,MongoDB使用的是内存映射存储引擎,它会把磁盘IO操作转换成内存操作,如果是读操作,内存中的数据起到缓存的作用,如果是写操作,内存还可以把随机的写操作转换成顺序的写操作,总之可以大幅度提升性能。MongoDB并不干涉内存管理工作,而是把这些工作留给操作系统的虚拟缓存管理器去处理,这样的好处是简化了MongoDB的工作,但坏处是你没有方法很方便的控制MongoDB占多大内存,事实上MongoDB会占用所有能用的内存,所以最好不要把别的服务和MongoDB放一起。

Linux内核有oom kill 机制,大概意思就是内存使用过高,会随机干掉一些服务(这里我也不清楚它是如何选择干掉的服务的,应该是根据进程号.docker可以设置不受oom kill机制的限制,但很危险)
  • MongoDB释放内存的几种方法
  1. 重启服务器释放内存(最笨,最行之有效,最危险)
  2. 参考文首文档里的有两条命令,但没有测试过,测试了"closealldatabases"那个,没有明显降低内存
  • 最后解决

由于数据库都是在docker里的,我打算跟领导说下,使用docker资源限制机制,暂时的话先不要停掉容器来达到缓解内存的目的

  • 总结
  1. 独挡一面能力不够强,原因很多,找一个理由说服下自己,数据库或者其它一切东西不是我参与搭建或者独立搭建的,心里没有数,难免放不开手脚
  2. 时间的问题

以上是关于生产中一次内存使用过高排查过程的主要内容,如果未能解决你的问题,请参考以下文章

如何在生产环境排查 Rust 内存占用过高问题

如何在生产环境排查 Rust 内存占用过高问题

记一次线上内存溢出问题排查过程

JVM探秘:线上CPU占用过高故障排查

tomcat内存占用过高排查小结

记录一次生产环境Net Core应用内存暴涨导致OOM的排查过程