Linux内核参数调优清单

背景与适用场景

Linux 系统从发行版自带的默认内核参数是为通用场景设计的，保守、保守、再保守。很多时候机器跑在低负载、低并发、低内存压力下，这些默认值没有问题。但当业务进入生产环境，尤其是 Web 服务、高并发 API、数据库、缓存、消息队列、容器平台等场景，默认参数会迅速成为瓶颈。

需要调内核参数的典型信号：

Nginx / Apache 连接建立时报connect: cannot assign requested address或too many open files

MySQL / PostgreSQL 连接数突增时部分请求失败，日志出现Too many connections

服务器在大量并发下出现卡顿，CPU 和内存明明还有余量但请求超时

业务正常但系统日志出现kernel: TCP: too many orphaned sockets或Out of socket memory

压测时 QPS 怎么也上不去，排除应用层问题后怀疑是内核队列满了

容器宿主机上跑着几十个容器，时不时报cannot create file: No space left on device或者句柄耗尽

本文覆盖 20 项生产环境最常需要调整的内核参数，分网络、内存文件句柄、进程信号、磁盘文件系统四个维度，配有判断方法、修改命令、验证手段和回滚思路。调参之前先做好一件事：把当前值备份。

调参前准备：备份与回滚

所有内核参数都在/proc/sys/下，通过sysctl命令读写。生产环境修改前，务必记录原始值。

# 备份所有内核参数到文件
sysctl -a > /backup/sysctl_backup_$(date +%Y%m%d_%H%M%S).conf

# 查看单个参数的当前值
sysctl net.core.somaxconn

# 查看多个参数（快速巡检）
sysctl net.core.somaxconn net.core.netdev_max_backlog net.ipv4.tcp_max_syn_backlog 
 net.ipv4.ip_local_port_range fs.file-max vm.swappiness

回滚时用备份文件恢复：

# 回滚所有参数（慎用，会一次性覆盖，建议按需回滚单个）
sysctl -p /backup/sysctl_backup_20260521_143000.conf

# 回滚单个参数
sysctl -w net.core.somaxconn=128

调参的永久生效方式是写入/etc/sysctl.conf或/etc/sysctl.d/下的配置文件，如/etc/sysctl.d/99-custom.conf。写入后执行sysctl -p /etc/sysctl.d/99-custom.conf使其生效，不需要重启系统。

以下按类别逐一说明每项参数。

第一类：网络相关参数

网络是调参需求最密集的区域。高并发服务器出问题，十有八九在网络队列、端口范围、连接复用、缓冲区大小上。

1. net.core.somaxconn —— 全连接队列上限

作用原理：当客户端发起 TCP 连接，服务端收到 SYN 包后会在内核里创建一个半连接（half-open）放入 Accept 队列，调用accept()后再放入全连接队列等待应用取走。全连接队列的最大长度受net.core.somaxconn和应用程序listen()第二个参数的双重限制，取两者较小值。

默认值：128（大多数发行版）

现象：Nginx 报错connect() failed (99: Cannot assign requested address)或 upstream 响应 502，原因是 Nginx 向上游服务建立连接时发现本地没有可用端口；又或者全连接队列满了，客户端 SYN+ACK 被丢弃，表现为connect 超时。

调优方法：

# 查看当前值
sysctl net.core.somaxconn

# 临时生效（重启失效）
sysctl -w net.core.somaxconn=65535

# 永久生效
echo"net.core.somaxconn = 65535">> /etc/sysctl.d/99-custom.conf
sysctl -p /etc/sysctl.d/99-custom.conf

应用侧配合：Nginx 配置中listen 80 backlog=65535;需要和内核参数匹配，否则以较小值为准。MySQL 的back_log参数同理。

验证方法：

# 查看各端口的全连接队列长度（需要 ss 命令）
ss -ltn sport = :80

# 确认内核值已生效
sysctl net.core.somaxconn

# 压测时观察是否有连接堆积
watch -n1"ss -s | grep -i est"

