您现在的位置是:首页 > 文章详情

Java应用异常状态监测

日期:2018-05-20点击:337

老板最近分派了一个任务,说线上客户在部署应用的时候发生了系统级别的OOM,触发了OOM Killer杀掉了应用,让我们解决这个问题。

对于这个任务,我从如下几点开始调研、分析与解决。

1、什么是系统级别的OOM(Out-Of-Memory)?

当创建进程时,进程都会建立起自己的虚拟地址空间(对于32位系统来说为4g)。这些虚拟地址空间并不等同于物理内存,只有进程访问这些地址空间时,操作系统才会为其分配物理内存并建立映射。关于虚拟内存和物理内存有很多资料,这里不再赘述,这篇文章写的通俗易懂,可以看下。

通过虚拟内存技术,操作系统可以允许多个进程同时运行,即便它们的虚拟内存加起来远超过系统的物理内存(和swap空间)。如果这些进程不断访问其虚拟地址,操作系统不得不为它们分配物理内存,当到达一个临界点时,操作系统耗尽了所有的物理内存和swap空间,此时OOM就发生了。

2、系统发生了OOM会怎么样?

当发生了OOM,操作系统有两个选择:1)重启系统;2)根据策略杀死特定的进程并且释放其内存空间。这两种策略当然是第二种影响面较小,由于我们线上系统也是采取杀死特定进程的策略,因此这里只展开第二种。

  • 第二种行为也称之为OOM Killer。那系统会杀死什么样的进程释放其内存呢?这篇文档的“Selecting a Process”部分大概描述了Linux内核的操作系统选取算法:首先,根据badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) * sqrt(sqrt(cpu_time_in_minutes)))来算起始值,total_vm_for_task为进程占用的实际内存,cpu_time_in_seconds为运行时间,这个公式会选取占用内存多且运行时间短的进程;
  • 如果进程是root进程或者拥有超级用户权限,那么上述得分会除以4;
  • 如果进程能够直接访问硬件(也就是硬件驱动),那么将得分再除以4。

但文档中描述并不完整,这个是Linux内核OOM_Killer的相关代码,然后这篇文章对代码进行了分析,除了上述因素之外还包含子进程内存、nice值、omkill_adj等因素。

操作系统会对每个进程进行计算得分,并记录在/proc/[pid]/oom_score文件中;当发生系统OOM时,操作系统会选取评分最高的进程进行杀死。

3、如何实现系统OOM告警?

OOM告警有两种方式,如下:

  • 提前OOM告警:在系统即将发生OOM时,发出告警信息。
  • 事中/事后告警:在系统完成OOM Killer杀死进程后,发出告警信息。

提前OOM告警是最好的方式,但实际上如果想达到不误报、不漏报,实现难度极大。我们线上应用为Java应用,考虑这么个场景:客户应用不断申请内存,当系统物理内存占用率达到90%的时候,系统及应用下一步行为会是什么样?个人认为有三种可能性:1)Java应用停止申请内存,并且进行了垃圾回收释放内存,这样系统将会恢复正常;2)应用继续申请内存导致应用内存超过了堆大小,但此时系统仍然有部分物理内存,这样会发生Java应用的OOM;3)应用继续申请内存导致系统耗尽物理内存,但此时没有超过堆内存的最大值,这样会发生操作系统的OOM。对于这个场景来说,我们想准确预判出系统及应用的下一步行为难度极大。

另一方面,我们线上其实已经有基于机器内存使用率的报警,这个报警其实已经包含了三种可能性:1)应用本身有问题但不会导致堆溢出或者系统OOM;2)应用可能会导致堆溢出;3)应用可能会导致系统OOM。无论实际情况为哪一种,这个报警都是有意义的。

事中/事后告警也是一种可取的方式,原因在于:1)这种方式能够实现不误报、不漏报;2)对于即将发生OOM的应用来说,事中报警与事前报警时间相差其实并不大。另外,到目前为止客诉的情况都是抱怨其应用死了没有任何通知,排查起来既浪费了客户时间,也浪费了研发排查问题的时间。

综合考虑,如果能够实现Java应用的异常状态检测并提供事中/事后报警与现场分析,也是很有意义的!

4、Java应用的异常状态为哪些?

这里定义的Java应用异常状态有:

  • Java应用被用户杀死(Kill、Kill -9);
  • Java应用发生堆溢出;
  • Java应用被系统OOM(Kill -9)。

5、如何检测出上述Java应用异常状态?

首先,Java应用发生堆溢出可以通过-XX:+HeapDumpOnOutOfMemoryError参数来生成dump信息,我们可以通过轮询方式即可发现是否发生堆溢出(当然基于事件通知方式更好,待调研)。

