比top更好用-可查看全部进程及某个进程的线程的linux命令Htop以及遇到服务端大量连接出现CLOSE_WAIT的问题排查解决

一、比top更好用-可查看全部进程及某个进程的线程的linux命令Htop

    可以使用命令top -H -p <pid>可以查看线程，不过有一个更好用的命令htop，htop算是top的升级版，top只能查看当前屏的数据，htop可以让你在垂直和水平方向上滚动，从而看到运行的所有进程，以及他们完整的命令行 publish:November 21, 2018 -Wednesday。

    htop 是Linux系统中的一个互动的进程查看器，一个文本模式的应用程序(在控制台或者X终端中)，需要ncurses。与Linux传统的top相比，htop在启动上比top更快，而且杀进程时不需要输入进程号，并且支持鼠标操作，支持颜色主题，总之htop更加人性化，centos上使用yum安装即可：

[ffv@s2 ~]$ yum install htop
#安装后直接招待htop，显示界面如图：
[ffv@s2 ~]$ htop

htop显示的部分总共分为四个区域：

第一区域：CPU、内存、Swap的使用情况；

第二区域：任务、线程、平均负载及系统运行时间的信息。

        平均负载部分提供了三个数字，这仅仅表示的是过去的5分钟、10分钟和15分钟系统的平均负载而已，在单核的系统中平均负载为1表示的是百分之百的 CPU 利用率。最后，运行时间 （uptime）标示的数字是从系统启动起到当前的运行总时间。

第三区域：当前系统中的所有进程。这个和top差异不大，各列说明如下：

PID：进程标志号，是非零正整数
USER：进程所有者的用户名
PR：进程的优先级别
NI：进程的优先级别数值
VIRT：进程占用的虚拟内存值
RES：进程占用的物理内存值
SHR：进程使用的共享内存值
S：进程的状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值是负数
%CPU：该进程占用的CPU使用率
%MEM：该进程占用的物理内存和总内存的百分比
TIME+：该进程启动后占用的总的CPU时间
COMMAND：进程启动的启动命令名称

第四区域：底部菜单栏,列出来F1-F10功能键

        进入界面后，可以用鼠标点击下面的进程，然后使用方向键上向移动，点击某个进程后，可以看到下面的菜单栏也跟着变化，比如选择后可以使用F9杀死进程，可以使用F5进行排序。总之菜单的意义一看就知道。

二、遇到服务端大量连接出现CLOSE_WAIT的问题排查解决 

    访问服务器接口报警，浏览器中请求接口发现http请求一直在响应中，最后都执行出错。登录服务器负载内存数据都正常，但请求半天没有执行结果就感觉发送的请求服务器没有收到一样。查看nginx日志发现很多499错误，499错误的原因是客户端关闭了连接：nginx出现499错误码的原因以及proxy_ignore_client_abort配置 及 nginx日志配置变量大全意义详解_nginx 499-CSDN博客。客户端为什么关闭了连接呢？查看服务器端的连接情况，发现统计如下： 

[online@USER-04 nginx]$ sudo netstat -tnp | awk '{print $6}' | sort | uniq -c
      1 
  40493 CLOSE_WAIT
   3110 ESTABLISHED
     21 FIN_WAIT1
     37 FIN_WAIT2
      1 Foreign
     96 LAST_ACK
      8 SYN_RECV
   5777 TIME_WAIT
[online@USER-04 nginx]$ ulimit -n
65535

     上面可以看到有大量的CLOSE_WAIT状态的连接，这肯定不正常，而且从数据上一看就发现这些连接加起来已经快达到了ulimit -n连接数了。

#. 关于CLOSE_WAIT状态

    TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证无用连接完全断开，否则大量僵死的连接会浪费许多服务器资源.
    客户端TCP状态迁移：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED
    服务器TCP状态迁移：CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

    在断开的过程中，主动关闭的一方发出FIN，同时进入FIN_WAIT1 状态，被动关闭的一方响应ACK，从而使主动关闭的一方迁移至FIN_WAIT2状态，接着被动关闭的一方同样会发出FIN，主动关闭的一方响应ACK，同时迁移至TIME_WAIT状态。从这个逻辑来看，服务端进入了CLOSE_WAIT状态说明服务器端已经到了响应客户端关闭时请求的FIN, 但还没有发出自己的FIN。于是我在服务器上进行了重启nginx和php服务，发现无用。然后我进一步查看CLOSE_WAIT状态是哪种连接的数据，通过netstat统计发现全都是PHP进程的状态，可以代入理解，上面的TCP状态迁移中客户端就是nginx,服务端就是php,最后php未发出自己的FIN从而停留在了CLOSE_WAIT状态，为什么会产生这么多的CLOSE_WAIT呢？

    在发现是php存在大量的CLOSE_WAIT状态后，我深度杀死php，然后再重启php，发现这个凑效，请求就正常了，但通过netstat发现CLOSE_WAIT状态的数量会在持续增加，没多久就超过了万，然后继续增大，于是我怀疑是有请求在攻击，通过对访问日志中的IP进行统计，发现统计最靠前的IP存在明显异常，占了总服务器请求的一半，而且请求频率超频繁，在持续刷入。

    于是我修改了一下nginx配置文件，增加了一行deny记录，杀掉php再启动php(注意这里使用kill -USR2处理不能解决)。但为什么这个IP大量请求会产生这么多CLOSE_WAIT状态呢？简单看了一下程序也没有发现什么异常，

    其它：不知道php的配置：request_terminate_timeout 会不会对此起作用。目前服务器上的此项我看用的是php的默认值即0，但是按照上面的逻辑，即便修改此值，也只是缓解，并不能解决问题。如果这个IP的攻击请求频率再加大，就会出现异常了。另外我上面是直接deny了IP，也可以使用nginx的扩展来限制IP的请求频率。