高併發情況下 Linux 系統及 kernel 參數優化

眾所周知在預設參數情況下Linux對高並發支援並不好，主要受限於單一進程最大開啟檔案數限制、內核TCP參數方面和IO事件分配機制等。 下面就從幾個方面來調整使Linux系統能夠支援高並發環境。

Iptables相關

如非必須，關掉或卸載iptables防火牆，並阻止kernel載入iptables模組。這些模組會影響並發性能。

單一進程最大開啟文件數限制

一般的發行版，限制單一進程最大可以開啟1024個文件，這是遠遠不能滿足高並發需求的，調整過程如下：在#號提示字元下敲入：

# ulimit–n 65535

將root啟動的單一進程的最大可以開啟的檔案數設定為65535個。如果系統回顯類似「Operation not permitted」之類的話，表示上述限制修改失敗，實際上是因為指定的數值超過了Linux系統對該使用者開啟檔案數的軟限製或硬限制。因此，就需要修改Linux系統對使用者的關於開啟檔案數的軟限制和硬限制。

第一步，修改limits.conf文件，並新增：

# vim /etc/security/limits.conf
* softnofile 65536
* hard nofile65536

其中'*'號表示修改所有使用者的限制；soft或hard指定要修改軟體限制還是硬限制； 65536則指定了想要修改的新的限制值，即最大開啟檔案數(請注意軟限制值要小於或等於硬限制)。修改完後儲存文件。第二步，修改/etc/pam.d/login文件，在文件中添加如下行：

# vim /etc/pam.d/login
sessionrequired /lib/security/pam_limits.so

這是告訴Linux在用戶完成系統登入後，應該調用pam_limits.so模組來設定係統對此使用者可使用的各種資源數量的最大限制(包括使用者可開啟的最大檔案數限制)，而pam_limits.so模組就會從/etc/security/limits.conf檔案中讀取設定來設定這些限制值。修改完後儲存此文件。

第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：

# cat/proc/sys/fs/file-max
32568

这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)32568个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/sysctl.conf文件内fs.file-max= 131072

这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为131072。修改完后保存此文件。

完成上述步骤后重启系统，一般情况下就可以将Linux系统对指定用户的单一进程允许同时打开的最大文件数限制设为指定的数值。如果重启后用ulimit-n命令查看用户可打开文件数限制仍然低于上述步骤中设置的最大值，这可能是因为在用户登录脚本/etc/profile中使用ulimit-n命令已经将用户可同时打开的文件数做了限制。

由于通过ulimit-n修改系统对用户可同时打开文件的最大数限制时，新修改的值只能小于或等于上次ulimit-n设置的值，因此想用此命令增大这个限制值是不可能的。所以，如果有上述问题存在，就只能去打开/etc/profile脚本文件，在文件中查找是否使用了ulimit-n限制了用户可同时打开的最大文件数量，如果找到，则删除这行命令，或者将其设置的值改为合适的值，然后保存文件，用户退出并重新登录系统即可。

通过上述步骤，就为支持高并发TCP连接处理的通讯处理程序解除关于打开文件数量方面的系统限制。

内核TCP参数方面

Linux系统下，TCP连接断开后，会以TIME_WAIT状态保留一定的时间，然后才会释放端口。当并发请求过多的时候，就会产生大量的TIME_WAIT状态的连接，无法及时断开的话，会占用大量的端口资源和服务器资源。这个时候我们可以优化TCP的内核参数，来及时将TIME_WAIT状态的端口清理掉。

下面介绍的方法只对拥有大量TIME_WAIT状态的连接导致系统资源消耗有效，如果不是这种情况下，效果可能不明显。可以使用netstat命令去查TIME_WAIT状态的连接状态，输入下面的组合命令，查看当前TCP连接的状态和对应的连接数量：

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

这个命令会输出类似下面的结果：

LAST_ACK16
SYN_RECV348
ESTABLISHED70
FIN_WAIT1229
FIN_WAIT230
CLOSING33
TIME_WAIT18098

我们只用关心TIME_WAIT的个数，在这里可以看到，有18000多个TIME_WAIT，这样就占用了18000多个端口。要知道端口的数量只有65535个，占用一个少一个，会严重的影响到后继的新连接。这种情况下，我们就有必要调整下Linux的TCP内核参数，让系统更快的释放TIME_WAIT连接。

编辑配置文件:/etc/sysctl.conf，在这个文件中，加入下面的几行内容：

# vim /etc/sysctl.conf
net.ipv4.tcp_syncookies= 1
net.ipv4.tcp_tw_reuse= 1
net.ipv4.tcp_tw_recycle= 1
net.ipv4.tcp_fin_timeout= 30

输入下面的命令，让内核参数生效：

# sysctl-p

简单的说明上面的参数的含义：

• net.ipv4.tcp_syncookies= 1 表示开启SYNCookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
• net.ipv4.tcp_tw_reuse= 1 表示开启重用。允许将TIME-WAITsockets重新用于新的TCP连接，默认为0，表示关闭；
• net.ipv4.tcp_tw_recycle= 1 表示开启TCP连接中TIME-WAITsockets的快速回收，默认为0，表示关闭；
• net.ipv4.tcp_fin_timeout 修改系統默认的TIMEOUT 时间。

在经过这样的调整之后，除了会进一步提升服务器的负载能力之外，还能够防御小流量程度的DoS、CC和SYN攻击。

此外，如果你的连接数本身就很多，我们可以再优化一下TCP的可使用端口范围，进一步提升服务器的并发能力。依然是往上面的参数文件中，加入下面这些配置：

