net.core.somaxconn过小导致连接拒绝，vm.swappiness=0加剧OOM风险，fs.file-max与ulimit-n不匹配引发文件描述符耗尽，kernel.pid_max过低造成fork失败。
net.core.somaxconn 设为过小导致连接拒绝
当 net.core.somaxconn 值低于应用的连接请求洪峰，新 TCP 连接会被内核直接丢弃，表现为客户端收到 Connection refused 或超时，而服务端日志可能无明显错误。nginx、redis、postgresql 等监听 socket 的 backlog 依赖此值——即使应用层设置了 listen(sockfd, 1024)，实际生效上限仍受该参数限制。
实操建议：
- 用
sysctl net.core.somaxconn查看当前值，生产环境建议 ≥ 65535 - 修改后需执行
sysctl -p生效，仅改/etc/sysctl.conf不生效 - 某些容器环境（如 docker）需在
docker run中显式传入--sysctl，宿主机设置不影响容器内核参数
vm.swappiness 设为 0 在内存压力下引发 OOM
vm.swappiness=0 并不完全禁用 swap，而是让内核极度倾向直接回收 page cache 和 anon 内存；当物理内存耗尽且无法快速释放时，OOM killer 会立即触发，随机杀死进程（如数据库主进程）。这不是“更干净”，而是把 swap 的缓冲作用彻底移除，把内存压力转化为进程崩溃风险。
实操建议：
- 数据库类服务可设为
1（仅在必要时交换匿名页），通用服务器设10～30更稳妥 - 检查是否真有 swap 分区：
swapon --show，若无 swap，vm.swappiness实际无效 - 注意：kubernetes Pod 默认不继承宿主机
vm.swappiness，需通过securityContext.sysctls显式配置
fs.file-max 和 ulimit -n 不匹配造成文件描述符耗尽
fs.file-max 是系统级上限，而每个进程还受 ulimit -n（即 RLIMIT_NOFILE）约束。若只调高 fs.file-max 却未同步调整用户级限制，服务仍会在打开约 1024 个文件后报 Too many open files。systemd 服务尤其容易踩坑——其默认 LimitNOFILE 仍为 1024，与全局设置无关。
实操建议：
- 查进程当前限制：
cat /proc//limits | grep "Max open files" - 临时调高单进程限制：
ulimit -n 65536；永久生效需在/etc/security/limits.conf中写* soft nofile 65536 - systemd 服务必须单独配置：
LimitNOFILE=65536放入.service文件的[Service]段
kernel.pid_max 过低导致 fork 失败
当系统活跃进程数接近 kernel.pid_max（默认 32768），fork() 会返回 -EAGaiN，表现为脚本执行失败、crontab 任务静默退出、ssh 登录卡住。这不是负载高，而是 PID 号池枯竭——尤其在短生命周期进程高频启停（如 CI/CD 构建、FaaS 场景）时极易触发。
实操建议：
- 监控当前使用量：
ps -eL | wc -l（近似活跃线程数），或读/proc/sys/kernel/pid_max对比/proc/sys/kernel/threads-max - 设为 65536 或更高前，确认
threads-max足够（它受内存页数限制，一般无需手动调） - 容器中该参数默认继承宿主机，但若用
unshare --pid创建新 PID Namespace，需在 namespace 内重新设置
真正危险的不是参数没调，而是调了却没验证效果——比如改完 sysctl 忘记 reload，或以为改了全局就自动覆盖所有进程上下文。线上调参前，务必用 strace -e trace=clone,fork 或 /proc/ 中的 Threads 字段做实际观测。