一、 故障現(xiàn)象

部分機頂盒用戶出現(xiàn)大面積登錄app時，界面停留在登陸頁面，無反應(yīng)。

二、現(xiàn)象初步分析

本次問題出現(xiàn)時，所有aaa出現(xiàn)了異常流量波動，在aaa異常流量段期間接到用戶故障報障。此時主要表現(xiàn)在lvs集群顯示真實的epg 服務(wù)器不停的被踢出集群和加入(up/down)，導(dǎo)致了用戶調(diào)度到epg后出現(xiàn)了異常顯示。

aaa異常流量圖

三、問題排查過程

接到故障后第一時間對aaa/epg后臺日志進(jìn)行了查看，發(fā)現(xiàn)用戶接入認(rèn)證和響應(yīng)都正常，觀察到epg 的lvs集群中有服務(wù)器的inactive連接數(shù)異常并且隨機出現(xiàn)不同epg服務(wù)器被踢出和加入集群，隨后對epg 的lvs集群的狀態(tài)進(jìn)行了跟蹤和抓包分析,為了快速恢復(fù)業(yè)務(wù)隨后重啟了epg tomcat并進(jìn)行了lvs的主備切換，業(yè)務(wù)故障恢復(fù)。

四、診斷分析結(jié)果

出現(xiàn)故障時通過lvs的日志可以看到5臺epg服務(wù)器在輪詢的出現(xiàn)連接失敗和連接成功的情況，也就是一臺ok后，另一臺出現(xiàn)連接失敗，如此反復(fù)的表現(xiàn)在5臺epg服務(wù)器上

此時被up/down的epg會出現(xiàn)大量的inactive

此時對集群出現(xiàn)up/dowm的服務(wù)器進(jìn)行抓包，發(fā)現(xiàn)客戶端發(fā)出了syn報

文，但是epg服務(wù)器沒有響應(yīng)，并且響應(yīng)報文發(fā)不出去不停的retransmission。

進(jìn)一步查看該epg的資源消耗情況netstat發(fā)現(xiàn)大量的syn-recv

通過上面的現(xiàn)象判斷是epg的socket資源被耗盡進(jìn)而出現(xiàn)了響應(yīng)客戶端異常，導(dǎo)致了lvs檢測epg服務(wù)器異常，因集群是5臺epg服務(wù)器，一臺異常后lvs集群把用戶調(diào)度到其它epg服務(wù)器，此時異常用戶也對該服務(wù)器產(chǎn)生了影響出現(xiàn)了該服務(wù)器也被資源耗盡，依次循環(huán)。根據(jù)當(dāng)前的用戶量程度來看一般epg的資源應(yīng)該是可以滿足，進(jìn)一步查看資源情況發(fā)現(xiàn)是epg的句柄數(shù)被耗盡導(dǎo)致的，當(dāng)重啟epg后，資源被釋放句柄數(shù)被釋放問題故障就恢復(fù)了。查看epg服務(wù)器發(fā)現(xiàn)系統(tǒng)的默認(rèn)句柄數(shù)為1024。

lvs原理分析：

當(dāng)有異常用戶訪問epg時，syn消息先發(fā)送到lvs，lvs會建立一個調(diào)度表，顯示用戶與epg的tcp對應(yīng)關(guān)系，epg會直接返回ack給用戶端不經(jīng)過lvs，只有l(wèi)vs收到用戶端發(fā)送的fin時，表項的對應(yīng)關(guān)系才會刪除該用戶客戶端的epg對應(yīng)關(guān)系。

當(dāng)用戶訪問突然異常且量大的時候epg默認(rèn)的句柄數(shù)只有1024，這樣會導(dǎo)致lvs踢出該epg，但是此時lvs建立的表里面的tcp關(guān)系還在所以inactive數(shù)會變的特別大，根據(jù)lvs調(diào)度策略用戶會被調(diào)度到其它epg真實服務(wù)器，這樣就會形成惡性循環(huán)，所有集群的epg真實服務(wù)器會被資源耗盡。

五、處理優(yōu)化措施

從上述分析來看本次故障根本原因是epg真實服務(wù)器的句柄數(shù)采用默認(rèn)的1024，一旦出現(xiàn)異常用戶訪問的時候就會變的脆弱，目前修改為了204800。經(jīng)過本次故障，對系統(tǒng)的參數(shù)做了確認(rèn)和文檔化

六、參數(shù)修改記錄

修改記錄一：net.ipv4.tcp_timestamps = 0

原因如下

1、slb服務(wù)器為了優(yōu)化性能，調(diào)整以下內(nèi)核參數(shù)：

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_tw_recycle = 1

當(dāng)這兩個參數(shù)都打開時，tcp需要校驗syn包的時間戳(timestamp)對集團用戶有影響使其接入失敗。

2、當(dāng)滿足以下條件，syn包將會被忽略，不會回復(fù)ack包：

a、該源ip的上次tcp通訊發(fā)生在60s內(nèi)。

