Linux高并發(fā)踩過的坑及性能優(yōu)化介紹

更新時間：2021年12月15日 10:05:54 作者：anyRTC

大家好，本篇文章主要講的是Linux高并發(fā)踩過的坑及性能優(yōu)化介紹，感興趣的同學(xué)趕快來看一看吧，對你有幫助的話記得收藏一下，方便下次瀏覽

前言

Linux操作系統(tǒng)是現(xiàn)在服務(wù)器的首選操作系統(tǒng)，在Linux的默認(rèn)系統(tǒng)參數(shù)下，Linux針對高并發(fā)的支持性并不是很好。小編從事Linux下應(yīng)用程序開發(fā)多年，關(guān)于Linux系統(tǒng)下的高并發(fā)，小編自己踩過的坑，及如何解決踩過的坑下面列上幾條，供大家參考，避免再次掉坑。

Linux應(yīng)用運(yùn)行過程中出現(xiàn)Too many open files 問題分析和解決

出現(xiàn)這句提示的原因是程序打開的文件socket連接數(shù)量超過系統(tǒng)設(shè)定值。

查看每個用戶最大允許打開的文件數(shù)量

ulimit -a

其中 open files (-n) 1024 表示每個用戶最大允許打開的文件數(shù)量是1024

當(dāng)前系統(tǒng)文件句柄的最大數(shù)目，只用于查看，不能設(shè)置修改

cat /proc/sys/fs/file-max

查看某個進(jìn)程的打開文件限制數(shù)

cat /proc/10446(pid)/limits

設(shè)置open files 數(shù)值方法

ulimit -n 65535

這種設(shè)置方法在重啟后會還原為默認(rèn)值。

永久設(shè)置方法：

vim /etc/security/limits.conf

在最后加入

* soft nofile 65535

* hard nofile 65535

生效需要重啟系統(tǒng)

這樣修改之后，問題得到有效解決。

Linux高并發(fā)下 time_wait 過多的問題分析及解決

現(xiàn)象是高并發(fā)場景下，服務(wù)器運(yùn)行應(yīng)用卡頓。

排查方法：查看服務(wù)器配置：

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

發(fā)現(xiàn)處于 time_wait 的數(shù)量太多，有幾萬條，應(yīng)該是大量socket處于TIME_WAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時部分客戶端就會顯示連接不上。
TCP連接狀態(tài)描述：

CLOSED：無連接是活動的或正在進(jìn)行
LISTEN：服務(wù)器在等待進(jìn)入呼叫
SYN_RECV：一個連接請求已經(jīng)到達(dá)，等待確認(rèn)
SYN_SENT：應(yīng)用已經(jīng)開始，打開一個連接
ESTABLISHED：正常數(shù)據(jù)傳輸狀態(tài)
FIN_WAIT1：應(yīng)用說它已經(jīng)完成
FIN_WAIT2：另一邊已同意釋放
ITMED_WAIT：等待所有分組死掉
CLOSING：兩邊同時嘗試關(guān)閉
TIME_WAIT：另一邊已初始化一個釋放
LAST_ACK：等待所有分組死掉

TIME_WAIT過多危害

網(wǎng)絡(luò)情況不好時，如果主動方無TIME_WAIT等待，關(guān)閉前個連接后，主動方與被動方又建立起新的TCP連接，這時被動方重傳或延時過來的FIN包過來后會直接影響新的TCP連接；
同樣網(wǎng)絡(luò)情況不好并且無TIME_WAIT等待，關(guān)閉連接后無新連接，當(dāng)接收到被動方重傳或延遲的FIN包后，會給被動方回一個RST包，可能會影響被動方其它的服務(wù)連接。

針對如何解決TIME_WAIT 過多這一問題，解答如下：

編輯內(nèi)核文件/etc/sysctl.conf，加入以下內(nèi)容：

net.ipv4.tcp_syncookies = 1 #表示開啟SYN Cookies。當(dāng)出現(xiàn)SYN等待隊(duì)列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_reuse = 1 #表示開啟重用。允許將TIME-WAIT sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉；
net.ipv4.tcp_tw_recycle = 1 #表示開啟TCP連接中TIME-WAIT sockets的快速回收，默認(rèn)為0，表示關(guān)閉。
net.ipv4.tcp_fin_timeout =30#修改系默認(rèn)的 TIMEOUT 時間

