nf_conntrack内核模块常见问题
- 问题描述
- 排查步骤
- 前置条件:启用nf_conntrack内核模块
- 检查nf_conntrack配置
- 解决办法1:半数减少nf_conntrack buckets的值
- 解决办法2:加倍调大m.min_free_kbytes值
- 解决办法3:Linux社区权威答复-忽略告警
问题描述
内核报错 falling back to vmalloc
排查步骤
前置条件:启用nf_conntrack内核模块
检查nf_conntrack内核模块是否启用
# 检查当前系统是否已经安装了 nf_conntrack 内核模块
lsmod | grep nf_conntrack
如果输出中没有nf_conntrack,则未启用该模块
# 低版本内核启用内核模块
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)的最大连接数 |
# 检查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"
# 查看连接跟踪模块(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
设置过大,按半数减小
,进行测试
# 修改连接跟踪模块(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 的值。
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/