查看apache的请求进程数

孤独海岸线

apache服务器的fin_wait1过多time_wait过多问题解决　　1、fin_wait1状态过多。fin_wait1状态是在server端主动要求关闭tcp连接，并且主动发送fin以后，等待client端回复ack时候的状态。fin_wait1的产生原因有很多，需要结合netstat的状态来分析。
netstat -nat|awk '{print awk $NF}'|sort|uniq -c|sort -n　　上面的命令可以帮助分析哪种tcp状态数量异常
netstat -nat|grep ":80"|awk '{print $5}' |awk -F: '{print $1}' | sort| uniq -c|sort -n则可以帮助你将请求80服务的client ip按照连接数排序。　　2、time_wait状态过多。
　　通常表现为apache服务器负载高，w命令显示load average可能上百，但是web服务基本没有问题。同时ssh能够登陆，但是反应非常迟钝。
　　原因：最可能的原因是httpd.conf里面keepalive没有开，导致每次请求都要建立新的tcp连接，请求完成以后关闭，增加了很多time_wait的状态。另，keepalive可能会增加一部分内存的开销，但是问题不大。
　　分析：如果发现fin_wait1状态很多，并且client ip分布正常，那可能是有人用肉鸡进行ddos***、又或者最近的程序改动引起了问题。一般说来后者可能性更大，应该主动联系程序员解决。
　　但是如果有某个ip连接数非常多，就值得注意了，可以考虑用iptables直接封了他。
　　前言：经常检查Apache的连接数，同样会发现很多无用的Time_Wait连接。有人说这是正常的，是因为一个请求中途中断造成的;还有人说微软的IE 连接时产生的Time_wait会比用Firefox连接时多。个人认为有一定的Time_wait是正常的，如果超过了连接数的比例就不是很正常，所以还是找来方法解决一下。
　　检查net.ipv4.tcp_tw当前值，将当前的值更改为1分钟：
[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw　　net.ipv4.tcp_tw_reuse = 0
　　net.ipv4.tcp_tw_recycle = 0
　　[root@aaa1 ~]#vi /etc/sysctl
增加或修改net.ipv4.tcp_tw值：net.ipv4.tcp_tw_reuse = 1　　net.ipv4.tcp_tw_recycle = 1
　　使内核参数生效：
[root@aaa1 ~]# sysctl -p　　[root@aaa1 ~]# sysctl -a|grep net.ipv4.tcp_tw
　　net.ipv4.tcp_tw_reuse = 1
　　net.ipv4.tcp_tw_recycle = 1
设置这两个参数： reuse是表示是否允许重新应用处于TIME-WAIT状态的socket用于新的TCP连接； recyse是加速TIME-WAIT sockets回收　　用netstat再观察正常
　　这里解决问题的关键是如何能够重复利用time_wait的值，我们可以设置时检查一下time和wait的值
#sysctl -a | grep time | grep wait　　net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
　　net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
　　net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
　　如果使用了nginx代理，那么系统TIME_WAIT的数量会变得比较多，这是由于nginx代理使用了短链接的方式和后端交互的原因，使得nginx和后端的ESTABLISHED变得很少而TIME_WAIT很多。这不但发生在安装nginx的代理服务器上，而且也会使后端的app服务器上有大量的 TIME_WAIT。查阅TIME_WAIT资料，发现这个状态很多也没什么大问题，但可能因为它占用了系统过多的端口，导致后续的请求无法获取端口而造成障碍。
　　虽然TIME_WAIT会造成一些问题，但是要完全枪毙掉它也是不正当的，虽然看起来这么做没什么错。具体可看这篇文档：
　　http://hi.baidu.com/tim_bi/blog/item/35b005d784ca91d5a044df1d.html
　　所以目前看来最好的办法是让每个TIME_WAIT早点过期。
　　在linux上可以这么配置：
　　#让TIME_WAIT状态可以重用，这样即使TIME_WAIT占满了所有端口，也不会拒绝新的请求造成障碍
　　echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
　　#让TIME_WAIT尽快回收，我也不知是多久，观察大概是一秒钟
　　echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
　　很多文档都会建议两个参数都配置上，但是我发现只用修改tcp_tw_recycle就可以解决问题的了，TIME_WAIT重用TCP协议本身就是不建议打开的。
　　不能重用端口可能会造成系统的某些服务无法启动，比如要重启一个系统监控的软件，它用了40000端口，而这个端口在软件重启过程中刚好被使用了，就可能会重启失败的。linux默认考虑到了这个问题，有这么个设定：
　　#查看系统本地可用端口极限值
　　cat /proc/sys/net/ipv4/ip_local_port_range
　　用这条命令会返回两个数字，默认是：32768 61000，说明这台机器本地能向外连接61000-32768=28232个连接，注意是本地向外连接，不是这台机器的所有连接，不会影响这台机器的 80端口的对外连接数。但这个数字会影响到代理服务器（nginx）对app服务器的最大连接数，因为nginx对app是用的异步传输，所以这个环节的连接速度很快，所以堆积的连接就很少。假如nginx对app服务器之间的带宽出了问题或是app服务器有问题，那么可能使连接堆积起来，这时可以通过设定nginx的代理超时时间，来使连接尽快释放掉，一般来说极少能用到28232个连接。
　　因为有软件使用了40000端口监听，常常出错的话，可以通过设定ip_local_port_range的最小值来解决：
　　echo "40001 61000" > /proc/sys/net/ipv4/ip_local_port_range
　　但是这么做很显然把系统可用端口数减少了，这时可以把ip_local_port_range的最大值往上调，但是好习惯是使用不超过32768的端口来侦听服务，另外也不必要去修改ip_local_port_range数值成1024 65535之类的，意义不大。
　　因为使用了nginx代理，在windows下也会造成大量TIME_WAIT，当然windows也可以调整：
　　在注册表（regedit）的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，值就是秒数，即可。
　　windows默认是重用TIME_WAIT，我现在还不知道怎么改成不重用的，本地端口也没查到是什么值，但这些都关系不大，都可以按系统默认运作。