1. 程式人生 > >高併發TCP連線數目問題

高併發TCP連線數目問題

linux可通過五元組唯一確定一個連結:源IP,源埠,目的IP,目的埠,傳輸層協議。而一個埠不允許被兩個及以上程序佔用(一個程序可同時佔用多個埠),據此是否可以推測一臺linux伺服器最多可以同時處理2^16(65536,或65K)個連結即併發請求呢?

一臺伺服器到底能夠支援多少TCP併發連線呢?

1. 檔案描述符限制

對於伺服器來說,每一個TCP連線都要佔用一個檔案描述符,一旦檔案描述符使用完,新的連線到來返回給我們的錯誤是"Socket/File:Can't open so many files"。

這時,你需要明白作業系統可以開啟最大檔案數的限制。

1)程序限制(使用者限制)

執行 ulimit -n 輸出1024,說明對於一個程序而言最多隻能開啟1024個檔案,所以你要採用此預設配置最多也就可以併發上千個TCP連線。

臨時修改:ulimit -n 1000000,但是這種臨時修改只對當前登入的使用者目前使用的環境有效,系統重啟或使用者退出會就失效。

永久生效:修改/etc/security/limits.conf 檔案:

                *    soft    nofile    1000000

                *    hard    nofile    1000000

            ulimit -SHn 1000000 >> /etc/rc.local

2)全侷限制

執行 cat /proc/sys/fs/file-nr

1216    0    187612

>1216:已經分配的檔案描述符數

>0:已經分配但沒有使用的檔案描述符數,這裡的意思是核心分配了1216,然後1216個都用光了,所以“分配了但沒有使用的控制代碼數目”為 0 。

>187612:最大檔案控制代碼數

注意:在kernel2.6 版本中第二項的值總為0,這並不是一個錯誤,它實際上意味著已經分配的檔案描述符無一浪費的都已經被使用。可以通過在/etc/sysctl.conf裡定義fs.file-max = 1000000 來調整最後一個值的大小。

2.  埠號範圍限制

作業系統上埠號1024以下是系統保留的,從1024-65535是使用者使用的,由於每個tcp連線都要佔用一個埠號,所以我們最多可以使用60000多個併發連線,這是對客戶端的理解。

分析一下:

1) 如何標識一個TCP連線? 系統用一個4元組來標識一個TCP連線:(local ip,local port,remote ip,remote port) 。對於accept來說,accept的sock不佔新的埠,而我們作為伺服器實際只是使用了bind這一個埠。

說明埠65535並不是併發量的限制。

2) server最大tcp連線數:server通常固定在某一個本地埠上監聽,等待client的連線請求。不考慮地址重用的情況下,即使多個ip,本地監聽埠也是獨佔的。因此server端tcp連線4元組中只有remote ip 和 remote port 是可變的,因此最大tcp連線數為客戶端ip數 * 客戶端port數。 對於ipv4,不考慮ip地址等因素,最大tcp連線約為2的32次方(ip數) * 2的16次方(port數)。

也就是server端:單機最大tcp連線數約為:2的48次方。

附加問題:

問題1:檢視檔案描述符使用 lsof檢視到的控制代碼數和/proc/sys/fs/file-nr 值不一樣,為什麼?

        [[email protected] ~]# lsof | wc -l

        710

        [[email protected] ~]# cat /proc/sys/fs/file-nr

        416    0    1000000

答案:一個檔案可以被多個程序開啟,lsof所列出來的是每個程序所開啟的檔案,所以lsof的數值比file-nr要大很正常。

問題2:關於檔案控制代碼到底設定多大合適?

檢視控制代碼數的方法:

        [[email protected] ~]# cat /proc/sys/fs/file-nr

        832    0    97321       

        [[email protected] ~]# cat /proc/sys/fs/file-max

        97321       

預設最大控制代碼數為97321。

這個值在kernel的文件裡意思是file-max一般為記憶體大小(KB)的10%來計算,如果使用shell,可以這樣計算:

grep -r MemTotal /proc/meminfo | awk '{printf("%d",$2/10)}' 

計算出來的值一般和預設最大控制代碼數近似。

echo "fs.file-max = 100133" >> /etc/sysctl.conf && sysctl -p

解決高併發socket最大連線數所受的各種限制(解除IO限制)

1.  修改使用者程序可開啟檔案數限制

修改Linux對當前使用者的程序同時開啟的檔案數量的軟限制(soft limit)和硬限制(hardlimit)。軟限制是指Linux在當前系統能夠承受的範圍內進一步限制使用者同時開啟的檔案數;硬限制則是根據系統硬體資源狀況(主要是系統記憶體)計算出來的系統最多可同時開啟的檔案數量。通常軟限制小於或等於硬限制。

