Linux服务器性能调优：从负载排查到内核参数调整的实操流程

Linux 服务器性能调优不是先改参数，而是先确认瓶颈在哪。
多数“服务器变慢”的问题，根源是某个进程吃满 CPU、磁盘 I/O 排队、内存被耗尽或连接数打满，盲目套用网上的 sysctl 优化模板反而可能让问题更隐蔽。
下面按“看现状、找原因、做调整、再验证”的顺序展开，适合刚接手服务器或遇到负载偏高的零基础用户。

先确认系统现状和调优边界

调优前先记录基线，否则改完不知道有没有变好。
登录服务器后依次执行：

uptime
free -h
df -h
iostat -x 1 3

uptime 里的 load average 表示 1、
5、
15 分钟的平均负载，
单核 CPU 上持续超过 1 就说明有排队。free -h 重点看 available 这一列，
而不是 free。df -h 看磁盘是否接近写满，
分区满会连带引发服务异常。iostat 需要 sysstat 包，
关注 %util 和 await，
前者长期接近 100% 说明磁盘是瓶颈。

如果这些命令提示找不到，用包管理器安装：

# Debian/Ubuntu
apt update && apt install -y sysstat
# CentOS/RHEL
 yum install -y sysstat

调优前提：先做快照或备份，涉及重启服务的操作安排在业务低峰期。
改内核参数前，记录当前值，方便回滚。

定位真正吃资源的进程

知道哪类资源紧张后，用 top 或 htop 找到具体进程：

top -o %CPU

进入后按 P 按 CPU 排序，按 M 按内存排序。
找到 PID 后，用 ps 确认它属于哪个服务：

ps -p  -o pid,ppid,user,%cpu,%mem,cmd

常见情况分三类：

• CPU 高：多为程序死循环、请求量突增或加密计算，先看应用日志再考虑限流。
• 内存高：看是否有进程持续增长，结合 dmesg | grep -i oom 确认是否触发过 OOM Killer。
• I/O 高：用 iotop 查看哪个进程在大量读写，数据库和日志写入是常见来源。

若是 Web 服务连接数异常，检查端口连接状态：

ss -s
ss -antp | awk '{print $1}' | sort | uniq -c

连接数暴涨时不要直接调大 backlog，先确认是正常流量还是攻击。

按瓶颈类型做针对性调整

不同瓶颈对应的调优动作差别很大，下面按资源类型分开说。

CPU 与进程调度：优先优化应用本身，比如调整线程池、减少同步阻塞。
系统层面可以检查运行队列，但不要随意修改调度器参数。

内存与交换：如果 free -h 显示 swap 被大量使用，且 vm.swappiness 偏高，可以适度降低交换倾向：

# 临时生效
sysctl -w vm.swappiness=10
# 永久生效
echo 'vm.swappiness=10' >> /etc/sysctl.conf
sysctl -p

注意：降低 swappiness 不等于禁用 swap，完全禁用可能导致内存不足时进程被杀。

网络连接：高并发短连接场景下，可检查 TIME_WAIT 数量。
若数量很大，再考虑调整：

sysctl -w net.ipv4.tcp_tw_reuse=1

tcp_tw_recycle 在新版内核中已移除，不要照搬老教程。
调整前确认内核版本：

uname -r

文件句柄：服务报 “Too many open files” 时，先看当前限制：

ulimit -n
cat /proc//limits | grep 'open files'

永久调整需同时改 /etc/security/limits.conf 和 systemd 服务的 LimitNOFILE，只改一处往往不生效。

调优后的验证和回滚思路

每做一项调整，间隔几分钟再观察，避免同时改多项导致无法判断哪项起作用：

uptime
free -h
ss -s

对比调优前的基线数据，看 load、available 内存、TIME_WAIT 数量是否朝预期方向变化。
若某项指标变差，立即回滚该参数。
回滚方式就是删掉 /etc/sysctl.conf 中新增的行，执行 sysctl -p，或把服务配置文件恢复后重启服务。

验证原则：不只看单个数字，要结合业务表现。
比如接口响应时间、错误率、超时次数，这些比单纯看 load 更有参考价值。

容易踩的坑

• 直接复制网上的“一键优化脚本”，里面可能包含已废弃参数或与当前内核不兼容的选项。
• 把 load average 高等同于 CPU 不够，实际可能是磁盘 I/O 等待。
• 只改 limits.conf 却忘了 systemd 服务有自己的限制，导致重启后句柄数又变回去。
• 在业务高峰期重启网络或数据库服务，造成连接中断。
• 调完参数不做记录，出问题时无法定位是哪次改动引起的。

常见疑问

调优后需要重启服务器吗？

sysctl 参数用 sysctl -p 即可生效，不需要重启。
但修改 limits.conf 或 systemd 配置后，需要重新登录或重启对应服务才生效。

load average 多少算正常？

没有绝对标准，要看 CPU 核数。
单核持续高于 1、多核持续高于核数，通常说明有排队。
结合 %util 和 await 一起判断更准确。

优化内核参数能提升多少性能？

取决于瓶颈类型。
如果瓶颈在应用代码或磁盘硬件，改内核参数帮助有限。
先定位瓶颈，再决定是否调参，顺序不能反。

如果正在处理 Linux 服务器性能调优，建议先把基线数据记录下来，再按资源类型逐项排查和调整，每步都留好回滚路径，比一次性套用模板更稳妥。