记一次解决业务系统生产环境宕机问题!

来源 | 个人博客 | 作者 | 打破突破

一、现象

Zabbix告警生产环境应用shutdown,通过堡垒机登入生产环境,查看应用容器进程,并发现没有该业务应用的相应进程,第一感觉进程在某些条件下被系统杀死了,然后查看容器日志,发现均没异常可寻。

二、问题

1、为何会没有应用进程及异常的日志输出?如果真的是系统杀死了应用进程,是什么条件触发了它?

2、测试环境、UAT环境为何从未有这样的情况,差别在哪?

三、排查

首先去查看生产环境系统资源情况及相应容器的配置,查得该台生产机器的总内存是8G:

接着查看该应用所在容器环境的变量设置:

此处可以看到这里为java设置的最大内存为4G,接着我们又查看了部署在本台机器上的另一个应用环境的设置,结果和该应用一样,设置的内存大小为4G,我们继续查看了该机器上的其他java应用,发现另外还部署了一个本地queue(activitymq),且设置的最大占用内存为1G,此时似乎已经可以猜测,由于机器的总内存不够,当应用在申请新的内存时,由于环境变量设置的缘故并没有去触发GC,而是直接申请内存,系统方发现总内存已经不够用,于是直接将该应用进程杀死。

为了验证上面的说法,我们查找系统的相关日志:

清晰地看到:Feb 23 00:01:09 us-app01 kernel: Out of memory: Kill process 14157 (java) score 619 or sacrifice child,此处说明的确是系统杀死了应用进程,根据这里的系统日志查询资料得知,系统会为每一块新分配的内存添加跟踪记录至low memory,当low memory的内存耗尽同时有需要新分配内存时,内核便会触发Kill process,此处为什么系统选择了kill该应用进程,我的猜想是一该应用进程属于用户进程,它的结束并不会影响系统的正常运行,二是由于该应用最大可用内存设置的不合理性,需要新分配内存来存储对象就发生在其中。由于当时的进程已经被系统杀死,我们无法得知当时具体内存的使用及分配情况,作为参考依据我们选择查看相同环境下的另一台机器的内存情况:

此处可以看出系统的总内存为7967m,low memory的总内存也为7967,(64位的系统,系统总内存与low memory相同),当前low memory已经使用7832(low memory = used + buff/cache)。

种种迹象表明:由于该应用及部署在同一台机器上的另一个应用,其环境中最大可用内存设置的不合理(系统总内存8G,这两个应用的最大可用内存设置为4G,同时机器上还有一个本地queue)性,导致其内部在申请内存时由于系统的low memory被耗尽,触使系统杀死了该应用进程。

四、临时解决

减少应用环境中的设置的最大可用内存,重启应用。

五、继续解决

应用重启后的一段时间(几天后),我们查看应用使用的内存情况:

我们想到该应用满足的业务量很小并没有那种数据量特别大的场景,为何系统会使用掉这么多的内存呢,于是我们决定对该应用从代码角度上进行一些可行的调优。

首先使用jmp dump出内存快照,并导入jprofiler,借助jprofiler进行分析:

从上图我们可以看到char[]占用了651m的内存,String占用的是10m左右,显然这里对char类型的使用或者处理是有问题的,我们进一步查看到底是什么地方使用了char[],又有哪些大的char[]实例,以及其中都存了怎样的数据:

这里我们看到有将近20个char[]实例的大小都超过了10m,其中最大的已然有30m,我们再查看这里都存了哪些数据:

此处可以看到其中有一些业务数据的记录,另外其内存数据中还有部分公司内部任务中心的一些任务信息(此处就不截图出来了),于是我们隐隐感觉到是不是任务平台做了什么事情,比如收集日志什么的,我们继续查看其引用情况:

看到此处的rabbit基本可以断定了就是任务中心client的引用,项目中其他地方并没有用到rabbit,于是我们找到任务中心的维护人员进行询问,他们的答案是不会去收集应用的日志的(我们心里的答案也是这,又不是日志平台的client,任务中心团队不会做这么傻的事),然而我们在char[]中的确看到的都是任务平台的信息这是怎么回事?于是我们查看任务平台客户端的源码及对外的api,看看能有什么线索,最终锁定了一个问题,任务平台客户端使用了线程池,并且默认的线程池中线程最多为100(这个是有些坑,简单说明,任务中心是通过queue实现的,服务端发送任务消息,client收到后消费)。

我们再看到截图中的线程,隐隐也是任务中心client的线程池中的线程,于是我们进一步查找到底哪里才会使用char[],并且会有业务数据,查看全局代码后我们发现对于应用中任务消息的处理器并没有直接使用char[],组内一位同学提醒是不是使用log4j打日志处理不当的原因,想一想就目前现状而言,这种说法说的通,于是我们在每一个任务处理器中查看日志上有没有大对象的输出,果然找到了一些(订单、库存等....)。

