应用服务器内存泄露故障诊断实践

 

2017-02-16 上午9点左右，运维人员发现应用突然变慢并出现换页问题，短信验证码明显比正常情况下变慢，整个影响大约持续了2分钟。

1.    系统运维人员9:10登录APP01服务器，通过history及nmon收集到的数据，分析发现有人使用vi工具查看日志文件，导致了换页问题;

2.    使用vmstat命令，发现系统一直在换页，通过执行top工具发现java虚机占用了8GB的SWAP内存，通过设置jvm内存堆大小将内存调整为固定大小1.5G，重启后问题解决，通过ps aux发现内存不断增长的进程并进行重启；

3.    通过lsof工具发现xbus用户某进程在不断打开文件并不断增长，打开文件数量超过11万个，与研发沟通确认为程序Bug，程序逻辑open文件后没有进行close。

通过以上收集到的数据来看目前xbusapp1系统存在如下问题：

1.     JVM没有进行合理设置堆内存，导致占用内存过多；      

2.     程序存在缺陷，申请内存后没有及时free；

3.     程序打开文件后没有及时colse掉文件，造成系统资源浪费。
一、正常服务器内存使用情况

图1-1收集了理财应用服务器近3个月的内存使用情况，从本图中我们可以看到基金与理财应用服务器内存整体使用情况比较平稳，基本都徘徊在15G以内进行有规律的波动，未有明显增长趋势。2016年12月8日与22日零点以后内存的突然下降是由于应用发版重启was导致，再排除12月10日与1月3日内存出现的一个峰值干扰点外，我们可以分析得出基金与理财应用程序长时间运行在15GB以下，内存使用上基本比较正常。

图1-2绘制了公务卡应用服务器近3个月的内存使用情况，从本图中我们可以看出公务卡应用服务内存基本在2GB到3.5GB内有规律的波动，在持续运行近90天的时间内未见内存有明显的增加趋势。其中在2016年12月8日、2017年1月8日、1月16日内存突然出现了一个峰值并很快被回收，排除以上干扰点之外，我们能够分析得出公务卡系统在内存使用上是比较合理的。

二、APP1过去三个月内存使用情况

 图1-3绘制了联机XBUSAPP1近3个月内存的使用情况。通过上图我们能够看出XBUSAPP1上的应用基本经过近1一个月的持续运行后内存会从10GB增长到30GB，接近系统可用内存的极限。系统此时已经变得极其脆弱，如果我们再不及时介入处理，即使日常的一些常规操作都极有可能导致系统的异常甚至服务的停摆。

对于上图系统活动内存成周期性的下降及下降的幅度有时比较小有时比较大的原因是由于我们只重启了部分或者全部服务导致，鉴于篇幅的问题，这里不再做过多的解释。

通过分析APP1近一个月内存使用曲线，可以分析得出在2017年2月16日9点左右xbusapp1的活动内存接近系统容量的极限，此时恰巧运维人员使用vi操作查看应用日志进行例行检查，然后导致了短信验证服务异常，最后通过重启部分进程，内存紧张的情况得到缓解，服务恢复正常。在2月16日18:30左右又对部分服务进行了重启，内存紧张的情况进一步得到了缓解。2月23日凌晨xbus进行了一次发版，联机服务基本通过全部重启后，内存的利用率降到了最低点。

根据最近几天的观察，23日发版后，内存增长趋势有所缓解，但是仍有增加的趋势，所以仍需要进一步的跟踪、观察内存使用情况。

四、进一步向下钻取
 

表2-1是通过部署集脚本采集常驻进程内存数据后，绘制从2017年2月23日发版后到2017年3月1日大约7天的内存使用情况曲线图。通过曲线图，我们可以看出从2017年2月23日到2017年3月1日MQXSVC相关进程使用内存在逐渐增加且没有释放的迹象。以MQXSVC_A进程为例，7天的实际内存需求由540MB增加到了760MB，以上4个进程每天增加的内存总计达到约90MB左右。

上表中只绘出了部分进程内存增长情况，由于有些进程虽然内存增长较快，但是其生命周期短暂等原因，所以没有完全体现在表2-1中。

五、结论与建议
通过以上数据分析可以确认XBUSAPP1应用相关进程存在内存泄露的问题，需要研发进一步协助定位并解决程序逻辑存在的缺陷。
关于app1内存泄露的问题可以从以下两个分析维度解决：
一、从解决问题的角度，关于app1内存泄露问题可以从以下2个方面分析定向：
(1) 从系统层面dump数据进行反推，定位存在问题的功能模块、函数及放法；
(2) 从应用层面debug或者利用内存泄露检查工具进行分析、定位。
二、从运维的角度（短时间无法解决的折中方案）
(1) 系统层面，可以对c开发的平台，从OS层面把内存作为KPI指标建立可视化视图，进行展示，实时跟踪内存使用趋势，通过趋势分析预判服务是否需要重启及重启时机，由被动运维转为主动运维，以此将影响降到最低；
(2) 从服务层面，编写相关脚本，抓取内存快速增长的关键进程及进程打开文件句柄数等指标在大屏展示，根据增长的趋势、缓急及历史基线预判该服务是否需要人工介入处理，以将影响生产稳定运行的隐患提前解决掉的。
c语言开发的平台确实比较容易存在内存泄露的问题，因为对于内存的申请与释放的权利都完全交由开发人员处理，这对研发人员来讲是一种很大的挑战，而且内存泄露问题一般都比较隐蔽、难于发现。一个存在内存泄露的系统交付上线后可能在一个很长的时间周期内都不会对生产的稳定运行造成影响。