2. net.core.netdev_max_backlog —— 网卡收包队列长度

作用原理：当网卡收到数据包的速度快于内核协议栈处理速度时，超出的包会放入网卡的 backlog 队列，等待软中断处理。这个队列的长度由net.core.netdev_max_backlog控制。如果队列满了，新来的数据包被丢弃，表现为丢包。

默认值：1000（视发行版而定，RHEL/CentOS 可能是 1000，Ubuntu/Debian 可能是 1000 或 500）

现象：netstat -i或ifconfig看到 RX errors、RX drops、RX overruns 计数不断增长；业务延迟增加但 CPU 不高；大量 TIME_WAIT 连接。

调优方法：

sysctl -w net.core.netdev_max_backlog=65535
echo"net.core.netdev_max_backlog = 65535">> /etc/sysctl.d/99-custom.conf

配合检查：用cat /proc/net/softnet_stat查看每列 CPU 的 softnet 统计，第三列是 drops 计数，应该在压测或高负载下观察是否增长。

3. net.ipv4.tcp_max_syn_backlog —— 半连接队列长度

作用原理：TCP 三次握手中，服务端收到 SYN 后创建半连接放入半连接队列（也称 SYN queue），队列长度受net.ipv4.tcp_max_syn_backlog控制。半连接队列满了则新 SYN 被丢弃，客户端表现是 SYN 超时重传。

注意：该参数在 Linux 4.3 以后受net.core.somaxconn限制，实际队列长度为两者较小值。

默认值：128（CentOS/RHEL 6）或 1280（部分新版本）

现象：大量 SYN 包进来时客户端连接失败；在netstat -s中看到SYNs to LISTEN sockets dropped计数增长。

调优方法：

sysctl -w net.ipv4.tcp_max_syn_backlog=65535
echo"net.ipv4.tcp_max_syn_backlog = 65535">> /etc/sysctl.d/99-custom.conf

4. net.ipv4.ip_local_port_range —— 客户端可用端口范围

作用原理：当 Linux 作为客户端对外发起连接时，本地会分配一个临时源端口。端口范围默认是 32768-60999，共约 28000 多个端口。对于跑在服务器上的代理服务、爬虫、HTTP 客户端等场景，如果并发连接数逼近这个范围，会出现cannot assign requested address错误。

现象：Nginx 反向代理到 upstream 时报错；高并发 HTTP 客户端大量报无法建连；ss -s显示端口使用率接近上限。

调优方法：

# 查看当前范围
sysctl net.ipv4.ip_local_port_range

# 扩大范围，留更多可用端口
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
echo"net.ipv4.ip_local_port_range = 1024 65535">> /etc/sysctl.d/99-custom.conf

注意：低端口 1024 以下是系统保留端口，如果服务器同时有服务端监听 80/443 端口，这里改成 1024 起不会影响服务端监听。但部分业务可能依赖 1024-60000 范围内的端口做通信，需确认后再改。

验证：

# 查看当前范围
sysctl net.ipv4.ip_local_port_range

# 查看已使用端口数（快速估算）
ss -tan | awk'{print $4}'| cut -d: -f2 | sort -n | tail -1
ss -tan state established | wc -l

5. net.ipv4.tcp_fin_timeout 和 net.ipv4.tcp_keepalive_* —— 连接回收策略

作用原理：TCP 连接关闭时，主动关闭方会进入 TIME_WAIT 状态，持续tcp_fin_timeout秒（默认 60 秒）。在这期间，连接占用的本地端口无法释放。高并发短连接场景下，TIME_WAIT 连接堆积会迅速耗尽端口范围。

相关参数组：

net.ipv4.tcp_fin_timeout：主动关闭方 FIN_WAIT_2 状态的超时，默认 60 秒

net.ipv4.tcp_keepalive_time：TCP 保活探测空闲时间，默认 7200 秒（2小时）

net.ipv4.tcp_keepalive_intvl：保活探测重试间隔，默认 75 秒

