你买了一台配置不错的服务器，业务跑上去，却总觉得不够快。CPU 没用满，内存还有空，但网站就是慢。你加钱升级配置，好像也没改善多少。
问题出在哪？
性能调优不是堆硬件，也不是瞎改参数。它像剥洋葱，一层一层往下探：硬件、内核、应用、架构、监控——每个层次都有自己的瓶颈和优化空间。今天我们就一层层剥开，看看你的服务器到底还能榨出多少潜力。
第一层：硬件层——别让物理资源睡大觉
硬件是地基，地基没打好，上层怎么优化都有限。但很多人对硬件的理解停留在“核心越多越快，内存越大越好”。
CPU 不只是核心数
你有 32 核，但你的应用能同时用几个？很多旧软件是单线程的，核再多也白搭。更关键的是 NUMA：在多 CPU 服务器上，每个 CPU 有自己的内存。如果进程跑在 CPU0，却去访问 CPU1 的内存，速度会慢一大截。用 numactl 把进程绑定到指定 CPU 和内存节点，能减少跨 NUMA 访问。
还有 中断亲和性：网卡中断默认由 CPU0 处理，流量一大，CPU0 就忙不过来。把中断绑定到多个核心上，能大幅提升网络吞吐。
内存不止看容量，更要看带宽和通道
两条 64G 内存和八条 16G 内存，总容量一样，但后者带宽是前者的四倍（因为八通道）。对于内存密集型应用（数据库、Redis），带宽比容量更重要。
硬盘 IO 调度器
SSD 用 none 或 noop，机械盘用 deadline 或 cfq。配错了，IO 延迟能差几倍。
网卡队列
现代网卡支持多队列，让不同队列由不同 CPU 处理。用 ethtool -L 开启，配合中断亲和性，能榨干万兆网卡。
反常识数据：某公司把数据库从双路 E5 迁移到单路 Gold，因为避免了跨 NUMA，查询速度提升了 20%。硬件调对，比升级配置更管用。
第二层：内核层——操作系统的隐藏开关
操作系统默认配置是为了兼容性，而不是性能。你需要的性能，往往藏在几个内核参数里。
文件句柄限制
高并发下，Nginx 或 Java 进程需要打开大量文件。默认 1024 肯定不够，加到 100 万：
bash
fs.file-max = 1000000
TCP 调优
高并发短连接（比如 Web 服务）会产生大量 TIME_WAIT 连接，耗尽端口。开启复用和快速回收：
bash
net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 # 注意 NAT 环境下慎用 net.ipv4.tcp_fin_timeout = 30
监听队列长度
Nginx 默认 backlog 是 511，如果瞬时并发高，新连接会被丢掉。加大：
bash
net.core.somaxconn = 65535
内存管理vm.swappiness 控制使用交换分区的倾向。默认 60，对于数据库服务器，建议改到 10 甚至 0，避免内存被换出。vm.vfs_cache_pressure 控制目录和 inode 缓存的回收倾向，调低可减少磁盘 I/O。
一键优化脚本
很多运维会收集常用参数，写成脚本。你可以从网上找现成的，但要理解每个参数的作用，别盲目复制。
第三层：应用层——让软件跑得更顺
硬件和内核调好了，接下来是跑在上面的软件。
Nginx
- worker 进程数 = CPU 核心数（或者 auto）
- 开启 keepalive，减少连接建立开销
- 开启 gzip 压缩，但别压缩图片（效果差还费 CPU）
- 配置缓存：proxy_cache 或 fastcgi_cache，减少后端压力
PHP
- 开启 OpCache，避免每次请求都编译 PHP 代码
- 调整进程数：根据内存计算，每个 PHP-FPM 进程大约 30-50M，内存 / 单进程数 = 进程数上限
- 慢日志：找出执行慢的函数
数据库
- 索引：没索引的查询是灾难
- 查询缓存：8.0 之后已废弃，改用其他缓存策略
- 连接池：减少连接建立开销
- 慢查询日志：定期分析，优化那些执行慢的 SQL
反常识点：数据库调优中，索引往往比配置更重要。一个没索引的查询，能把 CPU 打满，而加个索引可能 CPU 降到 5%。
第四层：架构层——从单机到集群的进阶
单机性能有上限，到了一定程度，就得靠架构。
读写分离
主库写，从库读，分散压力。但要注意主从延迟。
分库分表
数据量太大，单表查询慢，拆成多表或多库。
缓存策略
- 本地缓存：如 Guava Cache，快但无法共享
- 分布式缓存：如 Redis，适合共享数据
- 缓存穿透/雪崩：空值缓存、布隆过滤器、随机过期时间
CDN
静态资源交给 CDN，源站压力骤减。图片、CSS、JS 都适合放 CDN。
异步处理
耗时操作（发邮件、生成报表）丢进消息队列，快速返回响应。
反常识观点：有时候加一层缓存比加十台服务器更管用。某电商网站把首页缓存 5 秒，QPS 从 2000 涨到 5 万，服务器没变。
第五层：监控层——用数据指导调优
没有监控的调优是盲人摸象。你必须知道瓶颈在哪，才能对症下药。
工具推荐
- netdata：轻量级实时监控，装上一分钟就能看到 CPU、内存、磁盘、网络的细粒度数据。
https://netdata.cloud - prometheus + grafana：适合长期趋势分析和告警，社区模板丰富。
https://prometheus.io
https://grafana.com - htop/iotop/iftop：命令行快速排查。
怎么看瓶颈
- CPU 高：看是用户态还是内核态，用户态高找应用，内核态高可能是系统调用频繁或网络问题。
- 内存高：看是 cache 还是应用占用，cache 高不是坏事，swap 使用率高才是警报。
- 磁盘 I/O 高：用 iostat 看 await 和 %util，await 高说明磁盘慢，%util 高说明负载重。
- 网络：看重传率、丢包率，用
netstat -s统计。
调优前后对比
改一个参数，跑一遍负载测试，对比数据。不要凭感觉，要让数字说话。
调优不是一劳永逸的事。业务在变，流量在变，今天的最佳实践可能明天就不适用。但这五个层次给你提供了思考框架：当性能出问题时，你知道从哪下手；当你想榨干机器时，你知道还有哪些地方可以挖。
去年帮一个客户调优，他的服务器配置和我的一样，但他的业务 QPS 只有我的三分之一。我按这五个层次帮他检查了一遍：硬件层——网卡中断没绑定；内核层——TIME_WAIT 堆积；应用层——数据库没索引；架构层——没加缓存；监控层——根本没监控。一层层改下来，QPS 翻了四倍。