第一步,修改/etc/security/limits.conf檔案,在檔案中新增如下行:

speng soft nofile 10240

speng hard nofile 10240

其中speng指定了要修改哪個使用者的開啟檔案數限制,可用’*'號表示修改所有使用者的限制;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檔案中讀取配置來設定這些限制值。修改完後儲存此檔案。

第三步,檢視Linux系統級的最大開啟檔案數限制,使用如下命令:

$ cat /proc/sys/fs/file-max

12158

這表明這臺Linux系統最多允許同時開啟(即包含所有使用者開啟檔案數總和)12158個檔案,是Linux系統級硬限制,所有使用者級的開啟檔案數限制都不應超過這個數值。通常這個系統級硬限制是Linux系統在啟動時根據系統硬體資源狀況計算出來的最佳的最大同時開啟檔案數限制,如果沒有特殊需要,不應該修改此限制,除非想為使用者級開啟檔案數限制設定超過此限制的值。修改此硬限制的方法是修改/etc/rc.local指令碼,在指令碼中新增如下行:

echo 22158 > /proc/sys/fs/file-max

這是讓Linux在啟動完成後強行將系統級開啟檔案數硬限制設定為22158。修改完後儲存此檔案。

完成上述步驟後重啟系統,一般情況下就可以將Linux系統對指定使用者的單一程序允許同時開啟的最大檔案數限制設為指定的數值。如果重啟後用 ulimit-n命令檢視使用者可開啟檔案數限制仍然低於上述步驟中設定的最大值,這可能是因為在使用者登入指令碼/etc/profile中使用ulimit -n命令已經將使用者可同時開啟的檔案數做了限制。由於通過ulimit-n修改系統對使用者可同時開啟檔案的最大數限制時,新修改的值只能小於或等於上次 ulimit-n設定的值,因此想用此命令增大這個限制值是不可能的。所以,如果有上述問題存在,就只能去開啟/etc/profile指令碼檔案,在檔案中查詢是否使用了ulimit-n限制了使用者可同時開啟的最大檔案數量,如果找到,則刪除這行命令,或者將其設定的值改為合適的值,然後儲存檔案,使用者退出並重新登入系統即可。

通過上述步驟,就為支援高併發TCP連線處理的通訊處理程式解除關於開啟檔案數量方面的系統限制。

2.  修改網路核心對TCP連線的有關限制

在Linux上編寫支援高併發TCP連線的客戶端通訊處理程式時,有時會發現儘管已經解除了系統對使用者同時開啟檔案數的限制,但仍會出現併發TCP連線數增加到一定數量時,再也無法成功建立新的TCP連線的現象。出現這種現在的原因有多種。

第一種原因可能是因為Linux網路核心對本地埠號範圍有限制。此時,進一步分析為什麼無法建立TCP連線,會發現問題出在connect()呼叫返回失敗,檢視系統錯誤提示訊息是“Can’t assign requested address”。同時,如果在此時用tcpdump工具監視網路,會發現根本沒有TCP連線時客戶端發SYN包的網路流量。這些情況說明問題在於本地Linux系統核心中有限制。其實,問題的根本原因在於Linux核心的TCP/IP協議實現模組對系統中所有的客戶端TCP連線對應的本地埠號的範圍進行了限制(例如,核心限制本地埠號的範圍為1024~32768之間)。當系統中某一時刻同時存在太多的TCP客戶端連線時,由於每個TCP客戶端連線都要佔用一個唯一的本地埠號(此埠號在系統的本地埠號範圍限制中),如果現有的TCP客戶端連線已將所有的本地埠號佔滿,則此時就無法為新的TCP客戶端連線分配一個本地埠號了,因此係統會在這種情況下在connect()呼叫中返回失敗,並將錯誤提示訊息設為“Can’t assign requested address”。有關這些控制邏輯可以檢視Linux核心原始碼,以linux2.6核心為例,可以檢視tcp_ipv4.c檔案中如下函式:

static int tcp_v4_hash_connect(struct sock *sk)

請注意上述函式中對變數sysctl_local_port_range的訪問控制。變數sysctl_local_port_range的初始化則是在tcp.c檔案中的如下函式中設定:

void __init tcp_init(void)

核心編譯時預設設定的本地埠號範圍可能太小,因此需要修改此本地埠範圍限制。

第一步,修改/etc/sysctl.conf檔案,在檔案中新增如下行:

net.ipv4.ip_local_port_range = 1024 65000

這表明將系統對本地埠範圍限制設定為1024~65000之間。請注意,本地埠範圍的最小值必須大於或等於1024;而埠範圍的最大值則應小於或等於65535。修改完後儲存此檔案。

第二步,執行sysctl命令:

$ sysctl -p

