1. 程式人生 > >伺服器最大TCP連線數及調優彙總 BIO,NIO,AIO的理解

伺服器最大TCP連線數及調優彙總 BIO,NIO,AIO的理解

啟動執行緒數:

啟動執行緒數=【任務執行時間/(任務執行時間-IO等待時間)】*CPU核心數

最佳啟動執行緒數和CPU核心數量成正比,和IO阻塞時間成反比。如果任務都是CPU計算型任務,那麼執行緒數最多不超過CPU核心數,因為啟動再多執行緒,CPU也來不及排程;相反如果是任務需要等待磁碟操作,網路響應,那麼多啟動執行緒有助於提高任務併發度,提高系統吞吐能力,改善系統性能。

單機最大tcp連線數

網路程式設計

在tcp應用中,server事先在某個固定埠監聽,client主動發起連線,經過三路握手後建立tcp連線。那麼對單機,其最大併發tcp連線數是多少?

如何標識一個TCP連線

在確定最大連線數之前,先來看看系統如何標識一個tcp連線。系統用一個4四元組來唯一標識一個TCP連線:{local ip, local port,remote ip,remote port}。

client最大tcp連線數

client每次發起tcp連線請求時,除非繫結埠,通常會讓系統選取一個空閒的本地埠(local port),該埠是獨佔的,不能和其他tcp連線共享。tcp埠的資料型別是unsigned short,因此本地埠個數最大隻有65536,埠0有特殊含義,不能使用,這樣可用埠最多隻有65535,所以在全部作為client端的情況下,最大tcp連線數為65535,這些連線可以連到不同的server ip。

server最大tcp連線數

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

實際的tcp連線數

上面給出的是理論上的單機最大連線數,在實際環境中,受到機器資源、作業系統等的限制,特別是sever端,其最大併發tcp連線數遠不能達到理論上限。在unix/linux下限制連線數的主要因素是記憶體和允許的檔案描述符個數(每個tcp連線都要佔用一定記憶體,每個socket就是一個檔案描述符),另外1024以下的埠通常為保留埠。在預設2.6核心配置下,經過試驗,每個socket佔用記憶體在15~20k之間

影響一個socket佔用記憶體的引數包括:

rmem_max

wmem_max

tcp_rmem

tcp_wmem

tcp_mem

grep skbuff /proc/slabinfo

對server端,通過增加記憶體、修改最大檔案描述符個數等引數,單機最大併發TCP連線數超過10萬 是沒問題的,國外 Urban Airship 公司在產品環境中已做到 50 萬併發 。在實際應用中,對大規模網路應用,還需要考慮C10K 問題。

原文:

http://wanshi.iteye.com/blog/1256282

http://www.cnblogs.com/Solstice/archive/2011/07/01/2095411.html

http://unix.stackexchange.com/questions/30509/what-is-the-formula-to-determine-how-much-memory-a-socket-consumes-under-linux

http://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-server

http://soft.chinabyte.com/os/285/12349285.shtml

 

曾幾何時我們還在尋求網路程式設計中C10K問題的解決方案,但是現在從硬體和作業系統支援來看單臺伺服器支援上萬併發連線已經沒有多少挑戰性了。

我們先假設單臺伺服器最多隻能支援萬級併發連線,其實對絕大多數應用來說已經遠遠足夠了,但是對於一些擁有很大使用者基數的網際網路公司,往往面臨的併發連線數是百萬,千萬,甚至騰訊的上億(注:QQ預設用的UDP協議)。雖然現在的叢集,分散式技術可以為我們將併發負載分擔在多臺伺服器上,那我們只需要擴展出數十臺電腦就可以解決問題,但是我們更希望能更大的挖掘單臺伺服器的資源,先努力垂直擴充套件,再進行水平擴充套件,這樣可以有效的節省伺服器相關的開支(硬體資源,機房,運維,電力其實也是一筆不小的開支)。

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


常識一:檔案控制代碼限制

