Linux配置支援高併發TCP連線(socket最大連線數)
Linux配置支援高併發TCP連線(socket最大連線數)及優化核心引數
2011-08-09 15:20:58| 分類：LNMP&&LAMP| 標籤：核心調優 檔案系統調優 高併發調優 socket連線 ip_conntract |字號大中小 訂閱
Linux配置支援高併發TCP連線(socket最大連線數)
1、修改使用者程式可開啟檔案數限制在 Linux平臺上，無論編寫客戶端程式還是服務端程式，在進行高併發TCP連線處理時，最高的併發數量都要受到系統對使用者單一程式同時可開啟檔案數量的限制(這是因為系統為每個TCP連線都要建立一個socket控制程式碼，每個socket控制程式碼同時也是一個檔案控制程式碼)。可使用ulimit命令檢視系統允許當前使用者程式開啟的檔案數限制：
[speng@as4 ~]$ ulimit -n
1024
這表示當前使用者的每個程式最多允許同時開啟1024個檔案，這1024個檔案中還得除去每個程式必然開啟的標準輸入，標準輸出，標準錯誤，伺服器監聽 socket，程式間通訊的unix域socket等檔案，那麼剩下的可用於客戶端socket連線的檔案數就只有大概1024-10=1014個左右。也就是說預設情況下，基於Linux的通訊程式最多允許同時1014個TCP併發連線。
對於想支援更高數量的TCP併發連線的通訊處理程式，就必須修改Linux對當前使用者的程式同時開啟的檔案數量的軟限制(soft limit)和硬限制(hardlimit)。其中軟限制是指Linux在當前系統能夠承受的範圍內進一步限制使用者同時開啟的檔案數；硬限制則是根據系統硬體資源狀況(主要是系統記憶體)計算出來的系統最多可同時開啟的檔案數量。通常軟限制小於或等於硬限制。
修改上述限制的最簡單的辦法就是使用ulimit命令：
[speng@as4 ~]$ ulimit -n
上述命令中，在中指定要設定的單一程式允許開啟的最大檔案數。如果系統回顯類似於“Operation notpermitted”之類的話，說明上述限制修改失敗，實際上是因為在中指定的數值超過了Linux系統對該使用者開啟檔案數的軟限制或硬限制。因此，就需要修改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系統級的最大開啟檔案數限制，使用如下命令：
[speng@as4 ~]$ 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命令：
[speng@as4 ~]$ 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命令：
[speng@as4 ~]$ 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保證。