nf_conntrack内核模块常见问题

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

image.png
nf_conntrack内核模块常见问题_第1张图片
如果输出中没有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内核模块常见问题_第2张图片

# 查看连接跟踪模块(nf_conntrack)中的哈希表大小
# net.netfilter.nf_conntrack_buckets 参数是 hashsize 参数的一个别名
## 较大的哈希表大小可以支持更多的连接跟踪,但也会占用更多的内存
cat /sys/module/nf_conntrack/parameters/hashsize

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

nf_conntrack内核模块常见问题_第3张图片


解决办法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

nf_conntrack内核模块常见问题_第4张图片

如果仍然报错误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中已经删除该告警
nf_conntrack内核模块常见问题_第5张图片

这是Linux内核社区 关于消除该告警的补丁邮件
https://lore.kernel.org/lkml/[email protected]/T/

你可能感兴趣的:(Linux内核,nf_conntrack)