Centos7高并發場景下怎么丟包排查

這期內容當中小編將會給大家帶來有關Centos7高并發場景下怎么丟包排查，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一 問題產生背景

線上使用使用6臺阿里云掛到了SLB負載均衡后面，最開始TPS只有4000左右，但是今天TPS增加到了7500了，線上應用偶發性的出現域名解析失敗，在服務器上ping域名的時候發現存在丟包（不限于內網域名，即使是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下一個區的兩個機器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下其他未部署該應用的其他ESC沒有出現問題，所以初步診斷是Centos本身問題。

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

最后通過**內核日志（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

內核日志中出現了大量的：nf_conntrack: table full, dropping packet

三 net_ratelimit和nf_conntrack

1 net_ratelimit

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

這個限制可以通過/proc/sys/kernel/printk_ratelimit和/proc/sys/kernel/printk_ratelimit_burst來調優。默認配置（RHEL6）分別是5和10。

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

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

對應內核代碼：http://fxr.watson.org/fxr/source/net/core/utils.c?v=linux-2.6

2 nf_conntrack

nf_conntrack是Linux系統內NAT的一個跟蹤連接條目的模塊。

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

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

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

1. nat：根據轉發規則修改 IP 包的源/目標地址，靠 conntrack 記錄才能讓返回的包能路由到發請求的機器。

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

關于nf_conntrack模塊中的重要參數，可參考如下信息。

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

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

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

四 解決

1. 通過sysctl接口調整nf_conntrack模塊中的參數值 業務側應提前自行確認應用程序可能使用的nf_conntrack最大連接數，并參考如下命令，通過sysctl接口調整nf_conntrack模塊中的參數值

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

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

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

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