因此,现在问题在于我们怎么发现一个Java应用被用户杀死或者被系统OOM Kill掉?


5.1 ShutdownHook/sun.misc.Signal

老司机可能很快就想到,通过注册shutdownHook就可以检测到系统信号了呀!注册shutdownHook的确能检测到SIGTERM信号(也就是通常不带参数的Kill命令,如Kill pid),但不能检测到SIGKILL信号(Kill -9)。另外,调研发现也可以通过sun.misc.Signal.handle方法来检测系统信号,但遗憾的是还是不能检测到SIGKILL信号。

5.2 strace

这个工具非常强大,它能够拦截所有的系统调用(包括SIGKILL),并且具有系统已经内置、使用方便、输出信息可读性好等优点。下图是我的一个实验(进程24063是一个触发系统OOM的Java进程):

strace

 

但这个工具的缺点是,被跟踪的应用的性能影响非常大。应用原来进行系统调用(比如open、read、write、close)时会发生一次上下文切换(从用户态到内核态),使用了strace之后会变成多次上下文调用,如下图所示:

(更多信息可以参考这篇文章

但无论如何,我们已经找到一种可行的解决方案,虽然性能影响很大,但可以作为debug方案开放给客户。

5.3 ftrace + 系统日志

ftrace是Linux系统已经内置的工具(debugfs挂载情况见附录),它的作用是帮助开发人员了解 Linux 内核的运行时行为,以便进行故障调试或性能分析。重要的是,它对应用本身的性能影响极小,而且我们可以只检测Kill事件,这样对客户应用几乎零影响(性能分析见第6节)。在我们的场景下,它也支持内核事件(包括进程SIGKILL信号)监听。ftrace使用起来非常方便,可以参考这篇文档,或者直接使用这个GITHUB脚本即可。下面是运行该GITHUB脚本的一个截图:

在上图中,SIGNAL为15的是我执行Kill 29265命令,SIGNAL为9的是我执行Kill -9 29428命令。但这个工具的问题在于,当Java进程触发系统级别的OOM Killer时,并没有检测到相应的信号(待进一步调研)。

另外,当系统触发OOM Killer时,会在系统日志(Centos的为/var/log/messages)中记录下特定信息,如下所示:

 5.4 auditd + 系统日志

(系统日志用来发现OOM信息,不再赘述,下文主要介绍auditd)

同事建议可以尝试下auditd,因此这里调研auditd,发现它能满足需求,而且测试性能影响比ftrace更小(性能分析见第6节)。auditd是Linux Auditing System(Linux审计系统)的一部分,它负责接收内核中发生的事件(系统调用、文件访问),并将这些事件写入日志供用户分析。

下图是Linux审计系统的框架:

audit框架

其中:

  • 左边是我们的应用程序;
  • 中间为Linux内核,内核中包含了审计模块,可以记录三类事件:1)User:记录用户产生的事件;2)Task:记录任务类型(如fork子进程)事件;3)Exit:在系统调用结束时记录该事件。同时,可以结合Exclude规则来过滤事件,最终将这些事件发送到用户空间的auditd守护进程;
  • 右边是在用户空间的应用程序,其中auditd是核心的守护进程,主要接收内核中产生的事件,并记录到audit.log中,然后我们可以通过ausearch或者aureport来查看这些日志;auditd在启动时会读取auditd.conf文件来配置守护进程的各种行为(如日志文件存放位置),并读取audit.rules中的事件规则来控制内核中的事件监听及过滤行为;另外,我们也可以通过auditctl来控制内核事件监听和过滤规则。 

关于更多信息可以自行搜索或者看下这篇文章

内核已经内置审计模块,而auditd守护进程也默认在centos(>=6.8)中启动,下面我们来测试下该工具。首先,我们执行如下命令:

auditctl -a always,exit -F arch=b64 -S kill -k test_kill

这条命令作用是,在kill系统调用返回时记录事件,并且绑定test_kill标记(以便后面进行日志筛选)。然后,我们可以随便执行一个脚本并kill掉,可以在/var/log/audit/audit.log中看到如下输出:

auditd-test

第一条SYSCALL日志记录发送SIGKILL信号的进程信息,第二条OBJ_PID日志记录接收SIGKILL信号的进程信息。

5.5 Shell + dmesg

如果我们能够控制Java应用的启动脚本,那么此方式是影响最小的方案。先看下面这个shell脚本:

#!/bin/bash java -Xms4g -Xmx4g Main ret=$? # # returns > 127 are a SIGNAL # if [ $ret -gt 127 ]; then sig=$((ret - 128)) echo "Got SIGNAL $sig" if [ $sig -eq $(kill -l SIGKILL) ]; then echo "process was killed with SIGKILL" dmesg > $HOME/dmesg-kill.log fi fi

