Linux 服务器进阶运维：从性能瓶颈定位到系统调优

适合对象：有 Linux 基础、负责网站或业务服务器维护的运维人员。
核心目标：掌握服务器性能问题的排查思路，能够从 CPU、内存、磁盘、网络和进程多个维度定位瓶颈。

---

一、服务器性能优化不是盲目加配置

很多服务器出现卡顿、接口慢、网站打不开时，第一反应是：

是不是服务器配置不够？
要不要升级 CPU？
要不要加内存？

但在真实运维中，很多问题并不是硬件配置不足，而是由以下原因造成的：

• 某个进程异常占用 CPU
• 内存泄漏导致 swap 被打满
• 数据库慢查询拖垮系统
• 磁盘 IO 被日志或备份任务占满
• 网络连接数过高
• 文件句柄不足
• PHP-FPM、Nginx、MySQL 参数配置不合理
• 定时任务集中执行造成瞬时压力

所以进阶运维的第一步不是“调参数”，而是先定位瓶颈。

---

二、建立排查顺序

服务器故障排查最怕没有顺序。建议按照下面思路来：

系统负载
↓
CPU 使用情况
↓
内存和 swap
↓
磁盘空间和 IO
↓
网络连接
↓
进程状态
↓
服务日志
↓
业务层问题

常用命令：

uptime
 top
 htop
 free -h
 df -h
 iostat -x 1
 vmstat 1
 ss -antp
 ps aux --sort=-%cpu
 ps aux --sort=-%mem
 journalctl -xe
 dmesg -T

不要只看一个指标，要结合多个指标判断。

例如 CPU 高不一定是 CPU 瓶颈，也可能是磁盘 IO 阻塞导致负载升高。

---

三、Load Average 怎么看？

uptime 可以看到系统负载：

uptime

示例：

17:30:01 up 20 days,  3:15,  1 user,  load average: 3.20, 2.85, 1.90

三个数字分别表示：

数值	含义
1 分钟负载	最近 1 分钟平均负载
5 分钟负载	最近 5 分钟平均负载
15 分钟负载	最近 15 分钟平均负载

判断负载要结合 CPU 核心数。

查看 CPU 核心数：

nproc

如果是 2 核服务器，load 长期超过 2，就说明系统压力较高。
如果是 8 核服务器，load 为 3 不一定有问题。

注意

Load 高不代表一定是 CPU 忙，也可能是：

• 磁盘 IO 等待
• 网络阻塞
• 大量进程等待资源
• 数据库锁等待

所以还要结合 top、iostat、vmstat 判断。

---

四、CPU 问题定位

查看 CPU 使用情况：

top

重点关注：

指标	含义
us	用户态 CPU
sy	内核态 CPU
wa	IO 等待
id	空闲 CPU
hi/si	硬中断/软中断
st	虚拟化偷取时间

常见判断

1. us 很高

通常说明业务进程消耗 CPU，例如：

• PHP
• Java
• Node.js
• MySQL
• Python 脚本

查看 CPU 占用最高进程：

ps aux --sort=-%cpu | head -20

2. wa 很高

说明 CPU 在等待磁盘 IO，不一定是 CPU 不够。

这时要检查：

iostat -x 1

关注：

• %util
• await
• r/s
• w/s

如果 %util 长期接近 100%，说明磁盘压力很大。

3. st 很高

如果是云服务器，st 表示被宿主机“偷走”的 CPU 时间。
这个值长期较高，可能说明云主机所在物理机资源紧张。

---

五、内存和 Swap 排查

查看内存：

free -h

示例：

              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       2.1Gi       300Mi       120Mi       1.4Gi       1.3Gi
Swap:         2.0Gi       500Mi       1.5Gi

重点看 available，不是只看 free。

Linux 会把空闲内存用于缓存，所以 free 很低不一定有问题。

Swap 使用过高怎么办？

如果 swap 长期大量使用，说明内存压力较大。

排查内存占用最高进程：

ps aux --sort=-%mem | head -20

常见原因：

• Java 堆内存设置过大
• MySQL buffer 配置过高
• PHP-FPM 子进程过多
• Redis 没有限制 maxmemory
• 程序内存泄漏
• 同时运行太多服务

OOM 排查

如果系统出现进程被杀，可以查看：

dmesg -T | grep -i -E "killed process|oom"

如果看到 OOM Killer 记录，说明系统内存不足，内核主动杀掉了进程。

---

六、磁盘空间和 inode

磁盘满是非常常见的服务器故障。

查看磁盘空间：

df -h

查看 inode：

df -i

有时候磁盘空间没满，但 inode 满了，也会导致无法创建新文件。