然后執(zhí)行 /sbin/sysctl -p 讓參數(shù)生效.

簡單來說，就是打開系統(tǒng)的TIMEWAIT重用和快速回收。

Linux更多性能優(yōu)化

如果您的系統(tǒng)的連接數(shù)本身就很多，如果以上配置調(diào)優(yōu)后性能還不理想，可以再優(yōu)化一下TCP的可使用端口范圍，進(jìn)一步提升服務(wù)器的并發(fā)能力。依然是/etc/sysctl.conf文件中，加入下面這些配置：

vi /etc/sysctl.conf
#表示當(dāng)keepalive起用的時候，TCP發(fā)送keepalive消息的頻度。缺省是2小時，改為20分鐘。
net.ipv4.tcp_keepalive_time = 1200 
#表示用于向外連接的端口范圍。缺省情況下很?。?2768到61000，改為1024到65000。
net.ipv4.ip_local_port_range = 1024 65000 
#表示SYN隊(duì)列的長度，默認(rèn)為1024，加大隊(duì)列長度為8192，可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)。
net.ipv4.tcp_max_syn_backlog = 8192 
#表示系統(tǒng)同時保持TIME_WAIT套接字的最大數(shù)量，如果超過這個數(shù)字，TIME_WAIT套接字將立刻被清除并打印警告信息。默認(rèn)為180000，改為5000。對于Apache、Nginx等服務(wù)器，上幾行的參數(shù)可以很好地減少TIME_WAIT套接字?jǐn)?shù)量，但是對于 Squid，效果卻不大。此項(xiàng)參數(shù)可以控制TIME_WAIT套接字的最大數(shù)量，避免Squid服務(wù)器被大量的TIME_WAIT套接字拖死。
net.ipv4.tcp_max_tw_buckets = 5000

Linux內(nèi)核更多參數(shù)優(yōu)化說明

vim /etc/sysctl.conf

1、net.ipv4.tcp_max_syn_backlog = 65536

記錄的那些尚未收到客戶端確認(rèn)信息的連接請求的最大值。對于超過128M內(nèi)存的系統(tǒng)而言，缺省值是1024，低于128M小內(nèi)存的系統(tǒng)則是128。

SYN Flood攻擊利用TCP協(xié)議散布握手的缺陷，偽造虛假源IP地址發(fā)送大量TCP-SYN半打開連接到目標(biāo)系統(tǒng)，最終導(dǎo)致目標(biāo)系統(tǒng)Socket隊(duì)列資源耗盡而無法接受新的連接。為了應(yīng)付這種攻擊，現(xiàn)代Unix系統(tǒng)中普遍采用多連接隊(duì)列處理的方式來緩沖(而不是解決)這種攻擊，是用一個基本隊(duì)列處理正常的完全連接應(yīng)用(Connect()和Accept() )，是用另一個隊(duì)列單獨(dú)存放半打開連接。

這種雙隊(duì)列處理方式和其他一些系統(tǒng)內(nèi)核措施(例如Syn-Cookies/Caches)聯(lián)合應(yīng)用時，能夠比較有效的緩解小規(guī)模的SYN Flood攻擊(事實(shí)證明<1000p/s)加大SYN隊(duì)列長度可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)，一般遭受SYN Flood攻擊的網(wǎng)站，都存在大量SYN_RECV狀態(tài)，所以調(diào)大tcp_max_syn_backlog值能增加抵抗syn攻擊的能力。

2、net.core.netdev_max_backlog = 32768

每個網(wǎng)絡(luò)接口接收數(shù)據(jù)包的速率比內(nèi)核處理這些包的速率快時，允許送到隊(duì)列的數(shù)據(jù)包的最大數(shù)目。

3、net.core.somaxconn = 32768

調(diào)整系統(tǒng)同時發(fā)起并發(fā)TCP連接數(shù)，可能需要提高連接儲備值，以應(yīng)對大量突發(fā)入局連接請求的情況。如果同時接收到大量連接請求，使用較大的值會提高受支持的暫掛連接的數(shù)量，從而可減少連接失敗的數(shù)量。大的偵聽隊(duì)列對防止DDoS攻擊也會有所幫助。掛起請求的最大數(shù)量默認(rèn)是128。

