修正Linux系統的默認連接數ITeye - AG环亚娱乐

修正Linux系統的默認連接數ITeye

2019年02月21日08时07分32秒 | 作者: 若松 | 标签: 修正,约束,文件 | 浏览: 2865

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()調用回来失敗,检查系統錯誤提示音讯是"Cant assign requestedaddress"。同時,假如在此時用tcpdump东西監視網絡,會發現底子沒有TCP連接時客戶端發SYN包的網絡流量。這些情況說明問題在於本地Linux系統內核中有约束。其實,問題的底子原因在於Linux內核的TCP/IP協議實現模塊對系統中一切的客戶端TCP連接對應的本地端口號的範圍進行了约束(例如,內核限製本地端口號的範圍為1024~32768之間)。當系統中某一時刻同時存在太多的TCP客戶端連接時,由於每個TCP客戶端連接都要佔用一個仅有的本地端口號(此端口號在系統的本地端口號範圍约束中),假如現有的TCP客戶端連接已將一切的本地端口號佔滿,則此時就無法為新的TCP客戶端連接分配一個本地端口號了,因而系統會在這種情況下在connect()調用中回来失敗,並將錯誤提示音讯設為"Cant 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客戶端連接。

*******留意*******

sysctl -p 報錯net.ipv4.ip_conntrack_max" is an unknown key 則:modprobe ip_conntrack

版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表AG环亚娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章