net.ipv4.tcp_keepalive_probes：保活探测重试次数，默认 9 次

现象：服务器出现大量 TIME_WAIT 连接（netstat -an | grep TIME_WAIT | wc -l几万甚至几十万）；端口范围被占满导致无法建立新连接；短连接服务频繁报Address already in use。

调优方法：

# 降低 FIN_WAIT 超时，加速连接回收
sysctl -w net.ipv4.tcp_fin_timeout=15
echo"net.ipv4.tcp_fin_timeout = 15">> /etc/sysctl.d/99-custom.conf

# 如果是 Nginx 作为反向代理，配合 upstream 配置：
# upstream 配置中加入 keepalive 32; 减少短连接建立

风险提醒：tcp_fin_timeout设置过短可能导致正常连接在数据传输未完成时提前关闭，引发数据丢失。如果业务侧有长连接或大文件传输，谨慎调整。

tp_tcp_keepalive 配置：

# 保活时间缩短到 5 分钟（适合通过负载均衡器长连接的场景）
sysctl -w net.ipv4.tcp_keepalive_time=300
sysctl -w net.ipv4.tcp_keepalive_intvl=30
sysctl -w net.ipv4.tcp_keepalive_probes=5

6. net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle —— TIME_WAIT 复用

作用原理：tcp_tw_reuse允许内核在特定条件下将新的连接复用处于 TIME_WAIT 状态的 socket 资源，主要用于客户端。tcp_tw_recycle允许快速回收 TIME_WAIT 连接，在服务端同时处理大量短连接时效果明显。

注意：tcp_tw_recycle在 NAT 环境下会导致客户端连接异常，因为它会忽略同一 IP 不同时间戳的连接。在云环境或负载均衡环境下，强烈建议保持关闭，只开tcp_tw_reuse。

默认值：tcp_tw_reuse= 0 或 1（视发行版），tcp_tw_recycle= 0

现象：TIME_WAIT 连接堆积，端口耗尽，cannot assign requested address。

调优方法：

sysctl -w net.ipv4.tcp_tw_reuse=1
echo"net.ipv4.tcp_tw_reuse = 1">> /etc/sysctl.d/99-custom.conf

# 关闭 tcp_tw_recycle（云环境和 NAT 环境下必须关闭）
sysctl -w net.ipv4.tcp_tw_recycle=0

验证：

# 压测后观察 TIME_WAIT 连接数量
netstat -an | awk'/^tcp/ {print $6}'| sort | uniq -c | sort -rn | head -10

# 观察端口复用情况
ss -s

7. net.core.rmem_max / net.core.wmem_max / net.ipv4.tcp_rmem / net.ipv4.tcp_wmem —— TCP 缓冲区大小

作用原理：Linux TCP 协议栈为每个连接维护发送缓冲区和接收缓冲区。缓冲区太小会导致高延迟（数据等待累积），缓冲区太大会占用过多内存。默认的内存自动调整机制会按需分配，但默认最大值对高吞吐场景不够用。

参数说明：

net.core.rmem_default：默认接收缓冲区大小

net.core.rmem_max：接收缓冲区最大大小（所有协议）

net.core.wmem_default：默认发送缓冲区大小

net.core.wmem_max：发送缓冲区最大大小（所有协议）

net.ipv4.tcp_rmem：TCP 接收缓冲区配置（min / default / max）

net.ipv4.tcp_wmem：TCP 发送缓冲区配置（min / default / max）

现象：高吞吐场景下带宽利用率低，明明网卡是万兆但实际流量上不去；或者时延抖动大。

调优方法（适用于万兆网卡高吞吐场景）：

# 增大 TCP 缓冲区上限
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

写入配置：

cat >> /etc/sysctl.d/99-custom.conf << 'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
EOF
sysctl -p /etc/sysctl.d/99-custom.conf

验证：

# 查看 TCP 连接的实际缓冲区使用情况
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem

# 压测观察吞吐和延迟变化
iperf3 -c  -t 60 -R # 测接收带宽