查看實(shí)時內(nèi)核實(shí)時丟包命令：

netstat-su

位置：/proc/sys/

4、net.core.wmem_default = 8388608

該參數(shù)指定了發(fā)送套接字緩沖區(qū)大小的缺省值(以字節(jié)為單位)

5、net.core.rmem_default = 8388608

該參數(shù)指定了接收套接字緩沖區(qū)大小的缺省值(以字節(jié)為單位)

6、net.core.rmem_max = 16777216

該參數(shù)指定了接收套接字緩沖區(qū)大小的最大值(以字節(jié)為單位)

7、net.core.wmem_max = 16777216

該參數(shù)指定了發(fā)送套接字緩沖區(qū)大小的最大值(以字節(jié)為單位)

8、net.ipv4.tcp_timestamps = 0

Timestamps可以防范那些偽造的sequence號碼。一條1G的寬帶線路或許會重遇到帶out-of-line數(shù)值的舊sequence號碼(假如它是由于上次產(chǎn)生的)。時間戳能夠讓內(nèi)核接受這種“異?！钡臄?shù)據(jù)包。這里需要將其關(guān)掉,以提高性能。

9、net.ipv4.tcp_synack_retries = 2

對于遠(yuǎn)端的連接請求SYN，內(nèi)核會發(fā)送SYN＋ACK數(shù)據(jù)報，以確認(rèn)收到上一個SYN連接請求包。這是所謂的三次握手(threeway handshake)機(jī)制的第二個步驟。這里決定內(nèi)核在放棄連接之前所送出的SYN+ACK數(shù)目。不應(yīng)該大于255，默認(rèn)值是5，對應(yīng)于180秒左右時間。(可以根據(jù)tcp_syn_retries來決定這個值)

10、net.ipv4.tcp_syn_retries = 2

對于一個新建連接，內(nèi)核要發(fā)送多少個SYN連接請求才決定放棄。不應(yīng)該大于255，默認(rèn)值是5，對應(yīng)于180秒左右時間。(對于大負(fù)載而物理通信良好的網(wǎng)絡(luò)而言,這個值偏高,可修改為2.這個值僅僅是針對對外的連接,對進(jìn)來的連接,是由tcp_retries1 決定的)

#net.ipv4.tcp_tw_len = 1

11、net.ipv4.tcp_tw_reuse = 1

表示開啟重用，允許將TIME-WAIT Sockets重新用于新的TCP連接，默認(rèn)為0，表示關(guān)閉。這個對快速重啟動某些服務(wù),而啟動后提示端口已經(jīng)被使用的情形非常有幫助。

12、net.ipv4.tcp_mem = 94500000 915000000 927000000

tcp_mem有3個INTEGER變量：low, pressure, high

low：當(dāng)TCP使用了低于該值的內(nèi)存頁面數(shù)時，TCP沒有內(nèi)存壓力，TCP不會考慮釋放內(nèi)存。(理想情況下，這個值應(yīng)與指定給tcp_wmem的第2個值相匹配。這第2個值表明，最大頁面大小乘以最大并發(fā)請求數(shù)除以頁大小 (131072*300/4096)

pressure：當(dāng)TCP使用了超過該值的內(nèi)存頁面數(shù)量時，TCP試圖穩(wěn)定其內(nèi)存使用，進(jìn)入pressure模式，當(dāng)內(nèi)存消耗低于low值時則退出pressure狀態(tài)。(理想情況下這個值應(yīng)該是TCP可以使用的總緩沖區(qū)大小的最大值(204800*300/4096)

high：允許所有TCP Sockets用于排隊(duì)緩沖數(shù)據(jù)報的頁面量。如果超過這個值，TCP連接將被拒絕，這就是為什么不要令其過于保守(512000*300/4096)的原因了。在這種情況下，提供的價值很大，它能處理很多連接，是所預(yù)期的2.5倍；或者使現(xiàn)有連接能夠傳輸2.5倍的數(shù)據(jù)。

一般情況下這些值是在系統(tǒng)啟動時根據(jù)系統(tǒng)內(nèi)存數(shù)量計算得到的。

13、net.ipv4.tcp_max_orphans = 3276800

系統(tǒng)所能處理不屬于任何進(jìn)程的TCP sockets最大數(shù)量。假如超過這個數(shù)量﹐那么不屬于任何進(jìn)程的連接會被立即reset，并同時顯示警告信息。之所以要設(shè)定這個限制﹐純粹為了抵御那些簡單的DoS攻擊﹐千萬不要依賴這個或是人為的降低這個限制

14、net.ipv4.tcp_fin_timeout = 30

如果套接字由本端要求關(guān)閉，這個參數(shù)決定了它保持在FIN-WAIT-2狀態(tài)的時間。對端可以出錯并永遠(yuǎn)不關(guān)閉連接，甚至意外當(dāng)機(jī)。缺省值是60秒。2.2 內(nèi)核的通常值是180秒，你可以按這個設(shè)置，但要記住的是，即使你的機(jī)器是一個輕載的WEB服務(wù)器，也有因?yàn)榇罅康乃捞捉幼侄鴥?nèi)存溢出的風(fēng)險，F(xiàn)IN-WAIT-2的危險性比FIN-WAIT-1要小，因?yàn)樗疃嘀荒艹缘?.5K內(nèi)存，但是它們的生存期長些。

