2016-05-06中午11:56,收到“[sentry2]2016-05-06 11:56:09 xxxxxxhost xxx.xxx.xxx.xxx 内存使用已达到90.18%”报警。首先在脑海浮现的,应该哪里出现内存泄漏了。
一、确认问题
马上到 Sentry 监控系统查看了该服务的“服务器监控”指标,发现其中2台机器的内存使用量都超过了90%,另外2台尽然没有监控数据(以前是有的)。
对于另外2台服务器没有监控数据,只好先登上去查看确认一下喽。通过“free -m”确认,线上服务器总内存共 7872MB,使用了 7098MB,还有 773MB(= 406 + 151 + 216) 空闲着,使用率为 90.16%(= 7098 / 7872)。(参考:free(1) - Linux manual page、Linux Used内存到底哪里去了? | 褚霸-余锋)
从问题表现来看,该业务的4台机器都出现“内存使用量都超过了90%”。
二、排查问题
1. 对比一下该业务“服务器内存占用百分比”的历史状况
1.1 3月26日业务刚上线时,服务器内存占用百分比是 45%。
1.2 4月14日之前,服务器内存占用百分比稳定在 48%。
1.3 4月15日,服务器内存占用百分比突然从 48% 升到 61%。
1.4 4月17日,服务器内存占用百分比稳定在 67%。
1.5 4月18日到5月2日期间,服务器内存占用百分比稳定在 68%。
1.6 5月3日直到5月6日的报警期间,服务器内存占用百分比又从 68% 升到 90%。
从“服务器内存占用百分比”历史数据的异常时间点(4月17日、5月3日)来看,我们自己都没有发布上线过代码,说明不是我们引起的。
2. 查看 Sentry 监控系统的“进程监控”指标,运维同学发现 logagent 进程内存占用了 580MB。他们刚优化了 logagent 组件,1分钟在线平滑升级后(线上业务服务不需要重启),内存从 580MB 降到 54MB,还是很可观的。这样服务器的空闲内存又多出了500+MB,为排查线上问题流出了更多的时间。(当时做得不够好的地方,应该只保留一台作为现场排查问题,重启其他机器,避免线上可能因为所有机器 OOM 而导致整个服务不可用)(当时我们都没看到 sentry_agent 进程占用了近 1.3GB )
3. 内存泄漏的可能性最大,先验证之
向有经验的同学请教,说内存使用量飙高,一般都是中间件引起的内存泄漏。因为我们线上服务使用 Java 语言开发,所以先从 JVM 垃圾收集器 GC 入手,可以比较直观地看出 JVM 内存状况。(jstat -gcutil `pgrep -u mapp java` 1s)
上图输出的每个字段的含义见 jstat -gcutil 命令参考文档。从上图看,Eden 区(Eden Space (heap))内存占用每秒增长 1.5%,Survivor 区(Survivor Space (heap),S0、S1)内存占用在一次垃圾收集后增长 1.2%,Old 区(Tenured Generation (heap))内存占用在一次垃圾收集后增长 0.57%,Perm 区(Permanent Generation (non-heap))内存一直占用 59.97%。Young GC 平均耗时为 96.7ms ( = 358.407 / 3705),Full GC 平均耗时为 74.4ms(= 7.587 / 102)。
从“gc 监控”看,也没收到 Full GC 报警。同时查看 gc.log,ParNew GC 大约每隔几分钟触发一次,CMS GC 大约每隔5个小时触发一次,没有 Full GC。从 JVM 内存监控数据来看,说明 GC 都正常的。
3. 哪些进程用了那么多内存
从上面@褚霸在《Linux Used内存到底哪里去了?》总结的:内存的去向主要有3个:1. 进程消耗,2. slab消耗,3. pagetable消耗。
先看一下线上服务器的 JVM 配置(jps -lv):
2628 org.apache.catalina.startup.Bootstrap -Djava.util.logging.config.file=/home/mapp/spyder/.default/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Xms4g -Xmx4g -XX:PermSize=96m -XX:MaxPermSize=256m -Xmn2g -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000 -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -verbose:gc -Xloggc:/home/mapp/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseCompressedOops -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/mapp/logs/java.hprof -XX:MaxDirectMemorySize=1g -XX:+UseCMSInitiatingOccupancyOnly -XX:+ExplicitGCInvokesConcurrent -Dsun.rmi.dgc.server.gcInterval=2592000000 -Dsun.rmi.dgc.client.gcInterval=2592000000 -Dsun.net.client.defaultConnectTimeout=10000 -Dsun.net.client.defaultReadTimeout=30000 -Dproject.name=xxxxxx -Djava.endorsed.dirs=/usr/local/tomcat/endorsed -Dcatalina.base=/home/mapp/spyder/.default -Dcatalina.home=/
从 JVM 配置来看,最大内存为 4GB。
接着就是通过“top -M”(按RES字段排序:按 f,然后再按 q)观察哪些进程占用的内存不正常。
top 命令的 VIRT 字段表示虚拟内存,而 RES 字段才表示实际的使用内存。从上图(数据是事后伪造的,因为没保存当时现场,但量级和当时事故现场差不多)可以很清晰地看到,java 进程占用了 4.1g 内存,和 JVM 配置一样;两个 sentry-agent 进程尽然分别占用了 1.6GB 和 1.2GB(好吓人)。
sentry-agent 是一个收集日志的客户端,为什么会占用这么多的内存呢?向负责该服务的开发同学反馈,证实确实有问题,他们好像也发现问题了,他们答应当天下午修复问题。凭直觉,问题应该就出现在这里了。先让运维同学重启了 sentry-agent 进程,内存占用百分比一下子就降到了 59%,说明此问题的大部分原因是这里引起的。此数据与4月15日吻合,但与最开始的48%数据还有差距,这个还需要进一步排查。因为从 GC 来看,自身应用程序没发现内存泄漏问题,需要深入探究一下。
上述4台机器,前面2台使用 Docker 虚拟化,后面2台使用 KVM 虚拟化。内存占用百分比相差10+个点(相差 900+MB),注意是由于 slabs 消耗不一样引起的(参考@褚霸的文章)。
KVM 虚拟化:
$ echo `cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'` MB
139.037 MB
Docker 虚拟化:
$ echo `cat /proc/slabinfo |awk 'BEGIN{sum=0;}{sum=sum+$3*$4;}END{print sum/1024/1024}'` MB
1177.34 MB
问题解决前后,“内存占用百分比”对比图:
看了其他监控指标,发现“服务器线程总数”从680下降到400,说明 sentry-agent 存在线程泄漏问题。
至此,本问题算是解决了大部分,线上服务器内存暴涨问题得到了解决。(在群里反馈,其他服务先前就已经出现了此问题,但一直没有去排查,我也是醉啦,就不担心出现 OOM 吗?就不担心整个服务都不可用吗?这个问题解决得到 Leader 的赞还是很开心滴)
写博客确实花很多时间和精力,但回顾问题整个处理过程并反思处理思路,还是有很多地方可以改进(不懂时就上网查资料,了解清楚),收获颇多。(感谢每一个问题!)
祝大家玩得开心!
相关推荐
本文主要介绍如何使用 JProfiler 对应用服务器内存泄漏问题进行诊断和解决。内存泄漏是指应用服务器中的一种常见问题,表现为内存长期不合理占用,内存经常处于高位占用,很难回收到低位。这种问题会导致应用服务器...
- **jmap**:生成对象和类的内存使用快照,帮助定位内存泄漏等问题。 - **jstack**:获取线程堆栈跟踪信息,可用于分析死锁、挂起等情况。 - **jvisualvm**:图形化工具,可对JVM进行详细的性能分析,包括CPU使用率...
线上Java服务器内存飙升处理方式
本文将以一个具体的线上实例为背景,介绍如何逐步排查并解决内存泄漏问题。通过图文并茂的方式,帮助读者更好地理解内存泄漏的诊断方法。 #### 二、问题背景 在一个项目中,开发团队新上线了一个API接口,并选择了...
通过jmap产生的dump文件,我们可以使用内存分析工具(如MAT - Memory Analyzer Tool)进一步分析,找出可能的内存泄漏点。 **3. 使用arthas进行动态诊断** 除了jmap,arthas是一款针对Java应用的在线诊断工具,它...
在使用Apache Doris的过程中,有时会遇到线上Doris Frontend(FE)内存使用过高的问题。Doris系统架构中,FE主要负责元数据管理、查询请求解析与计划生成,而Backend(BE)则承担主要的数据存储和计算工作。尽管大...
本文将深入探讨如何使用JProfiler来识别和解决应用服务器的内存泄漏问题。 一、了解内存泄漏 内存泄漏是指程序在申请内存后,无法释放已不再使用的内存空间。这会导致可用内存逐渐减少,系统资源耗尽,最终可能导致...
Valgrind提供了一整套内存错误检测工具,包括Memcheck,它能检测内存泄露、使用未初始化的内存和内存越界等问题。LeakSanitizer是编译器插件,可以在编译时集成到程序中,提供更快速的内存泄露检测,而且无需使用GDB...
利用 JProfiler 对应用服务器内存泄漏问题诊断一例 本文主要从应用的角度来解决中间件应用服务器的内存泄露问题,以提高系统的稳定性和性能。文章通过对某个大型项目的案例分析,介绍了如何使用 JProfiler 工具来...
Lua是一种轻量级的脚本语言,常用于游戏开发、嵌入式系统和服务器应用程序等。在使用Lua的过程中,内存管理是确保程序高效稳定运行的关键因素之一。内存泄露是编程中常见的问题,它可能导致资源浪费,甚至导致程序...
4. 使用内存分析工具进行定期检查:在开发过程中,定期使用DDMS、LeakCanary等工具检查内存使用情况,及时发现和修复内存泄露问题。 总结来说,Android应用内存泄露是一个复杂的问题,涉及到Android内存管理机制、...
Electron-Vue 开发环境内存泄漏问题汇总 本文主要介绍了 Electron-Vue 开发环境中内存泄漏问题的解决方案。 Electron-Vue 是一个基于 Electron 和 Vue.js 的开发框架,用于构建桌面应用程序。然而,在开发环境中,...
为了解决这个问题,开发者通常会使用专门的内存泄漏检测工具。本文将详细介绍两个用于Windows平台的内存泄漏排查工具:LeakDiag和LDGrapher。 **LeakDiag** LeakDiag是由微软开发的一款轻量级内存泄漏检测工具,...
4. **使用内存分析工具**:如MAT(Memory Analyzer Tool)进行深度分析,帮助找到内存泄漏的具体对象和原因。 通过上述方法,可以逐步定位并修复内存泄漏,提升应用服务器的稳定性和性能。在实施解决方案后,应持续...
windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题windbg内存泄漏问题
内存泄漏是C++编程中一个严重的问题,它指的是程序在申请内存后,无法释放已申请的内存空间,一次小的内存泄漏可能看似无害,但随着时间推移,大量的内存泄漏会消耗掉系统的可用内存,导致性能下降甚至系统崩溃。...
在使用OpenCV时,经常会遇到内存泄露的问题,特别是在使用cvLoadImage和cvCloneImage函数时。这些函数的使用不当将导致内存泄露,影响程序的稳定性和性能。本文将详细介绍这两个函数的使用方法和解决方案,帮助...