Centos7高并發(fā)場景下怎么丟包排查

這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)Centos7高并發(fā)場景下怎么丟包排查，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一 問題產(chǎn)生背景

線上使用使用6臺阿里云掛到了SLB負載均衡后面，最開始TPS只有4000左右，但是今天TPS增加到了7500了，線上應(yīng)用偶發(fā)性的出現(xiàn)域名解析失敗，在服務(wù)器上ping域名的時候發(fā)現(xiàn)存在丟包（不限于內(nèi)網(wǎng)域名，即使是baidu域名也丟包）

[root@prd1 ~]# ping www.baidu.com
PING www.a.shifen.com (180.101.49.12) 56(84) bytes of data.
64 bytes from 180.101.49.12 (180.101.49.12): icmp_seq=1 ttl=48 time=16.4 ms
64 bytes from 180.101.49.12 (180.101.49.12): icmp_seq=2 ttl=48 time=16.3 ms
ping: sendmsg: 不允許的操作
ping: sendmsg: 不允許的操作

為了排除是DNS的問題，直接ping在同一個VPC下一個區(qū)的兩個機器ping也時好時壞：

[root@prd2 ~]# ping 172.31.6.108
PING 172.31.6.108 (172.31.6.108) 56(84) bytes of data.
ping: sendmsg: 不允許的操作
ping: sendmsg: 不允許的操作
64 bytes from 172.31.6.108: icmp_seq=13 ttl=64 time=0.129 ms
64 bytes from 172.31.6.108: icmp_seq=14 ttl=64 time=0.137 ms

二 問題原因

進一步分析同一個VPC下其他未部署該應(yīng)用的其他ESC沒有出現(xiàn)問題，所以初步診斷是Centos本身問題。

然后查看了SLB和Linux的請求日志，未判斷是遭受到了惡意DoS攻擊

最后通過**內(nèi)核日志（dmesg）**終于找到了問題：

[15283.099034] net_ratelimit: 18702 callbacks suppressed
[15283.099037] nf_conntrack: table full, dropping packet
[15283.099626] nf_conntrack: table full, dropping packet
[15283.099691] nf_conntrack: table full, dropping packet
[15283.102105] nf_conntrack: table full, dropping packet
[15283.102754] nf_conntrack: table full, dropping packet
[15283.103533] nf_conntrack: table full, dropping packet
[15283.103889] nf_conntrack: table full, dropping packet
[15283.104421] nf_conntrack: table full, dropping packet
[15283.106042] nf_conntrack: table full, dropping packet
[15283.106047] nf_conntrack: table full, dropping packet
[15288.100786] net_ratelimit: 22924 callbacks suppressed

內(nèi)核日志中出現(xiàn)了大量的：nf_conntrack: table full, dropping packet

三 net_ratelimit和nf_conntrack

1 net_ratelimit

rate limit也是Linux為了避免DoS攻擊的一種機制，避免每個消息都被記錄（會導(dǎo)致存儲空間撐爆）。當內(nèi)核記錄消息，使用printk()通過這種機制來檢查是否輸出日志

這個限制可以通過/proc/sys/kernel/printk_ratelimit和/proc/sys/kernel/printk_ratelimit_burst來調(diào)優(yōu)。默認配置（RHEL6）分別是5和10。

也就是說，內(nèi)核允許每5秒記錄10條消息。超過這個限制，內(nèi)核就會拋棄日志，并記錄ratelimit N: callbacks suppressed

[root@prd16 ~]# cat /proc/sys/kernel/printk_ratelimit
5
[root@prd16 ~]# cat /proc/sys/kernel/printk_ratelimit_burst
10

對應(yīng)內(nèi)核代碼：http://fxr.watson.org/fxr/source/net/core/utils.c?v=linux-2.6

2 nf_conntrack

nf_conntrack是Linux系統(tǒng)內(nèi)NAT的一個跟蹤連接條目的模塊。

nf_conntrack模塊會使用一個哈希表記錄TCP協(xié)議“established connection”記錄，當這個哈希表滿之后，新的連接會引發(fā)“nf_conntrack: table full, dropping packet”錯誤。

這個模塊是在 kernel 2.6.15（2006-01-03 發(fā)布） 被引入，支持 IPv4 和 IPv6，取代只支持 IPv4 的 ip_connktrack，用于跟蹤連接的狀態(tài)，供其他模塊使用。

需要 NAT 的服務(wù)都會用到它，例如防火墻、Docker 等。以 iptables 的 nat 和 state 模塊為例：

1. nat：根據(jù)轉(zhuǎn)發(fā)規(guī)則修改 IP 包的源/目標地址，靠 conntrack 記錄才能讓返回的包能路由到發(fā)請求的機器。

2. state：直接用 conntrack 記錄的連接狀態(tài)（NEW/ESTABLISHED/RELATED/INVALID 等）來匹配防火墻過濾規(guī)則。

關(guān)于nf_conntrack模塊中的重要參數(shù)，可參考如下信息。

• nf_conntrack_buckets：哈希表的大小，可在模塊加載時指定參數(shù)，也可以通過sysctl命令修改。當系統(tǒng)內(nèi)存大于等于4GB時，它的默認值是“65536”。

• nf_conntrack_max：哈希表的最大節(jié)點個數(shù)，即nf_conntrack模塊支持的最大連接數(shù)。當系統(tǒng)內(nèi)存大于等于4G時，它的默認值是“262144”。對于處理大量連接的服務(wù)器來說，該默認值相對較小。

• nf_conntrack_tcp_timeout_time_wait：nf_conntrack模塊中保存time_wait狀態(tài)的TCP連接時間，默認值為“120s”。

四 解決

1. 通過sysctl接口調(diào)整nf_conntrack模塊中的參數(shù)值 業(yè)務(wù)側(cè)應(yīng)提前自行確認應(yīng)用程序可能使用的nf_conntrack最大連接數(shù)，并參考如下命令，通過sysctl接口調(diào)整nf_conntrack模塊中的參數(shù)值

sudo sysctl -w net.netfilter.nf_conntrack_max=1503232
sudo sysctl -w net.netfilter.nf_conntrack_buckets=375808  # 如果使用非4.19內(nèi)核，該選項可能無法在運行時修改
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=60

2. 通過iptables過濾不需要追蹤的連接 參考如下命令，在iptables規(guī)則中增加“-j notrack”的動作 ，即過濾不需要追蹤（track）的連接。該方式的好處是治本，可以將不需要追蹤的連接直接進行notrack處理，將不會占用哈希表的空間，也就不會引發(fā)報錯。

sudo iptables -t raw -A PREROUTING -p udp -j NOTRACK
sudo iptables -t raw -A PREROUTING -p tcp --dport 22 -j NOTRACK

上述就是小編為大家分享的Centos7高并發(fā)場景下怎么丟包排查了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。