系统运行缓慢
ipmi应该是用于系统管理的远控进程，虽然这是一个利用空余的CPU资源进行一些接口自动调节的任务，但看着占那么多的资源还是怕出意外。并且现在已经出了意外 反正不管怎么样试试
通过kipmid_max_busy_us值可占用以改变kipmi的调度方式实现降低cpu占用。
临时降低
echo 100 > /sys/module/ipmi_si/parameters/kipmid_max_busy_us
永久性降低（修改配置文件，模块/系统重启生效）
echo "options ipmi_si kipmid_max_busy_us=100">/etc/modprobe.d/ipmi.conf
修改了了之后再查看下系统负载，果然降低到了正常值。
发现大量gzip压缩进程和sshd进程占用cpu(最后发现是自己的备份脚本设置成了每分钟执行一次，自己把自己给坑了)
还是root用户启动的，向同事确认没人用后直接关了看后续情况
pgrep gzip|xargs kill # 查找进程pid并kill
400多个php-fpm和nginx，占用CPU百分百
CLOSE_WAIT
CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0
服务器的连接状态而言，一般有三种比较常见的： Established、 Time_Wait、Close_Wait。
TCP连接关闭时需要四次握手
A发一条FIN(关闭)请求给B，说我要关闭了；
B回应一条ACK(确认)请求给A，说我知道了，你关吧，此时B就会进行CLOSE_WAIT状态；
B发送一条FIN(关闭)请给A，说我要关闭了；
A收到发送一条ACK(确认)消息说，你关闭吧。
SYN表示建立连接，
FIN表示关闭连接，
ACK表示响应，
HttpClient连接池的中创建连接数已经达到了最大数字，不能够创建新的连接了，已经创建的连接都是在等待关闭（CLOSE_WAIT）的状态，没有被放回到可用的连接池中，不能够用于处理新的连接请求，因而所有的请求都是堵在了从连接池中获取连接哪里
通过原理图，我们知道了CLOSE_WAIT是被动关闭的状态。什么意思呢？比如客户端发了个请求，正常情况下是会收到服务器响应一个状态的，即Response。当客户端读取了这个返回后，会主动告诉服务器收到了，关闭连接。
解决办法
[root@121 ~]# lsof -i |grep 80
kill -9 26565