nf_conntrack内核模块常见问题

本文详细介绍了nf_conntrack内核模块常见的问题“fallingbacktovmalloc”,涉及排查步骤,如启用模块、检查配置,以及三种解决办法:减小nf_conntrack_buckets值、增大m.min_free_kbytes并解释风险,以及Linux社区的官方回应。
摘要由CSDN通过智能技术生成

问题描述

内核报错 falling back to vmalloc


排查步骤


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

检查nf_conntrack内核模块是否启用

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

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

# 低版本内核启用内核模块
modprobe nf_conntrack_ipv4

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

检查nf_conntrack配置

参数默认值解释
net.netfilter.nf_conntrack_buckets65536网络连接跟踪表(conntrack table)的桶(bucket)数量
net.netfilter.nf_conntrack_max262144连接跟踪表中可以存储的最大连接跟踪条目数
net.nf_conntrack_max262144网络连接跟踪表(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"

image.png

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

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

image.png


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

image.png

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


解决办法2:加倍调大vm.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中已经删除该告警
image.png

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

image.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

识途老码

赞赏是第一生产力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值