Linux服务器调优的核心答案：调优不是单点优化，而是围绕CPU、内存、磁盘I/O、网络和内核参数五个维度，结合具体业务场景做系统性配置调整，优先解决瓶颈问题，而不是盲目堆参数。
很多朋友一上来就问我“linux服务器调优有哪些”，其实这个问题背后通常藏着更具体的需求：网站访问慢、数据库响应延迟、并发扛不住，或者就是单纯想榨干现有硬件的性能，咱们先把调优这件事拆开看，它不是一个命令搞定的事，而是一套排查、定位、调整、验证的循环流程。
调优前的先决条件：你得先知道瓶颈在哪
业内专家指出,不做压测和监控就谈调优，等于蒙着眼睛开车，在动手改任何参数之前，先花半小时把现状摸清楚，这一步省不掉。
用这些命令给服务器做“体检”
登录服务器后,按顺序跑下面这几组命令，基本能定位80%的性能问题：
uptime：看系统平均负载，如果1分钟、5分钟、15分钟的负载值持续攀升，说明压力在累积free -h：看内存总量、已用、缓存和swap使用情况，重点观察swap是否被频繁占用df -h和iostat -x 1：前者看磁盘空间，后者看磁盘I/O利用率、等待队列长度vmstat 1 5：每秒采样一次，共5次，观察CPU空闲率、运行队列、块设备I/Osar -n DEV 1 3：查看网卡PPS（每秒数据包数）和带宽吞吐，判断是否被打满
拿到这些数据后,你就能回答一个关键问题：服务器到底是CPU不够、内存不足，还是磁盘在拖后腿，绝大多数“linux服务器卡顿怎么排查”的场景，跑完这套命令就能有个初步结论。
判断瓶颈类型的简易标准
CPU瓶颈：top 里 %us（用户态CPU）或 %sy（内核态CPU）持续超过70%，运行队列长期大于CPU核数。
内存瓶颈：free 显示可用内存趋近于零，同时swap的 si 和 so 数值频繁为非零。
磁盘I/O瓶颈：iostat 里 %util 接近100%，但CPU和内存还有余量，这时候加CPU没用，得换SSD或者优化读写逻辑。
按场景拆解：linux服务器性能调优命令实战
不同业务场景对资源的需求天差地别,你用Nginx做静态资源服务器，和用MySQL跑在线交易，调优策略完全是两个方向，下面按场景给一套可直接落地的方案。
高并发Nginx或Web服务场景
这类场景的痛点往往是文件句柄不够、TCP连接队列溢出、以及系统级限制。
第一步，调大文件描述符限制，编辑 /etc/security/limits.conf，添加：
soft nofile 65535
hard nofile 65535同时修改 /etc/sysctl.conf 中的内核参数：
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535执行 sysctl -p 生效，这一步能有效解决“并发一高就报Too many open files”的问题。
第二步，优化TCP连接复用，在 sysctl.conf 里加这几行，减少TIME_WAIT连接堆积：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 1200行业共识认为,开启 tcp_tw_reuse 比直接开 tcp_tw_recycle 更稳妥，后者在NAT环境下容易导致连接异常，这个坑不少运维踩过。
数据库或缓存服务场景
Redis、MySQL这类应用对内存和磁盘I/O的敏感度极高，调优思路是让数据尽量留在内存里，减少磁盘交互。
调整swap使用策略，系统默认的 swappiness=60 对数据库服务器来说太激进，会导致内存里的热数据被换到磁盘，临时生效：
sysctl vm.swappiness=1永久生效写入 /etc/sysctl.conf：
vm.swappiness = 1
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5dirty_ratio 控制进程写入脏数据的最大比例，dirty_background_ratio 控制后台刷盘阈值，这两个参数调好后，文件系统缓存能更高效地配合数据库的Buffer Pool工作，不会出现频繁卡顿。
文件服务器或日志采集场景
这类场景写操作密集,适合调整I/O调度器，机械硬盘用 deadline，SSD用 none（即 noop），查看当前调度器：
cat /sys/block/sda/queue/scheduler临时修改：
echo deadline > /sys/block/sda/queue/scheduler永久修改用 grubby 或直接改内核启动参数，不同发行版做法略有差异，另外还有个实用技巧：把日志写入到 tmpfs 或 ramdisk，减少对物理磁盘的磨损。
核心参数深度解析：linux内核参数优化的权重排序
内核参数几百个,真正值得你花时间调的其实就那十几个，咱们按优先级排个序，别把精力浪费在冷门参数上。
第一梯队：直接影响业务响应速度的参数
| 参数 | 默认值参考 | 推荐调整方向 | 适用场景 |
|---|---|---|---|
vm.swappiness |
60 | 10以下 | 数据库/缓存服务器 |
net.core.somaxconn |
128 | 1024以上 | Web服务/高并发入口 |
fs.file-max |
约内存页数一半 | 按并发数放大 | 所有服务器 |
net.ipv4.tcp_max_syn_backlog |
256 | 4096以上 | 抗突发流量 |
第二梯队：在特定场景下效果显著的参数
vm.overcommit_memory：Redis服务器建议设为1，避免申请大内存时被系统拒绝net.ipv4.tcp_rmem和tcp_wmem：调大TCP收发缓冲区，适合大文件传输kernel.sem：信号量限制，PostgreSQL或Oracle这类数据库要放大默认值vm.max_map_count：Elasticsearch经常碰到这个限制，默认65530根本不够用，设成262144是常见做法
有朋友问过“linux服务器调优有没有一套通用的参数模板”，我的答案很直接：模板只能作为起点，不能作为终点，同样是Nginx，你服务器内存是2GB还是64GB，tcp_rmem 的最优值能差出几倍，拿参数模板硬套，不如学会分析 sar 和 vmstat 的输出。
容易被忽略的软层调优：系统服务与编译优化
很多人盯着内核参数改,却忘了系统层面有些开关直接影响性能。
关掉不需要的守护进程
新装系统默认开机启动的服务里,有不少用不上的，用 systemctl list-unit-files --type=service --state=enabled 过一遍，像 postfix、cups、avahi-daemon 这类服务，如果业务用不到就 systemctl disable --now 关掉，省出来的内存不多，但减少了无谓的上下文切换。
调整CPU频率调节器
服务器环境别用 powersave，改成长跑模式，查看当前模式：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor改为性能模式：
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor这个操作对延迟敏感型应用很有效,你可能会看到响应时间下降10%~20%，在部分云厂商的共享实例上效果更明显，因为CPU频率被降频的情况太常见了。
应用层面顺手做的优化
后面追了一句“同样的代码，换台配置低的机器反而更快”，这种情况多半是旧机器开启了CPU性能模式，新机器还在节能模式，先把频率调节器对齐，再谈硬件差异。
还有一个常见优化是用 preload 或 vmtouch 把常用库文件预热到内存，减少冷启动时的磁盘读取，这个思路在Java应用上效果显著，因为JVM类库加载对I/O的依赖很重。
压缩和算法的选择也属于软层优化,同样一个页面，开Gzip压缩后传输体积能减小60%以上，配合 keepalive 连接复用，整体吞吐能提升一大截，这些不花一分钱硬件成本，但效果立竿见影。
Q&A：linux服务器调优的常见疑问
Q：调优之后性能没变化，问题出在哪？
A：先确认改的参数真的生效了，用 sysctl -a | grep 参数名 验证内核参数，用 ulimit -n 验证文件句柄限制，如果参数已生效但性能没变化，说明瓶颈不在你调的那个维度，比如磁盘I/O已经打满，你去调TCP缓冲区当然没效果，回到第一步，重新看 top 和 vmstat，把瓶颈定位准。
Q：生产环境可以直接调优吗？有没有风险？
A：不同参数风险等级不同，像 vm.swappiness、net.core.somaxconn 这类改动安全，加载后即时生效且可回退，但像 vm.dirty_ratio 调得过高，遇到断电会丢更多数据；net.ipv4.tcp_tw_reuse 在某些防火墙场景下会引发连接重置，建议先在压测环境验证，遵循“单次只改一个参数、保存旧值、观察一两天”的原则。
Q：linux内核参数优化和服务器硬件升级哪个优先？
A：优先做软件层调优，因为它零成本且能清晰看到边际收益，当软件层优化做完后，多项指标仍长期处于高位，再去升级对应硬件，比如内存使用率持续90%以上且swap频繁读写，加内存比调优更直接；如果CPU空闲但磁盘 %util 一直100%，换SSD才是正解，调什么参数都绕不过物理设备的性能极限。
调优是一条持续迭代的路,没有一劳永逸的“最优配置”，每上线一个新业务、每更新一次内核版本，之前调的参数都可能变得不再合适，建议每季度做一次性能复检，用这篇文章里的命令把服务器重新体检一遍，对比历史数据看趋势，把调优当成习惯，你的服务器才能始终跑在最佳状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/722754.html
