1.现象

线上一台备用节点logtail 100%，这台机器是8核，部署的是线上服务的备用节点，平时都没什么负载，现在负载居然到了500多

这时想到的最直接的操作就是kill -9，居然干不掉

2.追查过程

1）看最近系统有什么报错：

这里发现当天有报系统调用mkdir操作超时，然后取样了这里的几个进程，

这里发现crontab发起的很多任务，最后都挂住了，

继续统计，发现跟负载中的数量对得上，虽然负载看着很高，但是cpu负载并不高，继续查看

发现这些进程最后都挂在了mkdir

父进程可以干掉，最后执行mkdir的子进程干不掉，跟logtail类似

2）gpt分析一下系统报错

大概有个结论，就是系统有个锁一直没放掉，导致新的进程执行mkdir时挂在了申请锁的节点

3）strace,pstack出场

最早想通过strace查看一下logtail到底在执行什么，结果机器上strace没安装，于是yum install，

最后也挂住了，退不出来，幸好strace已经安装好了，于是

发现也挂住了，

pstack也挂住了，

4）从cpu 100%入手

这里初步有一个结论，被卡住的其他进程cpu都是0%，只有logtail是100%，还是单线程，那么就是logtail占着锁，还死循环了，那为什么kill -9不行，看gpt

大概意思是，有些关键系统调用执行过程中，是不允许直接捕获SIGKILL二退出进程的，这就解释了为什么上面的logtail进程无法kill -9，那只有它只这样吗，

包括前面说到的yum install，包括那些crontab启的mkdir的进程，还有我实验性的 strace mkdir /tmp/aa,这些进程都无法kill -9，不同的是，这里是两个系统调用，一个是mkdir，一个是open，不过目录都是/tmp,同样求助gpt

得到一个结论，应该是/tmp上有一个目录项锁，同时在其他目录操作是没有问题的，也印证了只有/tmp锁了

logtail cpu100%，而其他进程0%，logtail还是单线程，说明logtail拿着这个锁，而其他进程都在等这个锁

5）查看这个锁

通过lslocks查看，发现logtail在/tmp上并没有锁，但是通过lsof查看

发现有一个锁文件

6）初步结论

简单分析，logtail 100%，其他进程0%，应该是logtail拿着锁没有释放，因为没法strace查看logtail进程，所以细节暂时无法深究，阿里云的技术人员也祭出各种绝技，终究跟我上面的分析差不多，最后他们说dump整个机器，后续再慢慢分析，但是这个机器需要重启，把锅甩给阿里云之后，我会继续跟踪，希望他们能给出一个确切的分析结论。