风险提醒：增大这些值会占用更多内存。确认服务器有足够 RAM，且不能无限增大，要在内存容量和性能间取平衡。

8. net.ipv4.conf.default.rp_filter 和 net.ipv4.conf.all.rp_filter —— 反向路径过滤

作用原理：反向路径过滤（Reverse Path Filtering）是 Linux 内核的一种安全机制，用于防止 IP 欺骗攻击。当收到一个数据包时，内核检查该数据包的源地址是否应该从该网卡进来。如果来源路由不符合预期，rp_filter 会丢弃该包。值 0 表示关闭，1 表示严格模式，2 表示宽松模式。

现象：服务器在多网卡、VPN、负载均衡或 Docker 环境下出现奇怪的连接问题——数据包进来了但应用收不到；同网段通信正常但跨网段通信失败；服务启动后部分 IP 无法访问。

典型故障场景：Docker 默认创建的 bridge 网络默认使用 172.17.0.0/16，如果服务器的 rp_filter 设置为严格模式，可能导致容器访问外部网络时数据包被丢弃。

调优方法：

# 查看当前值
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

# 如果需要关闭（容器、VPN、多路径场景）
sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.default.rp_filter=2

# 或者针对单个网卡配置
sysctl -w net.ipv4.conf.eth0.rp_filter=2

安全提醒：关闭反向路径过滤会降低对 IP 欺骗攻击的防护能力。只在确认有实际需求（容器、VPN、多网卡绑定）的场景下才关闭，并在其他接口上保持默认严格模式。

永久配置：

cat >> /etc/sysctl.d/99-custom.conf << 'EOF'
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
EOF

9. net.ipv4.conf.all.accept_source_route 和 net.ipv4.conf.default.accept_source_route —— 禁用源路由

作用原理：源路由是一种允许发送者指定数据包经过的网络路径的机制。攻击者可以利用源路由来绕过网络访问控制，因此生产环境应禁用。

默认值：大多数发行版默认关闭，但应检查确认。

调优方法：

# 确认已禁用（值为 0）
sysctl net.ipv4.conf.all.accept_source_route
sysctl net.ipv4.conf.default.accept_source_route

# 如需开启（不建议），设为 0
sysctl -w net.ipv4.conf.all.accept_source_route=0

永久配置：

cat >> /etc/sysctl.d/99-custom.conf << 'EOF'
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
EOF

第二类：内存与文件句柄相关参数

10. fs.file-max 和 fs.nr_open —— 系统级文件句柄上限

作用原理：fs.file-max是系统级别的最大文件句柄数，fs.nr_open是单个进程最大能打开的文件句柄数。进程调用open()或socket()都会消耗一个文件描述符（file descriptor）。默认的fs.file-max通常足够，但某些高并发服务（如 Nginx、MySQL Proxy）可能达到上限。

默认值：fs.file-max默认约几百万，fs.nr_open默认 1048576（100万）。

现象：进程日志报Too many open files；ls /proc//fd | wc -l接近系统限制；cat /proc/sys/fs/file-nr显示已分配句柄数接近上限。

调优方法：

# 查看当前值
sysctl fs.file-max fs.nr_open

# 查看已使用情况
cat /proc/sys/fs/file-nr
# 输出格式：已分配文件句柄数 / 已分配但未使用数 / 最大句柄数

# 提高系统级上限
sysctl -w fs.file-max=2097152
echo"fs.file-max = 2097152">> /etc/sysctl.d/99-custom.conf

进程级限制配合：系统级fs.nr_open是上限，进程级限制在/etc/security/limits.conf中配置：

# /etc/security/limits.conf
root soft nofile 1048576
root hard nofile 1048576
* soft nofile 1048576
* hard nofile 1048576

注意：limits.conf中的nofile值不能超过fs.nr_open。

验证：

# 查看进程打开的句柄数
ls /proc/$(pgrep -n nginx)/fd | wc -l

# 查看系统级句柄使用情况
cat /proc/sys/fs/file-nr