b、該源ip的上次tcp通訊的timestamp 大于本次tcp。

注：tcp通訊的timestamp 為系統(tǒng)啟動到當(dāng)前的時間。

3、解釋現(xiàn)象：

a、為什么普通的用戶播放正常，集團用戶不行？

一個ip對應(yīng)一個普通用戶，那么普通用戶的tcp通訊的timestamp是一直增大的，即不會滿足2中的b條件。

集團用戶是做了nat的，一個ip對應(yīng)多個客戶端，只有tcp通訊的timestamp比較大的客戶端(大堂)才能請求成功，timestamp比較小的(房間)請求就失敗。

b、房間偶爾又能播放？

該源ip的上次tcp通訊發(fā)生在60s之外了。

修改記錄二：net.ipv4.tcp_max_tw_buckets = 5000

time_wait狀態(tài)的連接過多，會影響到大并發(fā)。

修改記錄三：net.ipv4.tcp_synack_retries = 0

net.core.somaxconn = 65535

writen:aaron

time:20170106

原因如下：

syn flood(tcp洪水攻擊優(yōu)化)

tcp_synack_retries：表示回應(yīng)第二個握手包(syn+ack包)給客戶端ip后，如果收不到第三次握手包(ack包)后，不進(jìn)行重試，加快回收“半連接”，不要耗光資源。可以把tcp_synack_retries改為0，因為客戶端還有tcp_syn_retries參數(shù)，默認(rèn)是5，即使服務(wù)器端沒有重發(fā)syn+ack包，客戶端也會重發(fā)syn握手包。

net.core.somaxconn：最大的監(jiān)聽隊列的長度，默認(rèn)限制為128，在高突發(fā)的請求中可能會導(dǎo)致鏈接超時或觸發(fā)重傳。

修改記錄四：

括號值為修改后的值，(x)代表刪除。

net.ipv4.tcp_fin_timeout = 5 (1)

net.ipv4.tcp_max_syn_backlog = 10240(262144)

net.ipv4.tcp_max_tw_buckets = 5000(6000)

net.ipv4.tcp_mem = 24794688????? 33059584??????? 49589376 (x)

net.ipv4.tcp_retries1 = 3 (2)

net.ipv4.tcp_retries2 = 15(2)

net.ipv4.tcp_keepalive_intvl = 75(2)

net.ipv4.tcp_keepalive_probes = 9(3)

net.ipv4.tcp_keepalive_time = 7200(2)

net.ipv4.tcp_rmem = 4096???? 87380????? 4194304(x)

net.ipv4.tcp_syn_retries = 2

net.ipv4.tcp_timestamps = 0(1)// timestamps可單獨起效

net.ipv4.tcp_tw_recycle = 1(0)// 需要timestamps起效，此項才奇效，單獨開啟無意義

net.ipv4.tcp_wmem = 4096??? 16384????? 4194304(x)

net.ipv4.udp_mem = 24794688???? 33059584??????? 49589376(x)

net.ipv4.udp_rmem_min = 4096(x)

net.ipv4.udp_wmem_min = 4096(x)

net.core.rps_sock_flow_entries = 65535

// nf_conntrack 避免iptables的conntrack模塊故障

net.netfilter.nf_conntrack_acct = 0

net.netfilter.nf_conntrack_checksum = 1

net.netfilter.nf_conntrack_events = 1

net.netfilter.nf_conntrack_events_retry_timeout = 5

net.netfilter.nf_conntrack_expect_max = 256

net.netfilter.nf_conntrack_generic_timeout = 6

net.netfilter.nf_conntrack_helper = 1

net.netfilter.nf_conntrack_icmp_timeout = 3

net.netfilter.nf_conntrack_log_invalid = 0

net.netfilter.nf_conntrack_max = 524288

net.netfilter.nf_conntrack_tcp_be_liberal = 0

net.netfilter.nf_conntrack_tcp_loose = 1

net.netfilter.nf_conntrack_tcp_max_retrans = 2

net.netfilter.nf_conntrack_tcp_timeout_close = 5

net.netfilter.nf_conntrack_tcp_timeout_close_wait = 6

net.netfilter.nf_conntrack_tcp_timeout_established = 5

net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 3

net.netfilter.nf_conntrack_tcp_timeout_last_ack = 3

net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 3

net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 3

net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 3

net.netfilter.nf_conntrack_tcp_timeout_time_wait = 2

net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 3

net.netfilter.nf_conntrack_timestamp = 0

net.netfilter.nf_conntrack_udp_timeout = 3

net.netfilter.nf_conntrack_udp_timeout_stream = 3

net.nf_conntrack_max = 524288

修改記錄五：

net.ipv4.tcp_max_tw_buckets = 6000 (262144)

原因：tcp_max_tw_buckets的默認(rèn)值為262144

修改記錄六：

增加修改文件句柄數(shù)：在/root/.bash_profile增加ulimit -n 204800

總結(jié)

以上是生活随笔為你收集整理的linux查询socket资源,TCP的socket资源被耗尽的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。