nf_conntrack内核模块常见问题

问题描述
排查步骤
- 前置条件：启用nf_conntrack内核模块
- 检查nf_conntrack配置
[解决办法1:半数减少nf_conntrack buckets的值](#解决办法1:半数减少nf_conntrack buckets的值)
解决办法2:加倍调大m.min_free_kbytes值
解决办法3:Linux社区权威答复-忽略告警

问题描述

内核报错 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/