# 查看各进程句柄占用排名
lsof -n 2>/dev/null | awk'{print $1,$2}'| sort | uniq -c | sort -rn | head -20

11. vm.swappiness —— 内存交换倾向

作用原理：vm.swappiness控制系统使用 swap 的激进程度，范围 0-100。值越大越倾向于把不活跃的内存页换出到 swap 区，值越小越倾向于优先回收 page cache 和 slab 对象而不是换页。默认 60。

现象：物理内存还有剩余但系统开始大量使用 swap；Java 进程被 OOM Killer 杀掉；MySQL InnoDB Buffer Pool 被换出导致性能急剧下降。

典型问题：MySQL 和 PostgreSQL 数据库进程被换出后性能雪崩，因为数据库依赖常驻内存的 Buffer Pool 和查询缓存。容器环境下也常出现，宿主机内存不足时容器被悄悄换出。

调优方法：

# 查看当前值
sysctl vm.swappiness

# 临时修改（生产环境建议先临时测试再永久）
sysctl -w vm.swappiness=10

# 永久配置（数据库和内存敏感场景建议 10 或更低）
echo"vm.swappiness = 10">> /etc/sysctl.d/99-custom.conf

重要提醒：vm.swappiness=0在 Linux 3.5 之前是完全禁止使用 swap，3.5 之后变为"只有在极端情况下才使用 swap"。生产环境通常设置 10-30 之间，既保留一定 swap 能力防止 OOM，又避免过早换出活跃内存。

验证：

