Linux 内核 根据 CPU 和 内存 动态调整
哪些内核参数适合根据CPU和内存动态调整？
这是一个非常专业、而且非常“生产向”的问题 👍
结论先行：不是所有内核参数都适合“动态算”，但有一小部分“强烈适合”根据 CPU / 内存自动调整，其余要么固定值更安全，要么只和场景有关。
按 “强烈建议动态 -> 可选动态 -> 不建议动态” 给你一份清晰清单，并给出计算逻辑与原因。
这些参数与系统容量强相关，写死容易浪费或成为瓶颈。
作用：最大进程 / 线程数
核心瓶颈：线程多的服务（Java / Python / K8S / PostgreSQL）
pid_max ≈ CPU 核数 × 32768
| CPU | 推荐 pid_max |
|---|---|
| 2 核 | 65536 |
| 4 核 | 131072 |
| 8 核 | 262144 |
| ≥16 核 | 524288 ~ 1048576 |
kernel.pid_max = 262144
作用：系统级最大文件句柄数
影响对象：数据库、K8S、Nginx、Redis、Prometheus
file-max ≈ 内存(GB) × 262144
| 内存 | file-max |
|---|---|
| 4 GB | 1048576 |
| 8 GB | 2097152 |
| 16 GB | 4194304 |
fs.file-max = 4194304
作用：最大网络连接跟踪数
K8S / 容器 / NAT 必须
nf_conntrack_max ≈ 内存(MB) × 64
| 内存 | conntrack |
|---|---|
| 4 GB | 262144 |
| 8 GB | 524288 |
| 16 GB | 1048576 |
net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_buckets = 131072
buckets ≈ conntrack / 4
作用：最大 mmap 数
JVM / Elasticsearch / MongoDB 必须
max_map_count ≈ 内存(GB) × 16384
vm.max_map_count = 262144
这些参数不是必须动态，但在高并发 / 大内存机器上有明显收益。
net.core.rmem_max
net.core.wmem_max
net.ipv4.tcp_mem
tcp_mem ≈ 内存页数 × 0.01 / 0.02 / 0.03
| 内存 | tcp_mem |
|---|---|
| ≤8 GB | 786432 1048576 1572864 |
| ≥16 GB | 1572864 2097152 3145728 |
作用：网卡收包队列
与 CPU 核数强相关
net.core.netdev_max_backlog = CPU核数 × 2048
示例：
- 4 核 -> 8192
- 8 核 -> 16384
适用对象：PostgreSQL、Oracle、共享内存应用
shmmax ≈ 内存 × 50%~75%
shmall ≈ shmmax / PAGE_SIZE
这些参数与架构、语义、安全相关，动态反而危险。
| 参数 | 原因 |
|---|---|
vm.swappiness |
策略参数，不是容量 |
vm.overcommit_memory |
行为语义，非资源 |
kernel.numa_balancing |
架构级决策 |
net.ipv4.tcp_tw_reuse |
网络语义 |
net.ipv4.ip_forward |
功能开关 |
rp_filter |
路由策略 |
tcp_syncookies |
安全策略 |
tcp_timestamps |
协议语义 |
👉 这些参数“开 / 关 / 固定值”更安全
CPU=$(nproc)
MEM_MB=$(awk '/MemTotal/ {print int($2/1024)}' /proc/meminfo)
PID_MAX=$((CPU * 32768))
FILE_MAX=$((MEM_MB * 256))
CONNTRACK_MAX=$((MEM_MB * 64))
NET_BACKLOG=$((CPU * 2048))
只有“容量型参数”才适合根据 CPU / 内存动态计算；
“行为型、策略型、安全型参数”必须固定配置。