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%但await不高？可能是队列深度不够）、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分钟）。每次变更记日志，方便回溯。
基本上就这些。不复杂但容易忽略——优化的本质是让资源用在刀刃上，而不是让系统更“炫酷”。
