记录一次CPU占用率高的解决经历

记录一次服务器cpu占用高的解决经历，

刚一发现这个问题觉得应该挺简单，不就是top查看进程占用率，然后找打相应的进程，找出哪个应用程序或者服务出的问题。

但是现实并没有那么简单，linux服务器上无论你怎么用top，或者htop，都无法发现CPU占用率高的进程，最多也才百分之五六，偶尔有些进程上去百分之五十，但是总占用率却总是百分之九十甚至百分之一百。我就纳闷了，到底是什么问题呢，于是乎我把所有CPU占用率稍微高点的进程像mysql，php-fpm都杀掉，过一段时间观察，以为会有好转，但是并不像想象的那般。CPU一点变化都没有。中途一直没找到原因，还联系了服务器代理商那边的运维人员，然而并没有什么用，问题还在。这其中还重启了N多到，想着会不会是mysql死锁什么的，但都不起作用。没办法之余，又去查看了mysql慢查询日志，虽然有记录慢查询，但不至于导致CPU占用率百分之百。

实在没办法了，于是申请加了一核CPU(原本单核)，升级成了双核，刚开始还挺正常的，过了一会儿，服务器有崩溃了，CPU再一次沦陷。就像瞎子过河一样，全靠摸索。终于通过perf top -s comm,pid,symbol，系统性能分析命令，找到了影响CPU占用的进程，就是这个进程在作怪，于是把它杀了，原以为就好了，结果，让我没想到的是，杀了一个进程，另一个进程又来了，这个时候我想到是不是被病毒攻击了。

后面，我想着应该是某个定时任务，在重启这个服务，于是乎，去查看linux的定时任务。果不其然，发现一个不是我们业务范围的定时任务，随后我将其删除，并杀掉相应的进程。过了没几分钟，呵呵，另一个进程又来了，去查看定时任务的时候，发现刚刚删除的定时任务又被创建了。我嘞个去，我这暴脾气，于是我把linux可能存在的所有定时任务，全找出来，然后把不认识的一个一个删除，最后再删掉占用率高的那个进程，果然，最后CPU恢复正常了，这次没有沦陷了，哈啊哈。

后面百度了下，是所谓的挖坑脚本不知道通过什么方法攻击到服务器，一直在对外发包。真的是过分，这些个脚本创建的进程top命令还检测不到，真让人头痛的，还好最后还是解决了。唉...  心累！

最终解决方案：https://blog.csdn.net/hgx13467479678/article/details/82347473