1.生产环境问题描述
一台机器上的某个进程直接就消失了，别的机器上的服务都正常跑着，怎么排查原因？包括java进程、mysql、redis、mq 也是一样的情况。
2.Linux软件环境准备
（1）安装 gcc yum install gcc -y
gcc是一个编译器，没有界面，在命令行模式下使用，通过gcc命令可以将源文件编译成可执行文件。
gcc 命令如果不指定目标文件名时默认生成的可执行文件名为 a.out(linux) 或 a.exe(windows)。
可用gcc [源文件名] -o [目标文件名] 来指定目标文件路径及文件名。
C语言中，malloc函数的作用是动态分配内存，不能自动释放，申请的内存单位是字节。
（2）创建测试代码，这里采用c语言的程序
#include <stdlib.h> #include <stdio.h> int main(void) { while(1) { printf("..."); char *p = malloc(1024 * 200); if (p == NULL) { return -1; } } return 0; }
- c语言不会像Java那种有垃圾回收机制，c语言要手动释放内存，所以这里好演示内存占满的情况。
3.编译运行程序，分析现象
# 编译程序 gcc test.c -o test.out
# 先看一下内存的使用情况 free -h -s 5 top
# 运行程序 ./test.out
- 注意看这三张图，运行test.out进程后，内存一直在上升，直到test.out进程消失。
4.进程消失原因分析
Linux服务器上有多个应用程序运行，应用压力突增情况下容易出现各种问题，在多应用部署时需要注意对内存分配和资源隔离。
Linux系统在内存不足等条件下会主动干预进程（OOM-Killer机制），OOM Killer给进程打分，把oom_score最大的进程先杀死，打分主要有两部分组成。
一种系统根据该进程的内存占用情况打分，进程的内存开销是变化的，所以该值也会动态变化
另一种用户可以设置的 oom_score_adj，范围是 -1000到 1000
当然还有可能是公司同事重启了机器，导致进程没开机自启动运行。
通过last reboot查看机器是什么时候重启的。
5.生产类似进程消失的案例
- Rocketmq消息队列、Naocs服务注册发现、Java微服务jar 等进程常规运行，突然消失
- JVM本身的内存会启动的时候指定，但是JVM还有堆外内存，主要包括
- JVM 自身运行占用的空间、线程栈分配占用的系统内存、Java 8
开始的元数据空间
DirectByteBuffer 占用的内存、JNI 里分配的内存、Unsafe 调用分配的内存；
这些技术在中间件、复杂技术业务项目等都高频出现
不由JVM触发也不由JVM管理，是系统内核的一种安全保护措施，包括可用内存(含swap)不足， 就有可能会影响系统稳定
- 这时候 Out of memory killer 就会设法找出进程并杀死，引起 Out of memory: kill process or sacrifice child 错误
- 配置Swap有好有坏，Full GC总比OOM 进程消失要好
6.如何通过日志查看消失进程
（1）/var/log/messages 日志
- 是核心系统日志文件，包括整体系统信息、系统启动时的引导消息、系统运行时的其他状态消息
- 在做故障诊断时可以首先查看该文件内容，比如IO 错误、网络错误和其他系统错误都会记录到这个文件中
#过滤kill进程相关的日志 cat /var/log/messages | grep Kill
（2）/var/log/dmesg日志
- 用dmesg查看，包含内核缓冲信息，在系统启动时，会在屏幕上显示许多与硬件有关的信息
#egrep 详细: -i 忽略大小写 -C n key 输出匹配key关键字及关键字上下的n行 #过滤出 killed process 上下10行日志 dmesg | egrep -i -C10 'killed process' #增加人类可读的时间戳 dmesg -T #常用完整命令 dmesg -T | egrep -i -C10 'killed process'
7.OOM评分机制和进程雪崩实战
（1）什么是oom_score
- 对某一个task进程进行打分（oom_score），实际得分需要考虑两方面，然后把oom_score最大的进程先杀死。
- 一是系统打分，主要是根据该task的内存使用情况，进程的内存开销是变化的，所以该值也是动态变化的。
二是用户打分，也就是oom_score_adj，默认是0，取值范围是-1000~1000
0表示用户不调整oom_score，负数表示要在实际打分值上减去用户的这个配置
正值表示要惩罚对应的进程，也就是增加该进程的oom_score
如果用户将该进程的 oom_score_adj 设定成 -1000，表示禁止OOM killer 杀死该进程，特别重要的服务可以配置
说明：proc文件系统是虚拟文件系统，某个进程被杀掉，则/proc/pid/ 目录也会被销毁
# 查看某进程系统的评分 cat /proc/$(pidof 进程名称)/oom_score #先查看用户默认的评分 cat /proc/$(pidof 进程名称)/oom_score_adj #手工修改评分 sudo sh -c "echo -500 > /proc/$(pidof 进程名称)/oom_score_adj"
（2）测试进程雪崩
- 修改上面编写的c测试程序，将每次申请的内存修改的小一点。
#include <stdlib.h> #include <stdio.h> int main(void) { while(1) { printf("..."); char *p = malloc(1024); if (p == NULL) { return -1; } } return 0; }
把一个一直申请内存的进程的 oom_score_adj 设置为-1000，会导致大量的都进程被kill，因为我们的test.out是在bash中启动的，bash也是个进程，所以这个bash挂了，test.out也停止了，如果是后端运行，则更多进程都会被kill。当运行test.out 的这个bash被kill掉之后，内存就恢复成正常了。
查看被kill掉的进程
#过滤kill进程相关的日志 cat /var/log/messages | grep Kill #常用完整命令, 可能损坏查询不到信息 dmesg -T| grep "Out of memory"
