linux oom killer导致应用进程杀掉交易事务回滚

前段时间，公司同事遇到这样的问题，A系统通过RPC调用B系统，调用之前会在本地落单据，与RPC是在同一事务中。后来出现A应用挂掉，引发的问题是发现B返回给A系统，找不到相关流水，最后发现是linux在内存吃紧的情况下，会杀掉占用最大的进程，导致了数据库事务的回滚，但是RPC调用成功了，这是一个容易疏忽的不一致点。

 

 

Linux OOM-killer

 

前天线上出了个502错误，经排查是某开发人员写了条性感的程序吃掉了大部分内存，触发OOM-killer杀死Nginx

查看日志/var/log/messages发现类似"Out of Memory: Kill process..."错误

以前不了解OOM-killer{out of memory killer }，今天碰巧放假一天，借此学习下，涨涨姿势！

 

OOM_killer是Linux自我保护的方式，当内存不足时不至于出现太严重问题，有点壮士断腕的意味

在kernel 2.6，内存不足将唤醒oom_killer，挑出/proc/<pid>/oom_score最大者并将之kill掉

 

为了保护重要进程不被oom-killer掉，我们可以：echo -17 > /proc/<pid>/oom_adj,-17表示禁用OOM

我们也可以对把整个系统的OOM给禁用掉：

sysctl -w vm.panic_on_oom=1

sysctl -p

 

值得注意的是，有些时候 free -m 时还有剩余内存，但还是会触发OOM-killer，可能是因为进程占用了特殊内存地址

 

平时我们应该留意下新进来的进程内存使用量，免得系统重要的业务进程被无辜牵连

可用 top M 查看最消耗内存的进程，但也不是进程一超过就会触发oom_killer

参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略

当overcommit_memory=0 允许进程轻微过量使用内存，但对于大量过载请求则不允许

当overcommit_memory=1 永远允许进程overcommit

当overcommit_memory=2 永远禁止overcommit