pache服務器的fin_wait1過多time_wait過多問題解決
1、fin_wait1狀態過多。fin_wait1狀態是在server端主動要求關閉tcp連接，並且主動發送fin以後，等待client端回覆ack時候的狀態。fin_wait1的產生原因有很多，需要結合netstat的狀態來分析。
上面的命令可以幫助分析哪種tcp狀態數量異常
則可以幫助你將請求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分鐘：
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_recycle = 1
使內核參數生效：
[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的值
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，我現在還不知道怎麼改成不重用的，本地端口也沒查到是什麼值，但這些都關係不大，都可以按系統默認運作。
要想在Linux系統下查看Apache的負載情況，最簡單有效的方法就是查看 Apache Server Status，在沒有開啓Apache Server Status的情況下，或安裝的是其他的Web Server，比如Nginx的時候，可以使用下面的命令查看。
#ps -ef|grep httpd|wc -l
1388
統計httpd進程數，這個請求會啓動一個進程，使用於Apache服務器。
表示Apache能夠處理1388個併發請求，這個值Apache可根據負載情況自動調整，我這組服務器中每臺的峯值曾達到過2002。
#netstat -nat|grep -i "80"|wc -l
4342
netstat -an會打印系統當前網絡鏈接狀態，而grep -i “80″是用來提取與80端口有關的連接的, wc -l進行連接數統計。
最終返回的數字就是當前所有80端口的請求總數。#netstat -na|grep ESTABLISHED|wc -l
376
netstat -an會打印系統當前網絡鏈接狀態，而grep ESTABLISHED 提取出已建立連接的信息。 然後wc -l統計。
最終返回的數字就是當前所有80端口的已建立連接的總數。
#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
FIN_WAIT_1 286
FIN_WAIT_2 960
SYN_SENT 3
LAST_ACK 32
CLOSING 1
CLOSED 36
SYN_RCVD 144
TIME_WAIT 2520
ESTABLISHED 352
這條語句是在張宴那邊看到，據說是從新浪互動社區事業部技術總監王老大那兒獲得的，非常不錯。返回參數的說明如下：
SYN_RECV表示正在等待處理的請求數；
ESTABLISHED表示正常數據傳輸狀態；
TIME_WAIT表示處理完畢，等待超時結束的請求數。