1)統計80端口連接數
2)統計stat -an會打印系統當前網絡鏈接狀態,而grep -i "80"是用來提取與80端口有關的連接的,wc -l進行連接數統計。
最終返回的數字就是當前所有80端口的請求總數。
netstat -an會打印系統當前網絡鏈接狀態,而grep ESTABLISHED 提取出已建立連接的信息。 然後wc -l統計。
最終返回的數字就是當前所有80端口的已建立連接的總數。
查看Apache的並發請求數及其TCP連接狀態:
TIME_WAIT 8947 等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
FIN_WAIT1 15 等待遠程TCP連接中斷請求,或先前的連接中斷請求的確認
FIN_WAIT2 1 從遠程TCP等待連接中斷請求
ESTABLISHED 55 代表壹個打開的連接
SYN_RECV 21 再收到和發送壹個連接請求後等待對方對連接請求的確認
CLOSING 2 沒有任何連接狀態
LAST_ACK 4 等待原來的發向遠程TCP的連接中斷請求的確認
TCP連接狀態詳解
LISTEN: 偵聽來自遠方的TCP端口的連接請求
SYN-SENT: 再發送連接請求後等待匹配的連接請求
SYN-RECEIVED:再收到和發送壹個連接請求後等待對方對連接請求的確認
ESTABLISHED: 代表壹個打開的連接
FIN-WAIT-1: 等待遠程TCP連接中斷請求,或先前的連接中斷請求的確認
FIN-WAIT-2: 從遠程TCP等待連接中斷請求
CLOSE-WAIT: 等待從本地用戶發來的連接中斷請求
CLOSING: 等待遠程TCP對連接中斷的確認
LAST-ACK: 等待原來的發向遠程TCP的連接中斷請求的確認
TIME-WAIT: 等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED: 沒有任何連接狀態
LAST_ACK 5
SYN_RECV 30
ESTABLISHED 1597
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057
其中的
SYN_RECV表示正在等待處理的請求數;
ESTABLISHED表示正常數據傳輸狀態;
TIME_WAIT表示處理完畢,等待超時結束的請求數。
查看Apache並發請求數及其TCP連接狀態
查看.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然後執行 /sbin/sysctl -p 讓參數生效。
net.ipv4.tcp_syncookies = 1 表示開啟SYN cookies。當出現SYN等待隊列溢出時,啟用cookies來處理,可防範少量SYN攻擊,默認為0,表示關閉;
net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接,默認為0,表示關閉;
net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收,默認為0,表示關閉。
net.ipv4.tcp_fin_timeout 修改系統默認的 TIMEOUT 時間
客戶端與服務器端建立TCP/IP連接後關閉SOCKET後,服務器端連接的端口
狀態為TIME_WAIT
是不是所有執行主動關閉的socket都會進入TIME_WAIT狀態呢?
有沒有什麽情況使主動關閉的socket直接進入CLOSED狀態呢?
主動關閉的壹方在發送最後壹個 ack 後
就會進入 TIME_WAIT 狀態 停留2MSL(max segment lifetime)時間
這個是TCP/IP必不可少的,也就是“解決”不了的。
也就是TCP/IP設計者本來是這麽設計的
主要有兩個原因
1。防止上壹次連接中的包,迷路後重新出現,影響新連接
(經過2MSL,上壹次連接中所有的重復包都會消失)
2。可靠的關閉TCP連接
在主動關閉方發送的最後壹個 ack(fin) ,有可能丟失,這時被動方會重新發
fin, 如果這時主動方處於 CLOSED 狀態 ,就會響應 rst 而不是 ack。所以
主動方要處於 TIME_WAIT 狀態,而不能是 CLOSED 。
TIME_WAIT 並不會占用很大資源的,除非受到攻擊。
還有,如果壹方 send 或 recv 超時,就會直接進入 CLOSED 狀態
如何合理設置apache httpd的最大連接數?
手頭有壹個網站在線人數增多,訪問時很慢。初步認為是服務器資源不足了,但經反復測試,壹旦連接上,不斷點擊同壹個頁面上不同的鏈接,都能迅速打開,這種現象就是說明apache最大連接數已經滿了,新的訪客只能排隊等待有空閑的鏈接,而如果壹旦連接上,在keeyalive 的存活時間內(KeepAliveTimeout,默認5秒)都不用重新打開連接,因此解決的方法就是加大apache的最大連接數。
1.在哪裏設置?
apache 2.24,使用默認配置(FreeBSD 默認不加載自定義MPM配置),默認最大連接數是250
在/usr/local/etc/apache22/httpd.conf中加載MPM配置(去掉前面的註釋):
Include etc/apache22/extra/httpd-mpm.conf
可見的MPM配置在/usr/local/etc/apache22/extra/httpd-mpm.conf,但裏面根據httpd的工作模式分了很多塊,哪壹部才是當前httpd的工作模式呢?可通過執行 apachectl -l 來查看:
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
看到prefork 字眼,因此可見當前httpd應該是工作在prefork模式,prefork模式的默認配置是:
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
2.要加到多少?
連接數理論上當然是支持越大越好,但要在服務器的能力範圍內,這跟服務器的CPU、內存、帶寬等都有關系。
查看當前的連接數可以用:
ps aux | grep httpd | wc -l
或:
pgrep httpd|wc -l
計算httpd占用內存的平均數:
ps aux|grep -v grep|awk '/httpd/{sum+=$6;n++};END{print sum/n}'
由於基本都是靜態頁面,CPU消耗很低,每進程占用內存也不算多,大約200K。
服務器內存有2G,除去常規啟動的服務大約需要500M(保守估計),還剩1.5G可用,那麽理論上可以支持1.5 1024 1024*1024/200000 = 8053.06368
約8K個進程,支持2W人同時訪問應該是沒有問題的(能保證其中8K的人訪問很快,其他的可能需要等待1、2秒才能連上,而壹旦連上就會很流暢)
控制最大連接數的MaxClients ,因此可以嘗試配置為:
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 5500
MaxClients 5000
MaxRequestsPerChild 100
</IfModule>
註意,MaxClients默認最大為250,若要超過這個值就要顯式設置ServerLimit,且ServerLimit要放在MaxClients之前,值要不小於MaxClients,不然重啟httpd時會有提示。
重啟httpd後,通過反復執行pgrep httpd|wc -l 來觀察連接數,可以看到連接數在達到MaxClients的設值後不再增加,但此時訪問網站也很流暢,那就不用貪心再設置更高的值了,不然以後如果網站訪問突增不小心就會耗光服務器內存,可根據以後訪問壓力趨勢及內存的占用變化再逐漸調整,直到找到壹個最優的設置值。
(MaxRequestsPerChild不能設置為0,可能會因內存泄露導致服務器崩潰)
更佳最大值計算的公式:
apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5
附:
實時檢測HTTPD連接數:
watch -n 1 -d "pgrep httpd|wc -l"