Linux下突破限制實現高並發量伺服器

來源:互聯網
上載者:User

本文轉自:http://hi.baidu.com/fdwm_lx/blog/item/0c3cdb383f132acfd5622507.html

2010-07-02 17:41

 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 <file_num>
上述命令中,在<file_num>中指定要設定的單一進程允許開啟的最大檔案數。如果系統回顯類似於“Operation notpermitted”之類的話,說明上述限制修改失敗,實際上是因為在<file_num>中指定的數值超過了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保證。

Date: 2007-01-31
OS: Red Hat Enterprise Linux AS release 4 (kernel version 2.6.9-5.EL)

五種I/O 模式
----------------------------------------
在Linux/UNIX 下,有下面這五種I/O 操作方式:
阻塞I/O
非阻塞I/O
I/O 多工
訊號驅動I/O(SIGIO)
非同步I/O

程式進行輸入操作有兩步:
等待有資料可以讀
將資料從系統核心中拷貝到程式的資料區。

對於一個對通訊端的輸入操作:
第一步一般來說是,等待資料從網路上傳到本地,當資料包到達的時候,資料將會從網路層拷貝到核心的緩衝中;
第二步是從核心中把資料拷貝到程式的資料區中

.阻塞I/O 模式
簡單的說,阻塞就是"睡眠"的同義字
如你運行上面的listener 的時候,它只不過是簡單的在那裡等待接收資料。它調用recvfrom()函數,但是那個時候(listener 調用recvfrom()函數的時候),它並沒有資料可以接收.所以recvfrom()函數阻塞在那裡(也就是程式停在recvfrom()函數處睡大 覺)直到有資料傳過來阻塞.你應該明白它的意思。

阻塞I/O 模式是最普遍使用的I/O 模式。大部分程式使用的都是阻塞模式的I/O 。
預設的,一個通訊端建立後所處於的模式就是阻塞I/O 模式。

對於一個UDP 通訊端來說,資料就緒的標誌比較簡單:
已經收到了一整個資料報
沒有收到。

而TCP 這個概念就比較複雜,需要附加一些其他的變數
一個進程調用recvfrom ,然後系統調用並不返回知道有資料報到達本地系統,然後系統將資料拷貝到進程的緩衝中。
(如果系統調用收到一個中斷訊號,則它的調用會被中斷)我們稱這個進程在調用recvfrom 一直到從recvfrom 返回這段時間是阻塞的。
當recvfrom正常返回時,我們的進程繼續它的操作。

.非阻塞模式I/O
當我們將一個通訊端設定為非阻塞模式,我們相當於告訴了系統核心:“當我請求的I/O 操作不能夠馬上完成,你想讓我的進程進行休眠等待的時候,不要這麼做,請馬上返回一個錯誤給我。”

如我們開始對recvfrom 的三次調用,因為系統還沒有接收到網路資料,所以核心馬上返回一個EWOULDBLOCK的錯誤。
第四次我們調用recvfrom 函數,一個資料報已經到達了,核心將它拷貝到我們的應用程式的緩衝區中,然後recvfrom 正常返回,我們就可以對接收到的資料進行處理了。

當一個應用程式使用了非阻塞模式的通訊端,它需要使用一個迴圈來不聽的測試是否一個檔案描述符有資料可讀(稱做polling)。
應用程式不停的polling 核心來檢查是否I/O操作已經就緒。這將是一個極浪費CPU 資源的操作。這種模式使用中不是很普遍

.I/O 多工 select()
在使用I/O 多路技術的時候,我們調用select()函數和poll()函數,在調用它們的時候阻塞,而不是我們來調用recvfrom(或recv)的時候阻塞。
當我們調用select 函數阻塞的時候,select 函數等待資料通訊端進入讀就緒狀態。當select 函數返回的時候,也就是通訊端可以讀取資料的時候。這時候我們就可以調用recvfrom函數來將資料拷貝到我們的程式緩衝區中。
和阻塞模式相比較,select()和poll()並沒有什麼進階的地方,而且,在阻塞模式下只需要調用一個函數:讀取或發送,在使用了多工技術後, 我們需要調用兩個函數了:先調用select()函數或poll()函數,然後才能進行真正的讀寫。

多工進階之處在於,它能同時等待多個檔案描述符,而這些檔案描述符(通訊端描述符)其中的任意一個進入讀就緒狀態,select()函數就可以返回

假設我們運行一個網路用戶端程式,要同時處理通訊端傳來的網路資料又要處理本地的標準輸入輸出。在我們的程式處於阻塞狀態等待標準輸入的資料的時候,假如 伺服器端的程式被kill(或是自己Down 掉了),那麼伺服器程端的TCP 協議會給用戶端(我們這端)的TCP 協議發送一個FIN 資料代表終止串連。但是我們的程式阻塞在等待標準輸入的資料上,在它讀取通訊端資料之前(也許是很長一段時間),它不會看見結束標誌.我們就不能夠使用阻 塞模式的通訊端。

I/O多路技術一般在下面這些情況中被使用:
當一個用戶端需要同時處理多個檔案描述符的輸入輸出操作的時候(一般來說是標準的輸入輸出和網路通訊端), I/O 多工技術將會有機會得到使用。
當程式需要同時進行多個通訊端的操作的時候。
如果一個TCP 伺服器程式同時處理正在偵聽網路連接的通訊端和已經串連好的通訊端。
如果一個伺服器程式同時使用TCP 和UDP 協議。
如果一個伺服器同時使用多種服務並且每種服務可能使用不同的協議(比如inetd就是這樣的)。

I/O 多路服用技術並不只局限與網路程式應用上。幾乎所有的程式都可以找到應用I/O多工地方。

 

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.