常见占用空间目录：

/var/log
/var/lib/mysql
/www/wwwlogs
/home
/tmp

查找大文件：

du -ah /var/log | sort -rh | head -20

查找当前目录下大文件夹：

du -sh * | sort -rh | head

日志文件过大处理

不要直接删除正在被进程占用的日志文件。
更安全的方式是清空：

: > /path/to/logfile.log

或者配置 logrotate，让日志自动轮转。

---

七、磁盘 IO 排查

安装 sysstat：

apt install sysstat -y
# 或
 yum install sysstat -y

查看 IO：

iostat -x 1

重点指标：

指标	含义
await	IO 平均等待时间
%util	磁盘繁忙程度
r/s	每秒读请求
w/s	每秒写请求
rkB/s	每秒读取量
wkB/s	每秒写入量

如果 %util 长期接近 100%，并且 await 较高，说明磁盘成为瓶颈。

常见原因：

• MySQL 大量读写
• 日志疯狂写入
• 备份任务正在执行
• 网站被大量访问生成缓存
• 磁盘性能较差
• 程序频繁写小文件

可以结合 iotop 查看具体进程：

iotop -o

---

八、网络连接排查

查看监听端口：

ss -lntp

查看 TCP 连接状态：

ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

常见状态：

状态	含义
ESTAB	已建立连接
TIME-WAIT	等待关闭
SYN-SENT	主动发起连接
SYN-RECV	收到连接请求
CLOSE-WAIT	对方关闭，本地未关闭

如果 SYN-RECV 很多，可能存在攻击或连接堆积。
如果 CLOSE-WAIT 很多，可能是应用程序没有正确关闭连接。

查看连接最多的 IP：

ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

---

九、文件句柄限制

高并发服务可能遇到文件句柄不足。

查看当前限制：

ulimit -n

查看系统限制：

cat /proc/sys/fs/file-max

查看某个进程打开文件数：

ls /proc/<PID>/fd | wc -l

如果 Nginx、MySQL、Redis 等服务连接数较高，需要合理调整文件句柄限制。

但不要盲目调大，应该结合实际连接数和服务参数一起设置。

---

十、服务日志是关键证据

性能问题不能只看系统指标，还要看服务日志。

常见日志位置：

/var/log/syslog
/var/log/messages
/var/log/nginx/error.log
/var/log/nginx/access.log
/var/log/mysql/error.log
/var/log/php-fpm.log
/var/log/secure

systemd 服务日志：

journalctl -u nginx --since "1 hour ago"
journalctl -u mysql --since "1 hour ago"
journalctl -u php-fpm --since "1 hour ago"

如果网站在某个时间点突然变慢，可以按时间范围查看日志，通常能找到线索。

---

十一、常见调优方向

1. PHP-FPM

关注：

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers
pm.max_requests

如果 max_children 太小，高峰期请求会排队。
如果太大，可能导致内存耗尽。

2. MySQL

关注：

innodb_buffer_pool_size
max_connections
slow_query_log
tmp_table_size
query cache（新版 MySQL 已不推荐）

MySQL 优化要结合内存和业务查询，不要照搬网上参数。

3. Nginx

关注：

worker_processes
worker_connections
keepalive_timeout
client_max_body_size
gzip / brotli
access_log 是否过多

Nginx 本身通常不是瓶颈，更多问题出在后端 PHP、数据库或磁盘 IO。

---

十二、推荐故障排查模板

遇到服务器变慢，可以按这个模板记录：

## 故障时间
2026-xx-xx xx:xx

## 表现
- 网站打开慢
- 后台 502
- CPU 飙高

## 系统状态
- load average:
- CPU us/sy/wa:
- memory available:
- swap used:
- disk usage:
- disk io:
- network connections:

## 主要异常进程
- PID:
- 服务:
- CPU:
- MEM:

## 日志发现
- Nginx:
- PHP-FPM:
- MySQL:
- system:

## 初步原因

## 处理动作

## 后续优化

这样做可以避免每次排查都从零开始，也方便后续复盘。

---

十三、总结

Linux 服务器进阶运维的核心，不是记住多少命令，而是建立一套清晰的排查逻辑。

当服务器出现问题时，应该按照：

负载 → CPU → 内存 → 磁盘 → IO → 网络 → 进程 → 日志 → 业务

逐层定位。

真正可靠的运维，不是等故障发生后临时处理，而是平时就做好：

• 监控
• 日志轮转
• 备份
• 慢查询分析
• 资源容量规划
• 服务参数优化
• 故障复盘

服务器性能优化没有万能参数，所有调优都应该建立在数据和日志之上。