net.ipv4.tcp_keepalive_time= 1200
net.ipv4.ip_local_port_range= 1024 65535
net.ipv4.tcp_max_syn_backlog= 8192
net.ipv4.tcp_max_tw_buckets= 5000

这几个参数，建议只在流量非常大的服务器上开启，会有显著的效果。一般的流量小的服务器上，没有必要去设置这几个参数。

• net.ipv4.tcp_keepalive_time= 1200 表示keepalive開始使用的時候，TCP發送keepalive訊息的頻度。缺省是2小時，改為20分鐘。
• ip_local_port_range= 1024 65535 表示用於向外連接的連接埠範圍。缺省情況下很小，改為1024到65535。
• net.ipv4.tcp_max_syn_backlog= 8192 表示SYN佇列的長度，預設為1024，加大佇列長度為8192，可以容納更多等待連線的網路連線數。
• net.ipv4.tcp_max_tw_buckets= 5000 表示系統同時保持TIME_WAIT的最大數量，如果超過這個數字，TIME_WAIT將立刻被清除並列印警告訊息。預設為180000，改為5000。此項參數可以控制TIME_WAIT的最大數量，只要超出了。核心其他TCP參數說明
• net.ipv4.tcp_max_syn_backlog= 65536 記錄的那些尚未收到客戶端確認訊息的連線請求的最大值。對於有128M記憶體的系統而言，預設值是1024，小記憶體的系統則是128。
• net.core.netdev_max_backlog= 32768 每個網路介面接收封包的速率比核心處理這些封包的速率快時，允許送到佇列的封包的最大數目。
• net.core.somaxconn= 32768 例如web應用程式中listen函數的backlog預設會給我們核心參數的net.core.somaxconn限製到128，而nginx定義的NGX_LISTEN_BACKLOG預設值511，所以有必要調整這個值。
• net.core.wmem_default= 8388608
• net.core.rmem_default= 8388608
• # net.core.rmem_max= 16777216 #最大socket讀buffer,可參考的最佳化值:873200
• net.core.wmem_max= 16777216 #最大socket寫入buffer,可參考的最佳化值:873200
• net.ipv4.tcp_timestsmps= 0 時間戳記可以避免序號的捲繞。一個1Gbps的連結一定會遇到以前用過的序號。時間戳能夠讓核心接受這種「異常」的資料包。這裡需要將其關掉。
• net.ipv4.tcp_synack_retries= 2 為了開啟對端的連接，核心需要發送一個SYN並附帶一個回應前面一個SYN的ACK。也就是所謂三次握手中的第二次握手。這個設定決定了在核心放棄連線之前發送SYN ACK套件的數量。
• net.ipv4.tcp_syn_retries= 2 在核心放棄建立連線之前發送SYN套件的數量。
• #net.ipv4.tcp_tw_len= 1
• net.ipv4.tcp_tw_reuse= 1 開啟重複使用。允許將TIME-WAITsockets重新用於新的TCP連線。
• net.ipv4.tcp_wmem= 8192 436600 873200 TCP寫入buffer,可參考的最佳化值:8192 436600 873200
• #net.ipv4. tcp_rmem = 32768 436600 873200 TCP讀buffer,可參考的優化值:32768 436600 873200
• net.ipv4.tcp_mem= 94500000 91500000 92700000 同樣有3個值,意思是:
• net.ipv4.tcp_mem[0]:低於此值，TCP沒有記憶體壓力。
• net.ipv4.tcp_mem[1]:在此值下，進入記憶體壓力階段。
• net.ipv4.tcp_mem[2]:高於此值，TCP拒絕指派socket。上述記憶體單位是頁，不是位元組。可參考的最佳化值是:7864321048576 1572864
• net.ipv4.tcp_max_orphans= 3276800 系統中最多有多少個TCP套接字不被關聯到任何一個使用者檔案句柄上。如果超過這個數字，連接將即刻被重設並列印出警告訊息。這個限制只是為了防止簡單的DoS攻擊，不能過分依靠它或人為地減小這個值， 更應該增加這個值(如果增加了內存之後)。
• net.ipv4.tcp_fin_timeout= 30 如果套接字由本端要求關閉，則這個參數決定了它保持在FIN-WAIT-2狀態的時間。對端可以出錯並永遠不關閉連接，甚至意外當機。缺省值是60秒。 2.2 核心的通常值是180秒，你可以按這個設置，但要記住的是，即使你的機器是一個輕載的WEB伺服器，也有因為大量的死套接字而內存溢出的風險，FIN- WAIT-2的危險性比FIN-WAIT-1要小，因為它最多只能吃掉1.5K內存，但是它們的生存期長些。

同時也牽涉到一個TCP 擁塞演算法的問題，你可以用下面的指令來查看本機提供的擁塞演算法控制模組：

• sysctl net.ipv4.tcp_available_congestion_control

對於幾種演算法的分析，詳情可以參考下：TCP擁塞控制演算法的優缺點、適用環境、效能分析，例如高延時可以試試hybla ，中等延時可以試用htcp演算法等。

如果想設定TCP 壅塞演算法為hybla net.ipv4.tcp_congestion_control=hybla

額外的，對於核心版高於於3.7.1的，我們可以開啟tcp_fastopen：net.ipv4. tcp_fastopen= 3

IO事件分配機制

在Linux啟用高並發TCP連接，必須確認應用程式是否使用了合適的網路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保證。

经过这样的优化配置之后，服务器的TCP并发处理能力会显著提高。以上配置仅供参考，用于生产环境请根据自己的实际情况调整观察再调整。

以上是高併發情況下 Linux 系統及 kernel 參數優化的詳細內容。更多資訊請關注PHP中文網其他相關文章！