于是我们查阅相关资料了解到log4j会将当前线程中被打印的最长记录的大小进行缓存,至此该问题已经说得通了。

由于任务中心的客户端启用了默认最大线程数为100的线程池,这些线程用来消费服务端发送过来的任务消息,该业务应用中配置很多关于库存、订单的相应任务,在这些具体任务消息的处理器中存在一定的大对象日志输出。由于线程是用线程池维护,每次执行完并不会被销毁掉,因此会存在大量的缓存区域。

这样也就能回答我们最初设想的第二个问题:测试环境、UAT环境为何从未有这样的情况,差别在哪?差别有四个地方:

  • 系统环境的内存大小及虚机版本。
  • 订单数据或是库存数据量的差异。
  • 测试环境和UAT环境我们并不会配置很多的job,更多的是测试完就结束。
  • 应用重启的频率不同,测试环境较为频繁。

六、最终处理方案

(1)将任务中心客户端消费任务消息的线程池的最大线程数按照应用的实际情况改为10。

(2)去除对大对象的日志输出。

同时将任务中心客户端对于默认线程池的最大线程数设置的不合理性进行反馈,避免同样的事情发生在其他项目组。

七、总结

1、当low memory被耗尽时,系统会kill掉不会影响自身稳定运行的用户进程。

2、应用上线程池的最大线程数的设置需要根据机器环境及应用本身进行合理设置,尤其要注意依赖消息实现的三方工具包中的线程次设置,避免被其引用的对象使用过量的缓存等。

3、在组内会议中明确,任务处理器中不允许有大对象的日志输出。

作者:打破突破

链接:https://my.oschina.net/u/3345762/blog/1784199?p=2

原文发布于微信公众号 - Java后端技术(JavaITWork)

原文发表时间:2018-04-02

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏carven

react-native使用cookie

不久前,因为课程需要,我使用react native搭建了人生第一个完整的app--一个广外的教务查询系统。 祥见我的第一个react native项目 总体上...

2080
来自专栏数据和云

数据库高可用和分区解决方案-MongoDB 篇

许春植(Luocs) (阿里巴巴高级数据库管理员,7年以上数据库运维管理经验,擅长MySQL、Oracle及MongoDB数据库,目前主要研究并建设Mongo...

7406
来自专栏QQ音乐技术团队的专栏

全民K歌后台编译优化:从40分钟到30秒

编者注 :全民K歌上线1年半的从0发展到1.5亿,用户越来越多,后台代码库越来越大,编译速度也与日俱慢,编译一下整个工程需要30-40分钟,如何实现秒编至关重要...

3597
来自专栏FreeBuf

反取证技术:内核模式下的进程隐蔽

介绍 本文是介绍恶意软件的持久性及传播性技术这一系列的第一次迭代,这些技术中大部分是研究人员几年前发现并披露的,在此介绍的目的是建立这些技术和取证方面的知识框架...

3238
来自专栏IT技术精选文摘

带着问题学习分布式系统之数据分片

分布式系统(尤其是分布式存储系统)需要解决的两个最主要的问题,即数据分片和数据冗余,下面这个图片形象生动的解释了其概念和区别: ? 其中数据即A、B属于数据分片...

4456
来自专栏编程直播室

折腾git pages+hexo+NexT初识hexo开始本地试运行准备服务器准备上传工具先告一段落发表文章主题

2126
来自专栏linux、Python学习

IBM技术专家教你“懒惰”Linux管理员的10个关键技巧

好的系统管理员区分在效率上。如果一位高效的系统管理员能在 10 分钟内完成一件他人需要 2 个小时才能完成的任务,那么他应该受到奖励(得到更多报酬),因为他为公...

830
来自专栏喵了个咪的博客空间

[Golang软件推荐] Frp内网穿透

在一个IP紧缺的时代,连电信也不分配固定IP给到你用,一条专网专用线路贵的不行,那么作为软件开发人员常常要使用到外网,比如和微信调试程序,给到不在同一网段的朋友...

7434
来自专栏更流畅、简洁的软件开发方式

js的动态加载、缓存、更新以及复用(二)恼人的命名冲突

  上一篇发出来后得到了很多回复,在此首先感谢大家的热情捧场!有的推荐第三方框架,比如 In.js、requrieJS、sea.js、lab.js等。这个开阔了...

2268
来自专栏编程坑太多

『高级篇』docker之了解kubernetes(31)

PS:(梳理概念)pod里面包括N个容器,service里面包括pod,Deployment可能包括service或者是pod。

1384

扫码关注云+社区