nf_conntrack内核模块常见问题

nf_conntrack内核模块常见问题

问题描述

内核报错 falling back to vmalloc

排查步骤

前置条件:启用nf_conntrack内核模块

检查nf_conntrack内核模块是否启用

shell 复制代码
# 检查当前系统是否已经安装了 nf_conntrack 内核模块
lsmod | grep nf_conntrack


如果输出中没有nf_conntrack,则未启用该模块

shell 复制代码
# 低版本内核启用内核模块
modprobe nf_conntrack_ipv4

# 高版本内核nf_conntrack_ipv4被nf_conntrack替换了
modprobe nf_conntrack

检查nf_conntrack配置

参数 默认值 解释
net.netfilter.nf_conntrack_buckets 65536 网络连接跟踪表(conntrack table)的桶(bucket)数量
net.netfilter.nf_conntrack_max 262144 连接跟踪表中可以存储的最大连接跟踪条目数
net.nf_conntrack_max 262144 网络连接跟踪表(conntrack table)的最大连接数
shell 复制代码
# 检查nf_conntrack配置
sysctl -a | grep -i nf_conntrack

# 查看网络连接跟踪表(conntrack table)的桶(bucket)数量
# 查看连接跟踪表中可以存储的最大连接跟踪条目数
# 查看网络连接跟踪表(conntrack table)的最大连接数
sysctl -a|grep -E "net.netfilter.nf_conntrack_buckets|net.netfilter.nf_conntrack_max|net.nf_conntrack_max"
shell 复制代码
# 查看连接跟踪模块(nf_conntrack)中的哈希表大小
# net.netfilter.nf_conntrack_buckets 参数是 hashsize 参数的一个别名
## 较大的哈希表大小可以支持更多的连接跟踪,但也会占用更多的内存
cat /sys/module/nf_conntrack/parameters/hashsize

# 通常和net.netfilter.nf_conntrack_buckets的值是一样的

解决办法1:半数减少nf_conntrack buckets的值

https://blog.csdn.net/whatday/article/details/107552387

出现报错localhost kernel: nf_conntrack: falling back to vmalloc.说明nf_conntrack buckets设置过大,按半数减小,进行测试

shell 复制代码
# 修改连接跟踪模块(nf_conntrack)中的哈希表大小
echo 3072200 > /sys/module/nf_conntrack/parameters/hashsize

# 修改连接跟踪表中可以存储的最大连接跟踪条目数
sysctl -w net.netfilter.nf_conntrack_max=2097152

# 修改网络连接跟踪表(conntrack table)的最大连接数
sysctl -w net.nf_conntrack_max=2097152

如果仍然报错误falling back to vmalloc,继续按半数减小,进行测试。

解决办法2:加倍调大m.min_free_kbytes值

https://access.redhat.com/solutions/6958239

红帽和Oracle官方建议
vm.min_free_kbytes该参数是:内核操作保留的最少可用RAM,该值不应超过系统内存的 0.4%2GB,一般调试方法是加倍 vm.min_free_kbytes 的值。

shell 复制代码
vm.min_free_kbytes

关键是在于调整内存的内核参数的时候!调大的风险远大于调小的风险!如果有人想将 vm.min_free_kbytes 调大,千万要注意当前的水位,如果一旦调大 vm.min_free_kbytes 立刻触

directreclaim,可能会导致机器hang住,ping的通,ssh不上,影响业务!hang住的原因是当 vm.min_free_kbytes 是512M的时候,此时 free只有1G,此时正常运行,此时如果调大
vm.min_free_kbytes 到5G,将会direct reclaim失败。

解决办法3:Linux社区权威答复-忽略告警

该告警并无实质性影响,RHEL8中已经删除该告警

这是Linux内核社区 关于消除该告警的补丁邮件
https://lore.kernel.org/lkml/55A8C428.1000005@gmx.de/T/

相关推荐
achi0101 年前
CentOS 7 调优之周期性的访问中断
周期性的访问中断·net_ratelimit·table full·dropping packet·nf_conntrack·conntrack·conntrack_max