linux下高并發網絡應用注意事項
vi /etc/sysctl.conf,加入以下內容:
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=30 #修改系統默認的TIMEWAIT時間
net.ipv4.tcp_max_tw_buckets=3000 #限制TIMEWAIT的數量
net.ipv4.tcp_timestamps=1 #啟用TCP的時間戳選項
net.ipv4.ip_local_port_range=1024 65000 #這表明將系統對本地端口范圍限制設置為1024~65000之間。請注意,本地端口范圍的最小值必須大于或等于1024;而端口范圍的最大值則應小于或等 于65535
然后執行 /sbin/sysctl -p 讓參數生效。
實驗的結論:
1.主動連接情況下,TIME_WAIT對性能的影響很大
2.net.ipv4.tcp_tw_reuse和tcp_tw_recycle都設置為0時,在本地端口耗盡后負載會很高
3.net.ipv4.tcp_tw_reuse=1和net.ipv4.tcp_tw_recycle=1 配置生效的前提條件是:TCP連接的兩端都要啟用TCP的時間戳選項, net.ipv4.tcp_timestamps=1。
4.net.ipv4.tcp_tw_reuse設置為1后,會降低本地端口耗盡出現的概率,從而降低負載
5.net.ipv4.tcp_tw_recycle設置為1后,會加速TIME_WAIT的回收,從而顯著降低系統中TIME_WAIT狀態的socket數量
6.對于主動連接較多的服務器建議通過調整sysctl的net.ipv4.ip_local_port_range來增大本地端口范圍,以進一步降低端口耗盡出現的概率
除此之外,對于高并發的網絡應用,還應注意以下一些點:
1。ulimit -n #看一下一個進程可以打開的文件句柄數目,如果要修改系統默認的hard nofile閾值,需要按照以下步驟進行:
第一步,修改/etc/security/limits.conf文件,在文件中添加如下行:
admin soft nofile 10240
admin hard nofile 10240
其中admin指定了要修改哪個用戶的打開文件數限制,可用'*'號表示修改所有用戶的限制;soft或hard指定要修改軟限制還是硬限制;10240 則指定了想要修改的新的限制值,即最大打開文件數(請注意軟限制值要小于或等于硬限制)。修改完后保存文件。
第二步,修改/etc/pam.d/login文件,在文件中添加如下行:
session required /lib/security/pam_limits.so
這是告訴Linux在用戶完成系統登錄后,應該調用pam_limits.so模塊來設置系統對該用戶可使用的各種資源數量的最大限制(包括用戶可打開的 最大文件數限制),而pam_limits.so模塊就會從/etc/security/limits.conf文件中讀取配置來設置這些限制值。修改完 后保存此文件。
2。cat /proc/sys/fs/file-max #這表明這臺Linux系統最多允許同時打開(即包含所有用戶打開文件數總和)XXXX個文件,是Linux系統級硬限制,不夠時將其調大
3。還有一種無法建立TCP連接的原因可能是因為Linux網絡內核的IP_TABLE防火墻對最大跟蹤的TCP連接數有限制。此時程序會表現為在 connect()調用中阻塞,如同死機,如果用tcpdump工具監視網絡,也會發現根本沒有TCP連接時客戶端發SYN包的網絡流量。由于 IP_TABLE防火墻在內核中會對每個TCP連接的狀態進行跟蹤,跟蹤信息將會放在位于內核內存中的conntrackdatabase中,這個數據庫 的大小有限,當系統中存在過多的TCP連接時,數據庫容量不足,IP_TABLE無法為新的TCP連接建立跟蹤信息,于是表現為在connect()調用 中阻塞。此時就必須修改內核對最大跟蹤的TCP連接數的限制,方法同修改內核對本地端口號范圍的限制是類似的:在/etc/sysctl.conf中添加net.ipv4.ip_conntrack_max=10240
參考文章:
http://hi.baidu.com/zzxap/blog/item/ab3f2aedbe6c3b5978f05587.html《Linux下突破限制實現高并發量服務器》
http://kerry.blog.51cto.com/172631/105233/《發現大量的TIME_WAIT解決辦法》
http://wenku.baidu.com/view/dd18767c1711cc7931b71616.html《操作系統性能優化<1> Linux下TIME_WAIT對系統性能的影響》
http://blog.csdn.net/kasagawa/article/details/6978890《TCP協議學習筆記》
今天又遇到了CLOSE_WAIT的情況,google了一番,又對TIME_WAIT和CLOSE_WAIT的理解深了一層,參考的幾篇文章如下:
http://www.360doc.com/content/10/0414/16/1484_23029426.shtml
http://pengtyao.iteye.com/blog/829513
http://shootyou.iteye.com/blog/1129507
http://blog.csdn.net/shootyou/article/details/6615051
http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html
大致說一下我的一些新的理解:
TCP建立連接需要3次握手(就是發3個包),而終止連接需要發4個包(兩次FIN,兩次ACK),在終止的時候,調用close會觸發發送FIN包,通常我們說客戶端和服務器,但這都是相對而言的,更準確的說法是“主動關閉方”和“被動關閉方”,主動關閉方會出現TIME_WAIT(出現在對方也調用了close之后,在對方調用close之前是FIN_WAIT2狀態),被動關閉方會出現CLOSE_WAIT(出現在收到對方關閉請求但自己又沒有調用close之前);主動關閉方的TIME_WAIT的等待是正常的,tcp/ip協議就是這么設計的,可以通過調整機器的內核參數來控制,被動關閉方的CLOSE_WAIT的等待是應用程序自己造成的,和系統沒有關系,通常是被動關閉方沒有調用close導致的;TIME_WAIT出現后,需要等待2個MSL時間才會釋放socket,CLOSE_WAIT出現后需要等待一個keepalive的時間,關于keepalive的控制主要有3個參數:net.ipv4.tcp_keepalive_intvl(每次探測間隔)、net.ipv4.tcp_keepalive_probes(探測次數)、net.ipv4.tcp_keepalive_time(TCP鏈路上空閑多長時間開始發送keep_alive),tcp_keepalive_time默認為2小時,因此CLOSE_WAIT后最多有可能需要等待tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes;此外,不論是主動方還是被動方,只要程序退出(因為程序退出會關閉所有打開的fd),則相當于調用了close函數,那么對于被動方而言CLOSE_WAIT都會消失,對于主動方而言,退出前保持的FIN_WAIT2或TIME_WAIT狀態繼續保留;如果雙方都主動退出程序,那么誰先退出就相當于是優先調用了close的主動方。
https://www.byvoid.com/blog/http-keep-alive-header
posted on 2012-06-11 15:35 so true 閱讀(2018) 評論(0) 編輯 收藏 所屬分類: C&C++