这个脚本做了这几个事情:

  1. 使用Java -Xms4g -Xmx4g Main来启动一个Java应用;
  2. Java应用退出后通过$?获取程序退出状态码;
  3. 如果退出码大于128,则为应用收到SIGNAL退出;如果为SIGKILL,则通过dmesg收集kernal ring buffer中的信息。

如果应用由于被OOM Killer杀死而退出,则dmesg-kill.log中会有如下信息:

dmesg

 此方案优点在于影响面最小,但进程杀死信息量相比auditd少,只知道收到何种SIGNAL信号;而auditd能够知道SIGNAL信号来源于哪个进程、用户、组。 

6、性能测试

6.1 测试环境

测试机器
ecs.n1.medium
CPU
2 vCPU
处理器型号
Intel Xeon E5-2680v3
处理器主频
2.5 GHz
内存
4 GB
系统镜像 CentOS 7.4 64位

6.2 测试脚本

6.2.1 测试一:系统调用性能影响

测试方法

从/dev/zero中读取500个字节数据并写入到/dev/null中,循环执行1亿次(也就是100M):

dd if=/dev/zero of=/dev/null bs=500 count=100M

该脚本会产生大约2亿次系统调用(read 1亿次,write 1亿次)。

测试结果

测试目标
总耗时(s
平均耗时(μs
不加任何事件监听
41.7
0.2085
auditd
47.1
0.2355
ftrace
77.3
0.3865
strace
> 3600
> 18

6.2.2 测试二:JAVA应用性能影响

测试方法:

构造consumer和provider应用,consumer向provider发起HSF调用,provider返回预定义数据,循环调用1百万次,观察consumer耗时。

测试结果:

测试目标
总耗时(s
平均耗时(ms
不加任何事件监听
492
0.492
consumer和provider都开启auditd
484
0.482
consumer和provider都开启ftrace
493
0.493
consumer和provider都开启strace
> 3600
> 3.6 

7、总结

综上,我们可以通过如下手段来解决客户的应用OOM问题:

  • 1. 使用机器的基于内存使用率报警来事前通知客户;
  • 2. JVM启动参数可以添加-XX:+HeapDumpOnOutOfMemoryError等参数来协助收集JVM内存溢出信息;
  • 3. 通过系统日志(/var/log/messages)或者dmesg来收集系统OOM Killer信息;
  • 4. 使用启动shell脚本(见5.5节)或auditd(见5.4节) ftrace 来获取应用被Kill掉的信息(可能被客户自身Kill掉)。
  • 5.【可选】开放strace工具来帮助客户debug问题。

8、其他工具

8.1 trap

trap命令用于指定在接收到信号后将要采取的动作,通常在脚本程序被中断时完成清理工作。当shell接收到sigspec指定的信号时,arg参数(命令)将会被读取,并被执行。下面我试图拦截当前脚本的SIGTERM和SIGKILL信号:

#!/bin/bash sighdl () { echo "signal caught" #do something exit 0 } trap sighdl SIGKILL SIGTERM ### main script X=0 while : do echo "X=$X" X=`expr ${X} + 1` sleep 1 done

测试发现,trap命令能够检测到当前进程的SIGTERM信号,但是无法检测SIGKILL信号。这个命令相当于Java应用中的shutdownHook或者Signal。

9、附录

9.1 ftrace系统debugfs挂载情况

(注:以下统计阿里云上主要的操作系统)
操作系统
系统版本
debugfs是否已经默认挂载
备注
CentOS



   7.4(64位)  是  
   7.3(64位)  是  
   7.2(64位)  是  
   6.9(64位)    mount -t debugfs nodev /sys/kernel/debug
   6.8(64位)    mount -t debugfs nodev /sys/kernel/debug
   6.8(32位)  否  mount -t debugfs nodev /sys/kernel/debug
 Aliyun Linux      
   17.1(64位)  是  
 Ubuntu      
   16.04(64位)  是  
   16.04(32位)  是  
   14.04(64位)  是  
   14.04(32位)  是  
 Debian      
   9.2(64位)  是  
   8.9(64位)  是  
 SUSE Linux      
   Enterprise Server 12 SP2(64位)  是  
   Enterprise Server 11 SP2(64位)  是  
 OpenSUSE      
   42.3(64位)  是  
 CoreOS      
   1465.8.0(64位)  是  
 FreeBSD      
   11.1(64位)    

  

 

原文链接:https://yq.aliyun.com/articles/594697
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章