# 查看 swap 使用情况
free -h
# 查看各进程 swap 占用
forfin/proc/*/status;doawk'/VmSwap/{if($2>0)print $0}'$f;done| sort -k2 -rn | head -10

12. vm.dirty_ratio 和 vm.dirty_background_ratio —— 脏页回写策略

作用原理：当进程写文件时，数据先写入 page cache，形成"脏页"（dirty pages）。内核会定期或当脏页比例达到阈值时将数据写回磁盘。vm.dirty_background_ratio是触发后台回写的内存比例，vm.dirty_ratio是触发同步写（阻塞进程）的比例。

默认值：vm.dirty_background_ratio默认 10，vm.dirty_ratio默认 20。

现象：大量写入后突然卡顿（pdflush/flush 进程在做同步写）；数据库事务提交后数据未刷盘（取决于 MySQL 的 innodb_flush_log_at_trx_commit 配置）；进程在写大文件时阻塞时间过长。

调优思路：

对 MySQL：建议降低这两个值，让数据更频繁地写回磁盘，减少数据丢失窗口（但会降低写入性能）。配合 MySQL 的innodb_flush_log_at_trx_commit一起看。

对日志写入、大文件顺序写：可以适当提高阈值，让更多数据留在 page cache 中提高吞吐。

对高可靠数据库：降低阈值，接近 5/10 级别。

调优方法：

# 降低触发同步写的阈值（适合数据库场景，更快写盘）
sysctl -w vm.dirty_background_ratio=5
sysctl -w vm.dirty_ratio=10
echo"vm.dirty_background_ratio = 5">> /etc/sysctl.d/99-custom.conf
echo"vm.dirty_ratio = 10">> /etc/sysctl.d/99-custom.conf

验证：

# 查看当前脏页数量和内存占比
cat /proc/meminfo | grep -E"(Dirty|Writeback)"

# 查看 pdflush/flush 进程活动
ps aux | grep -E"flush|kworker"| head -10

13. vm.vfs_cache_pressure —— 文件系统缓存回收压力

作用原理：内核在内存压力下会回收 page cache（文件缓存）和 inode/dentry 缓存（VFS 缓存）。vm.vfs_cache_pressure控制回收倾向：100 是默认值（公平回收），值越大越倾向于尽快回收缓存，值越小越倾向于保留缓存。

现象：服务器重启后 MySQL 性能急剧下降（page cache 被回收，Buffer Pool 未预热）；频繁访问的文件（如字典、日志）反复被读入内存又换出；slab 占用过高导致内存不足。

调优方法：

# 查看当前值
sysctl vm.vfs_cache_pressure

# 如果是数据库服务器，倾向于保留缓存
sysctl -w vm.vfs_cache_pressure=50
echo"vm.vfs_cache_pressure = 50">> /etc/sysctl.d/99-custom.conf

14. kernel.shmmax 和 kernel.shmall —— 共享内存参数

作用原理：共享内存是进程间通信的一种高性能方式，数据库（MySQL 的 InnoDB Buffer Pool 在 SGA 模式下使用）、Redis（部分部署方式）、Oracle 等都依赖共享内存。kernel.shmmax是单个共享内存段的最大字节数，kernel.shmall是系统范围内共享内存页的总和。

现象：MySQL 启动时报InnoDB: Cannot allocate memory for the buffer pool；共享内存分配失败；Redis 启动时报failed to allocate SMART memory。

调优方法：

# 查看当前值
sysctl kernel.shmmax kernel.shmall

# 临时修改（共享内存建议设大一些，单位是字节）
# shmmax 设置为 64GB：64 * 1024 * 1024 * 1024 = 68719476736
sysctl -w kernel.shmmax=68719476736
sysctl -w kernel.shmall=16777216

# 永久配置
cat >> /etc/sysctl.d/99-custom.conf << 'EOF'
kernel.shmmax = 68719476736
kernel.shmall = 16777216
EOF

计算公式：kernel.shmall的单位是页（page），在 x86_64 架构下 page size 为 4096 字节。64GB / 4096 = 16777216 页。

验证：MySQL 查看 SGA 大小：

SHOWVARIABLESLIKE'innodb_buffer_pool_size';
SHOWVARIABLESLIKE'innodb_log_file_size';

确保 SGA + 日志缓冲 + 其他共享内存不超过kernel.shmmax。

15. kernel.msgmnb 和 kernel.msgmni —— 消息队列参数

作用原理：消息队列是 System V IPC 机制之一，部分老式应用和中间件仍在使用。kernel.msgmnb是单个消息队列的最大字节数，kernel.msgmni是系统范围内最大消息队列数量。

现象：较为少见，多见于老的中间件或自定义 IPC 应用报 "Message queue error"。

调优方法：

sysctl -w kernel.msgmnb=65536
sysctl -w kernel.msgmni=1024
echo"kernel.msgmnb = 65536">> /etc/sysctl.d/99-custom.conf
echo"kernel.msgmni = 1024">> /etc/sysctl.d/99-custom.conf

16. net.core.rmem_default 和 net.core.wmem_default —— 默认缓冲区大小

作用原理：net.core.rmem_default和net.core.wmem_default是各协议默认的套接字接收/发送缓冲区大小，通常不需要手动设置，因为 Linux 会通过net.ipv4.tcp_rmem和net.ipv4.tcp_wmem自动调整。只在特殊场景下作为兜底值。

调优方法（一般保持默认值即可，但如果默认自动调整的中间值偏小）：

sysctl -w net.core.rmem_default=262144
sysctl -w net.core.wmem_default=262144

第三类：进程与信号相关参数

17. kernel.pid_max —— 最大进程 ID

作用原理：Linux 中每个进程和线程都有唯一的 PID，内核用pid_max限制 PID 的上限。达到上限后 PID 会回绕，可能导致旧进程信息被错误复用。

默认值：32768（32位）和 4194304（64位），后者足够绝大多数场景。

现象：机器上跑着大量容器或 Java 进程（每个容器对应一个 PID namespace，宿主机上进程数可能非常多）；ps看到 PID 接近 32768；或者在高线程数场景下（如 Tomcat 每个请求一个线程）进程数快速增长。

调优方法：

# 查看当前值
sysctl kernel.pid_max

# 扩大上限
sysctl -w kernel.pid_max=4194304
echo"kernel.pid_max = 4194304">> /etc/sysctl.d/99-custom.conf

验证：

# 查看当前最大 PID
cat /proc/sys/kernel/pid_max

# 查看当前进程/线程总数
ps -eLf | wc -l
# 或
ps -eo pid,tid,cmd | wc -l

18. kernel.threads-max —— 最大线程数

作用原理：kernel.threads-max限制系统范围内最大线程数。默认值是kernel.pid_max的两倍。高线程数场景（如 Nginx（每个连接一个 worker）、Java 应用（每个请求一个线程）、Python Gevent 应用）容易触达上限。

现象：fork: Resource temporarily unavailable；创建线程失败；系统日志报kernel request for more threads。

调优方法：

# 查看当前值
sysctl kernel.threads-max

# 临时调整
sysctl -w kernel.threads-max=4194304
echo"kernel.threads-max = 4194304">> /etc/sysctl.d/99-custom.conf

配合进程级限制：/etc/security/limits.conf中也需要调整nproc（最大进程/线程数）：

* soft nproc 4194304
* hard nproc 4194304

验证：

# 查看当前线程总数
ps -eLf | wc -l

# 按用户查看线程数
ps -eLf | awk'{print $1}'| sort | uniq -c | sort -rn | head -10

19. kernel.sem —— 信号量参数

作用原理：System V 信号量（semaphore）是进程间同步机制之一，数据库和某些中间件依赖它。kernel.sem包含四个值：SEMMSL（每个信号量集最大信号量数）、SEMMNS（系统最大信号量数）、SEMOPM（单个 semop 调用最大操作数）、SEMMNI（最大信号量集数量）。

现象：少见，通常是 Oracle、PostgreSQL 等数据库在启动或高并发时遇到。

调优方法：

# 查看当前值
sysctl kernel.sem

# 推荐值（适合大多数数据库）
# 格式：SEMMSL SEMMNS SEMOPM SEMMNI
sysctl -w kernel.sem="250 32000 100 256"
echo"kernel.sem = 250 32000 100 256">> /etc/sysctl.d/99-custom.conf

第四类：磁盘与文件系统参数

20. net.ipv4.icmp_echo_ignore_broadcasts 和 net.ipv4.icmp_ratelimit —— ICMP 防护

作用原理：ICMP 广播/多播可以被利用做放大攻击（Smurf Attack）。icmp_echo_ignore_broadcasts设为 1 时忽略 ICMP 广播 echo 请求（ping 广播地址）。icmp_ratelimit限制 ICMP 响应速率，防止 ICMP 洪水。

调优方法：

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
sysctl -w net.ipv4.icmp_ratelimit=1000
echo"net.ipv4.icmp_echo_ignore_broadcasts = 1">> /etc/sysctl.d/99-custom.conf
echo"net.ipv4.icmp_ratelimit = 1000">> /etc/sysctl.d/99-custom.conf

注意：icmp_ratelimit的单位是"每 jiffy"，具体时间长度取决于内核 HZ 设置，通常 1000 已经相当宽松。

生产环境操作规范

永久生效的标准写法

将所有参数集中写入一个专属配置文件，不要散落在多处：

cat > /etc/sysctl.d/99-custom.conf << 'EOF'
# 网络参数
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# 内存与文件句柄
fs.file-max = 2097152
vm.swappiness = 10
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.vfs_cache_pressure = 50
kernel.shmmax = 68719476736
kernel.shmall = 16777216
kernel.msgmnb = 65536
kernel.msgmni = 1024
net.core.rmem_default = 262144
net.core.wmem_default = 262144

# 进程与信号
kernel.pid_max = 4194304
kernel.threads-max = 4194304
kernel.sem = 250 32000 100 256

# ICMP 安全
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ratelimit = 1000
EOF

# 使配置生效
sysctl -p /etc/sysctl.d/99-custom.conf

验证脚本

写一个简单的验证脚本，逐项比对预期值：

#!/bin/bash
# verify_sysctl.sh - 验证内核参数是否符合预期值

EXPECTED=(
"net.core.somaxconn=65535"
"net.core.netdev_max_backlog=65535"
"net.ipv4.tcp_max_syn_backlog=65535"
"fs.file-max=2097152"
"vm.swappiness=10"
"kernel.pid_max=4194304"
)

foritemin"${EXPECTED[@]}";do
 param="${item%%=*}"
 expected="${item##*=}"
 actual=$(sysctl -n"$param"2>/dev/null)
if[["$actual"=="$expected"]];then
 echo"[OK]$param=$actual"
else
 echo"[FAIL]$param: expected$expected, got$actual"
fi
done

分步上线流程

高危修改（如vm.swappiness、net.ipv4.tcp_tw_reuse）建议分步上线：

在一台机器上临时修改（sysctl -w），观察 24-48 小时无异常

确认无误后写入/etc/sysctl.d/99-custom.conf

使用 Ansible 或 Salt 批量推送到同类型机器

批量推送时建议使用 rolling restart 策略，分批重启相关服务

回滚操作

如果修改后出现异常，优先用备份的回滚单个参数，而不是重启机器：

# 查看备份文件
ls -lt /backup/sysctl_*.conf

# 回滚单个参数
sysctl -w net.core.somaxconn=128

# 如果需要完全恢复备份
sysctl -p /backup/sysctl_backup_20260521_143000.conf

总结：20 项参数速查清单

#	参数	推荐值	适用场景	风险
1	net.core.somaxconn	65535	高并发 Web 服务	中
2	net.core.netdev_max_backlog	65535	高吞吐网卡服务器	低
3	net.ipv4.tcp_max_syn_backlog	65535	高并发短连接服务	低
4	net.ipv4.ip_local_port_range	1024 65535	代理/爬虫/客户端	中
5	net.ipv4.tcp_fin_timeout	15	大量短连接场景	中
6	net.ipv4.tcp_tw_reuse	1	大量 TIME_WAIT 堆积	低
7	net.ipv4.tcp_tw_recycle	0	NAT/云环境必为 0	高
8	net.core.rmem_max/wmem_max	16777216	万兆网卡高吞吐	中
9	net.ipv4.conf.*.rp_filter	2	容器/Docker 环境	中
10	fs.file-max	2097152	高并发进程	低
11	vm.swappiness	10	数据库服务器	高
12	vm.dirty_ratio	10	数据库/高可靠场景	中
13	vm.vfs_cache_pressure	50	数据库服务器	中
14	kernel.shmmax/shmall	按需调大	共享内存数据库	中
15	kernel.pid_max	4194304	高线程数应用	低
16	kernel.threads-max	4194304	高线程数应用	中
17	kernel.sem	250 32000 100 256	数据库	低
18	net.ipv4.icmp_echo_ignore_broadcasts	1	所有服务器	低
19	net.ipv4.conf.*.accept_source_route	0	安全加固	低
20	vm.dirty_background_ratio	5	数据库/高可靠场景	中

实战排查路径汇总

当遇到网络/连接问题需要快速定位时，按以下顺序检查内核参数：

连接无法建立：net.core.somaxconn→net.ipv4.tcp_max_syn_backlog→fs.file-max（句柄耗尽）

TIME_WAIT 堆积：net.ipv4.tcp_fin_timeout→net.ipv4.tcp_tw_reuse→net.ipv4.ip_local_port_range

端口耗尽：net.ipv4.ip_local_port_range→net.ipv4.tcp_tw_reuse→net.core.somaxconn（accept 队列满导致连接堆积）

丢包/网络卡顿：net.core.netdev_max_backlog→net.core.rmem_max/wmem_max→cat /proc/net/softnet_stat

内存换页严重：vm.swappiness→vm.dirty_ratio→vm.vfs_cache_pressure

进程/线程数达上限：kernel.pid_max→kernel.threads-max→ulimit -u / nproc

数据库共享内存不足：kernel.shmmax→kernel.shmall→ipcs -m

所有调参操作建议在业务低峰期执行，并在修改后通过监控观察 24 小时内是否有异常。