linux性能优化 需先定位瓶颈再针对性调优：用 top、free、iostat、ss 快速诊断 CPU、内存、IO、网络；仅调整关键内核参数如 vm.swappiness、tcp_tw_reuse；应用层需匹配连接池、jvm GC、nginx配置；最后通过压测和 prometheus 持续验证效果。
Linux 性能优化不是 堆硬件或调几个参数就能见效的事，核心在于 理解瓶颈在哪、针对性干预、持续验证。盲目修改内核参数或关闭服务反而容易引发新问题。下面这些实践，都是从真实运维和压测场景中沉淀下来的“有效动作”，不讲虚的，直接上干货。
定位瓶颈：先看这四个指标
别一上来就改 sysctl.conf。用最轻量的命令快速圈定方向：
- CPU：top -H 看 线程 级占用，结合 pidstat -u 1 观察上下文切换（cs）和软中断（si）是否异常高
- 内存：free -h 关注 available 而非 total；cat /proc/meminfo | grep -E “Active|Inactive|SwapCached” 判断是否频繁换页
- 磁盘 IO：iostat -x 1 重点看 %util（接近 100% 但 awai t 不高？可能是队列深度不够）、r_await/w_await（明显升高说明存储响应慢）
- 网络：ss -s 查连接总数和状态分布；netstat -s | grep -i “retransmit|drop” 快速扫丢包和重传
内核参数调优：只动真正影响业务的几个
大部分默认值在现代内核（5.4+）已很合理。以下参数在高 并发、低延迟或大内存场景下值得检查：
- vm.swappiness=1：避免空闲内存被过度交换，SSD 环境尤其建议
- net.ipv4.tcp_tw_reuse=1：TIME_WAIT 套接字可复用于新建连接（需确保 NAT 环境时间戳开启）
- fs.file-max 和 fs.nr_open：按最大连接数预估，例如支撑 10 万连接，设为 131072 以上
- vm.dirty_ratio 和 vm.dirty_background_ratio：机械盘可适当调低（如 30/10），SSD 可略提高（60/20），减少突发刷盘卡顿
改完记得用 sysctl -p 生效，并写入 /etc/sysctl.conf 持久化。
应用层配合：别让系统替你背锅
很多“系统慢”其实是应用行为导致的：
- 数据库 连接池大小要匹配 ulimit -n，避免报“Too many open files”后降级为同步 IO
- java应用务必加 -XX:+UseG1GC -XX:MaxGCPauseMillis=200，避免 Full GC 卡住整个进程
- Nginx 静态文件服务开启 sendfile on; 和 tcp_nopush on;，减少内核态拷贝
- 日志避免同步刷盘（如 log4j2 的 immediateFlush=false），用 异步Appender+ 缓冲区
监控与迭代：优化不是一次性的
上线前用 stress-ng 或业务压测 工具 模拟负载，对比优化前后关键指标变化。重点关注：
- 99 分位响应时间是否下降
- 相同 QPS 下 CPU/IO 使用率是否降低
- 错误率（超时、连接拒绝等）是否收敛
把关键指标接入 Prometheus+Grafana，设置基线告警（比如 await > 50ms 持续 2 分钟）。每次变更记日志，方便回溯。
基本上就这些。不复杂但容易忽略——优化的本质是让资源用在刀刃上，而不是让系统更“炫酷”。