15、net.ipv4.ip_conntrack_max = 10000

設(shè)置系統(tǒng)對最大跟蹤的TCP連接數(shù)的限制(CentOS 5.6無此參數(shù))

同時還涉及到一個TCP 擁塞算法的問題，你可以用下面的命令查看本機(jī)提供的擁塞算法控制模塊：

sysctlnet.ipv4.tcp_available_congestion_control

對于幾種算法的分析，詳情可以參考下：TCP擁塞控制算法的優(yōu)缺點(diǎn)、適用環(huán)境、性能分析，比如高延時可以試用hybla，中等延時可以試用htcp算法等。

如果想設(shè)置TCP 擁塞算法為hybla

#設(shè)置TCP 擁塞算法
net.ipv4.tcp_congestion_control=hybla

對于內(nèi)核版高于于3.7.1的，我們可以開啟tcp_fastopen：

#開啟tcp_fastopen
net.ipv4.tcp_fastopen= 3

Iptables相關(guān)

如非必須，關(guān)掉或卸載iptables防火墻，并阻止kernel加載iptables模塊。這些模塊會影響并發(fā)性能。

IO事件分配機(jī)制

在Linux啟用高并發(fā)TCP連接，必須確認(rèn)應(yīng)用程序是否使用了合適的網(wǎng)絡(luò)I/O技術(shù)和I/O事件分派機(jī)制。可用的I/O技術(shù)有同步I/O，非阻塞式同步I/O，以及異步I/O。在高TCP并發(fā)的情形下，如果使用同步I/O，這會嚴(yán)重阻塞程序的運(yùn)轉(zhuǎn)，除非為每個TCP連接的I/O創(chuàng)建一個線程。但是，過多的線程又會因系統(tǒng)對線程的調(diào)度造成巨大開銷。因此，在高TCP并發(fā)的情形下使用同步I/O是不可取的，這時可以考慮使用非阻塞式同步I/O或異步I/O。非阻塞式同步I/O的技術(shù)包括使用select()，poll()，epoll等機(jī)制。異步I/O的技術(shù)就是使用AIO。

從I/O事件分派機(jī)制來看，使用select()是不合適的，因?yàn)樗С值牟l(fā)連接數(shù)有限(通常在1024個以內(nèi))。如果考慮性能，poll()也是不合適的，盡管它可以支持的較高的TCP并發(fā)數(shù)，但是由于其采用“輪詢”機(jī)制，當(dāng)并發(fā)數(shù)較高時，其運(yùn)行效率相當(dāng)?shù)停⒖赡艽嬖贗/O事件分派不均，導(dǎo)致部分TCP連接上的I/O出現(xiàn)“饑餓”現(xiàn)象。而如果使用epoll或AIO，則沒有上述問題(早期Linux內(nèi)核的AIO技術(shù)實(shí)現(xiàn)是通過在內(nèi)核中為每個I/O請求創(chuàng)建一個線程來實(shí)現(xiàn)的，這種實(shí)現(xiàn)機(jī)制在高并發(fā)TCP連接的情形下使用其實(shí)也有嚴(yán)重的性能問題。但在最新的Linux內(nèi)核中，AIO的實(shí)現(xiàn)已經(jīng)得到改進(jìn))。