現象： 伺服器產生大量SYN_RECV連接,而系統默認SYN_RECV為1024,如果系統當前的syn_recv達到系統默認值,Nginx會不處理新來的連接,導致影響業務. 分析： 目前是使用f5的layer4模式轉發請求,故所有tcp連接的處理都在伺服器端完成,有可能是網路質量不好而導致產生大量的syn_recv,使用netstat命令查看TOP 10 syn_recv ip,發現都是移動網關過來的,初步判斷可能是移動網路慢對方無法接受伺服器返回的包而產生syn_recv,尤其是如下ip比較明顯：211.139.92.11（甘肅省蘭州市移動）. 解決方法： 1.F5改為standard方式,所有tcp連接由F5處理,後端只關注業務,故障解決,但加大F5的性能負荷. 2.伺服器修改內核,使其能容納更多的syn_recv,加大網路連接; 修改內核參數如下： 1）net.ipv4.tcp_max_syn_backlog = 65536 該參數是SYN隊列的長度,默認為1024,修改為65536,加大SYN隊列長度可以容納更多等待連接的網路連接數 2）net.core.netdev_max_backlog = 32768 該參數決定了,網路設備接收數據包的速率比內核處理這些包的速率快時,允許送到隊列的數據包的最大數目,默認值為300.根據需要調整改值,不要設置的過大.
3）net.core.somaxconn = 32768 該參數用來限制監聽隊列最大數據包的數量,超過這個數量就會導致鏈接超時或者觸發重傳機制.也就是說,web應用中listen 函數的backlog會給我們內核參數的net.core.somaxconn 限制到128,在高突發的請求中可能會導致鏈接超時或者觸發重傳；例如：nginx的默認的backlog隊列為511,如果內核參數net.core.somaxconn的值低於511,那麼nginx的backlog隊列將被限制為該參數的值.此外,可以在nginx的配置中增加監聽隊列的數量,當然前提是不能超過net.core.somaxconn的值. server {
listen 80 deafult backlog=8192;
server_name http://www.libertyvps.com]www.libertyvps.com;
}
4）net.ipv4.tcp_syncookies = 1 該參數是一個開關,是否打開SYN Cookie功能,該功能可以防止部分SYN攻擊,默認為0關閉,1開啟. 注意：該選項千萬不能用於那些沒有收到攻擊的高負載伺服器,如果在日誌中出現synflood消息,但是調查發現沒有收到synflood攻擊,而是合法用戶的連接負載過高的原因,你應該調整其它參數來提高伺服器性能.參考:
5）net.ipv4.tcp_synack_retries = 0 默認值是5,對於遠端的連接請求SYN,內核會發送SYN ＋ ACK數據報,以確認收到上一個 SYN連接請求包.這是所謂的三次握手( threeway handshake)機制的第二個步驟.這裡決定內核在放棄連接之前所送出的 SYN ACK 數目.不應該大於 255,默認值是5,對應於180秒左右時間.(可以根據下面的 tcp_syn_retries 來決定這個值) 6）net.ipv4.tcp_syn_retries = 0 默認值是5,對於一個新建連接,內核要發送多少個 SYN 連接請求才決定放棄.不應該大於255,默認值是5,對應於180秒左右時間.(對於大負載而物理通信良好的網路而言,這個值偏高,可修改為2.這個值僅僅是針對對外的連接,對進來的連接,是由tcp_retries1 決定的) 註：5）6）這2項可根據業務的特性靈活調整,我這裡設置為0,對業務本身沒有很大的影響,查看連接及日誌沒有減少的變化. 7）由於我們的業務是移動互聯網業務,根據其特殊性,如修改了如下2個參數,會對業務有一定影響,請不要調整,保持默認即可. net.ipv4.tcp_rw_reuse = 0 net.ipv4.tcp_rw_recycle = 0 通過查看伺服器,有大量的TIME_WAIT連接,而很多是出現在nginx php-cgi的ip轉發連接方式,建議可調整為通過unix socket方式訪問,減少不必要的網路消耗. 經過以上調整,伺服器在容納更多的SYN_RECV亦保證nginx能正常提供web訪問,查看系統負載,保持在1以下. 本文出自 「UC滄月」 博客,請務必保留此出處http://kc1985.blog.51cto.com/2407758/771976