在linux下編寫網路伺服器程式的朋友肯定都知道每一個tcp連線都要佔一個檔案描述符,一旦這個檔案描述符使用完了,新的連線到來返回給我們的錯誤是“Socket/File:Can't open so many files”

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

  • 程序限制

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

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

    • 重啟後失效的修改(不過我在CentOS 6.5下測試,重啟後未發現失效):編輯 /etc/security/limits.conf 檔案, 修改後內容為

      * soft nofile 1000000

      * hard nofile 1000000

    • 永久修改:編輯/etc/rc.local,在其後新增如下內容

      ulimit -SHn 1000000

  • 全侷限制

    • 執行 cat /proc/sys/fs/file-nr 輸出 9344 0 592026,分別為:1.已經分配的檔案控制代碼數,2.已經分配但沒有使用的檔案控制代碼數,3.最大檔案控制代碼數。但在kernel 2.6版本中第二項的值總為0,這並不是一個錯誤,它實際上意味著已經分配的檔案描述符無一浪費的都已經被使用了 。

    • 我們可以把這個數值改大些,用 root 許可權修改 /etc/sysctl.conf 檔案:

      fs.file-max = 1000000

      net.ipv4.ip_conntrack_max = 1000000

      net.ipv4.netfilter.ip_conntrack_max = 1000000

常識二:埠號範圍限制?

作業系統上埠號1024以下是系統保留的,從1024-65535是使用者使用的。由於每個TCP連線都要佔一個埠號,所以我們最多可以有60000多個併發連線。我想有這種錯誤思路朋友不在少數吧?(其中我過去就一直這麼認為)

我們來分析一下吧

  • 如何標識一個TCP連線:系統用一個4四元組來唯一標識一個TCP連線:{local ip, local port,remote ip,remote port}。好吧,我們拿出《UNIX網路程式設計:卷一》第四章中對accept的講解來看看概念性的東西,第二個引數cliaddr代表了客戶端的ip地址和埠號。而我們作為服務端實際只使用了bind時這一個埠,說明埠號65535並不是併發量的限制。

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

總結

TCP/IP 協議規定的,只用了2個位元組表示埠號。容易讓人誤解為1個server只允許連線65535個Client。

typedef struct _NETWORK_ADDRESS_IP
{
    USHORT      sin_port;//0~65535
    ULONG       in_addr;
    UCHAR       sin_zero[8];
} NETWORK_ADDRESS_IP, *PNETWORK_ADDRESS_IP;

(1)其實65535這個數字,只是決定了伺服器端最多可以擁有65535個Bind的Socket。也就是說,最多可以開65535個伺服器程序,但是你要知道這個能夠連線客戶端的數量沒有任何關係,Accept過來的Socket是不需要Bind任何IP地址的,也沒有端口占用這一說。作為Server端的Socket本身只負責監聽和接受連線操作。

(2)TCP協議裡面是用[源IP+源Port+目的IP+目的 Port]來區別兩個不同連線,所以連入和連出是兩個不同的概念。連出Connect就不錯了,需要生成隨機埠,這個是有限的連入的話, 因SOCKET的分配受記憶體分頁限制,而連線受限制(WINDOWS)。

(3)所以,千萬不要誤以為1個server只允許連線65535個Client。記住,TCP連出受埠限制,連入僅受記憶體限制

例如server,IP:192.168.16.254,Port:8009

Client1:IP:192.168.16.1,Port:2378

Client2:IP:192.168.16.2,Port:2378

Client1和Client2雖然Port相同,但是IP不同,所以是不同的連線。

(4)想讓1個server併發高效得連線幾萬個Client,需要使用IOCP“完成埠(Completion Port)”的技術。

詳情請參考文章:http://blog.csdn.net/libaineu2004/article/details/40087167

上面給出的結論都是理論上的單機TCP併發連線數,實際上單機併發連線數肯定要受硬體資源(記憶體)、網路資源(頻寬)的限制,至少對我們的需求現在可以做到數十萬級的併發了,你的呢?

這種單臺機器10w併發,不考慮記憶體cpu的實現,主要是程式網路模型的選擇。專案在Github上有提供https://github.com/yaocoder/HPNetServer

 

常見設定

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

在Linux平臺上,無論編寫客戶端程式還是服務端程式,在進行高併發TCP連線處理時,最高的併發數量都要受到系統對使用者單一程序同時可開啟檔案數量的限制(這是因為系統為每個TCP連線都要建立一個socket控制代碼,每個socket控制代碼同時也是一個檔案控制代碼)。可使用ulimit命令檢視系統允許當前使用者程序開啟的檔案數限制:

[[email protected] ~]$ ulimit -n
1024