如果系統沒有錯誤提示,就表明新的本地埠範圍設定成功。如果按上述埠範圍進行設定,則理論上單獨一個程序最多可以同時建立60000多個TCP客戶端連線。

第二種無法建立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

這表明將系統對最大跟蹤的TCP連線數限制設定為10240。請注意,此限制值要儘量小,以節省對核心記憶體的佔用。

第二步,執行sysctl命令:

$ sysctl -p

如果系統沒有錯誤提示,就表明系統對新的最大跟蹤的TCP連線數限制修改成功。如果按上述引數進行設定,則理論上單獨一個程序最多可以同時建立10000多個TCP客戶端連線。

3. 使用支援高併發網路I/O的程式設計技術

在Linux上編寫高併發TCP連線應用程式時,必須使用合適的網路I/O技術和I/O事件分派機制。

可用的I/O技術有同步I/O,非阻塞式同步I/O(也稱反應式I/O),以及非同步I/O。在高TCP併發的情形下,如果使用同步I/O,這會嚴重阻塞程式的運轉,除非為每個TCP連線的I/O建立一個執行緒。但是,過多的執行緒又會因系統對執行緒的排程造成巨大開銷。因此,在高TCP併發的情形下使用同步 I/O是不可取的,這時可以考慮使用非阻塞式同步I/O或非同步I/O。非阻塞式同步I/O的技術包括使用select(),poll(),epoll等機制。非同步I/O的技術就是使用AIO。

從I/O事件分派機制來看,使用select()是不合適的,因為它所支援的併發連線數有限(通常在1024個以內)。如果考慮效能,poll()也是不合適的,儘管它可以支援的較高的TCP併發數,但是由於其採用“輪詢”機制,當併發數較高時,其執行效率相當低,並可能存在I/O事件分派不均,導致部分TCP連線上的I/O出現“飢餓”現象。而如果使用epoll或AIO,則沒有上述問題(早期Linux核心的AIO技術實現是通過在核心中為每個 I/O請求建立一個執行緒來實現的,這種實現機制在高併發TCP連線的情形下使用其實也有嚴重的效能問題。但在最新的Linux核心中,AIO的實現已經得到改進)。

綜上所述,在開發支援高併發TCP連線的Linux應用程式時,應儘量使用epoll或AIO技術來實現併發的TCP連線上的I/O控制,這將為提升程式對高併發TCP連線的支援提供有效的I/O保證。

4. 核心引數sysctl.conf的優化

/etc/sysctl.conf 是用來控制linux網路的配置檔案,對於依賴網路的程式(如web伺服器和cache伺服器)非常重要,RHEL預設提供的最好調整。

推薦配置(把原/etc/sysctl.conf內容清掉,把下面內容複製進去):

net.ipv4.ip_local_port_range = 1024 65536

net.core.rmem_max=16777216

net.core.wmem_max=16777216

net.ipv4.tcp_rmem=4096 87380 16777216

net.ipv4.tcp_wmem=4096 65536 16777216

net.ipv4.tcp_fin_timeout = 10

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_window_scaling = 0

net.ipv4.tcp_sack = 0

net.core.netdev_max_backlog = 30000

net.ipv4.tcp_no_metrics_save=1

net.core.somaxconn = 262144

net.ipv4.tcp_syncookies = 0

net.ipv4.tcp_max_orphans = 262144

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_synack_retries = 2

net.ipv4.tcp_syn_retries = 2

這個配置參考於cache伺服器varnish的推薦配置和SunOne 伺服器系統優化的推薦配置。varnish調優推薦配置的地址為:http://varnish.projects.linpro.no/wiki/Performance

不過varnish推薦的配置是有問題的,實際執行表明“net.ipv4.tcp_fin_timeout = 3”的配置會導致頁面經常打不開;並且當網友使用的是IE6瀏覽器時,訪問網站一段時間後,所有網頁都會打不開,重啟瀏覽器後正常。可能是國外的網速快吧,我們國情決定需要調整“net.ipv4.tcp_fin_timeout = 10”,在10s的情況下,一切正常(實際執行結論)。

修改完畢後,執行:

/sbin/sysctl -p /etc/sysctl.conf

/sbin/sysctl -w net.ipv4.route.flush=1

5. 調整檔案數

linux系統優化完網路必須調高系統允許開啟的檔案數才能支援大的併發,預設1024是遠遠不夠的。

執行命令:

echo ulimit -HSn 65536 >> /etc/rc.local

echo ulimit -HSn 65536 >>/root/.bash_profile

ulimit -HSn 65536

 

參考:

  1. linux單臺伺服器上併發TCP連結數
  2. Linux下解決高併發socket最大連線數所受的各種限制(解除IO限制)
  3. Linux下高併發socket最大連線數所受的各種限制
  4. Linux下檢視併發連線數