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 模块为例：
nat：根据转发规则修改 IP 包的源/目标地址，靠 conntrack 记录才能让返回的包能路由到发请求的机器。
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”。
四 解决
通过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
通过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高并发场景下怎么丢包排查了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
本文题目：Centos7高并发场景下怎么丢包排查
当前路径：http://cdiso.cn/article/gpechh.html