這表示當前使用者的每個程序最多允許同時開啟1024個檔案,這1024個檔案中還得除去每個程序必然開啟的標準輸入,標準輸出,標準錯誤,伺服器監聽 socket,程序間通訊的unix域socket等檔案,那麼剩下的可用於客戶端socket連線的檔案數就只有大概1024-10=1014個左右。也就是說預設情況下,基於Linux的通訊程式最多允許同時1014個TCP併發連線。
對於想支援更高數量的TCP併發連線的通訊處理程式,就必須修改Linux對當前使用者的程序同時開啟的檔案數量的軟限制(soft limit)和硬限制(hardlimit)。其中軟限制是指Linux在當前系統能夠承受的範圍內進一步限制使用者同時開啟的檔案數;硬限制則是根據系統硬體資源狀況(主要是系統記憶體)計算出來的系統最多可同時開啟的檔案數量。通常軟限制小於或等於硬限制。
修改上述限制的最簡單的辦法就是使用ulimit命令:

[[email protected] ~]$ ulimit -n

上述命令中,在中指定要設定的單一程序允許開啟的最大檔案數。如果系統回顯類似於“Operation notpermitted”之類的話,說明上述限制修改失敗,實際上是因為在中指定的數值超過了Linux系統對該使用者開啟檔案數的軟限制或硬限制。因此,就需要修改Linux系統對使用者的關於開啟檔案數的軟限制和硬限制。
第一步,修改/etc/security/limits.conf檔案,在檔案中新增如下行:

複製程式碼
...
# End of file
speng soft nofile 10240
speng hard nofile 10240
root soft nofile 65535
root hard nofile 65535
* soft nofile 65535
* hard nofile 65535
[[email protected] config]$
複製程式碼

其中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系統級的最大開啟檔案數限制,使用如下命令:

[[email protected] ~]$ 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 requestedaddress”。同時,如果在此時用tcpdump工具監視網路,會發現根本沒有TCP連線時客戶端發SYN包的網路流量。這些情況說明問題在於本地Linux系統核心中有限制。其實,問題的根本原因在於Linux核心的TCP/IP協議實現模組對系統中所有的客戶端TCP連線對應的本地埠號的範圍進行了限制(例如,核心限制本地埠號的範圍為1024~32768之間)。當系統中某一時刻同時存在太多的TCP客戶端連線時,由於每個TCP客戶端連線都要佔用一個唯一的本地埠號(此埠號在系統的本地埠號範圍限制中),如果現有的TCP客戶端連線已將所有的本地埠號佔滿,則此時就無法為新的TCP客戶端連線分配一個本地埠號了,因此係統會在這種情況下在connect()呼叫中返回失敗,並將錯誤提示訊息設為“Can’t assignrequested 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命令:
[[email protected] ~]$ 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命令:
[[email protected] ~]$ sysctl -p
如果系統沒有錯誤提示,就表明系統對新的最大跟蹤的TCP連線數限制修改成功。如果按上述引數進行設定,則理論上單獨一個程序最多可以同時建立10000多個TCP客戶端連線。

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

在Linux上編寫高併發TCP連線應用程式時,必須使用合適的網路I/O技術和I/O事件分派機制。
可用的I/O技術有同步I/O,非阻塞式同步I/O(也稱反應式I/O),以及非同步I/O。《BIO,NIO,AIO的理解

在高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保證。

核心引數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

命令生效。為了保險起見,也可以reboot系統。

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

執行命令:
Shell程式碼
echo ulimit -HSn 65536 >> /etc/rc.local
echo ulimit -HSn 65536 >>/root/.bash_profile
ulimit -HSn 65536

 

 備註:
對mysql使用者可同時開啟檔案數設定為10240個;
將Linux系統可同時開啟檔案數設定為1000000個(一定要大於對使用者的同時開啟檔案數限制);
將Linux系統對最大追蹤的TCP連線數限制為20000個(但是,建議設定為10240;因為對mysql使用者的同時開啟檔案數已經限制在10240個;且較小的值可以節省記憶體);
將linux系統埠範圍配置為1024~30000(可以支援60000個以上連線,不建議修改;預設已經支援20000個以上連線);

綜合上述四點,TCP連線數限制在10140個。
這10240個檔案中還得除去每個程序必然開啟的標準輸入,標準輸出,標準錯誤,伺服器監聽 socket,程序間通訊的unix域socket等檔案。


因此,當需要對TCP連線數進行調整時只需要調整ulimit引數。

 

Linux下檢視tcp連線數及狀態命令:

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'