参数是什么
net.netfilter.nf_conntrack_buckets 决定连接跟踪表的哈希桶数量：每条表项按哈希落到某个桶里，桶越多单条链越短、查找越快，但占用的内存也越多。它与 nf_conntrack_max（表项数量上限）是两个维度——max 决定能记录多少连接，buckets 决定在这些表项中查找的效率，两者需要匹配，桶太少会出现链过长、查找变慢、软中断占用上升。
基本信息
| 参数 | net.netfilter.nf_conntrack_buckets |
|---|---|
| 关联参数 | nf_conntrack_max（表项上限）、nf_conntrack_count（当前用量） |
| 默认值 | 由内核按内存规模推算，随版本与环境不同 |
| 修改方式 | 通常需在模块加载时指定或改启动参数后重启，运行时支持有限 |
| 运行统计 | conntrack -S（需 conntrack-tools）、/proc/net/stat/nf_conntrack |
| 内存开销 | 桶数组与表项都占用内存，规划时要一起估算 |
典型使用场景
- 大规模 NAT 网关：连接跟踪查找成为 CPU 热点时评估桶数是否不足
- 表项数量并不高但 CPU 偏高，怀疑哈希链过长导致查找变慢
- 扩容 nf_conntrack_max 时同步调整桶数，保持合理的平均链长
- 排查 conntrack 相关的软中断开销与丢包
- 云主机或容器宿主上核对连接跟踪的规模配置是否符合业务预期
查看现状
查看现状
sysctl net.netfilter.nf_conntrack_buckets # 当前桶数（可能提示只读）
cat /proc/sys/net/netfilter/nf_conntrack_count # 当前表项数
cat /proc/sys/net/netfilter/nf_conntrack_max # 表项上限
conntrack -S 2>/dev/null | head # 连接跟踪运行统计，需 conntrack-tools
awk '{print $1, $2}' /proc/net/stat/nf_conntrack | head # 每 CPU 的插入、查找与失败计数
free -h # 桶与表项都吃内存，先确认余量相关接口关系
| 项目 | 含义 | 关系 |
|---|---|---|
| nf_conntrack_buckets | 哈希桶数量 | 多则查找快、内存占用高 |
| nf_conntrack_max | 表项数量上限 | 决定能同时跟踪多少连接 |
| nf_conntrack_count | 当前表项数 | 与 max 比较判断是否接近容量 |
| conntrack -S | 运行统计 | 插入失败、查找失败等直接证据 |
桶数通常需要在模块加载时确定，运行时写入往往只读或需要重新加载模块。规划时应把桶数与 max 一起考虑，并按内存余量评估总开销，而不是只调其中一项。
不同内核版本对默认桶数的推算策略不同，直接照搬旧文档里的数值容易做出不匹配的配置。核对当前环境时以实际读取到的参数值为准。