一台 Linux 机器越来越慢，怎样用 top、vmstat、iostat 找到瓶颈
一、问题背景
生产环境中，经常遇到这样的场景：服务器刚上线时响应很快，但运行一段时间后，越来越慢。用户反馈页面加载缓慢，接口超时，甚至SSH登录都卡顿。
这种"慢"可能由多种原因导致：
CPU瓶颈：
- 应用代码死循环或低效算法
- 上下文切换过多
- 中断处理占用CPU
- 进程优先级配置不当
内存瓶颈：
- 内存泄漏导致可用内存不足
- 频繁swap导致性能下降
- Page Cache被占满，磁盘IO增加
- OOM Killer频繁杀进程
磁盘IO瓶颈：
- 磁盘读写速度慢(机械硬盘、老化SSD)
- 大量随机IO导致IOPS不足
- 文件系统碎片化
- 应用未使用缓存，频繁读写磁盘
网络瓶颈：
如果无法快速定位瓶颈，可能导致：
- 盲目扩容，浪费资源
- 重启服务临时缓解，但根因未解决
- 优化方向错误，性能未改善
本文系统梳理如何使用 top、vmstat、iostat 三个基础工具，快速定位性能瓶颈，找到优化方向。
二、适用场景
本文适用于以下运维场景：
- 服务器响应慢，需要快速定位瓶颈是CPU、内存还是磁盘
- 应用性能下降，需要分析系统资源使用情况
- 需要优化系统性能，但不确定从哪里入手
- 需要理解Linux性能监控的基本原理和工具
- 需要为容量规划收集基线数据
本文的方法适用于Linux系统(CentOS、Ubuntu、Debian)，需要基础的Linux命令行知识。
三、核心知识点
3.1 Linux性能观测的层次
Linux性能分析可以分为以下层次：
硬件层：
- CPU：核心数、频率、缓存
- 内存：容量、频率、通道数
- 磁盘：类型(HDD/SSD/NVMe)、IOPS、带宽
- 网络：带宽、延迟、丢包率
内核层：
- 调度器：进程调度、上下文切换
- 内存管理：分页、swap、Page Cache
- IO调度器：CFQ、Deadline、Noop
- 网络栈：TCP/IP协议栈
应用层：
- 进程CPU使用率
- 进程内存使用
- 进程IO行为
- 进程网络行为
3.2 top、vmstat、iostat的关系
这三个工具从不同角度观测系统性能：
top：
- 实时显示进程级资源使用情况
- 适合快速找到占用资源最多的进程
- 刷新频率高(默认3秒)
vmstat：
- 显示系统级资源使用情况
- 包含CPU、内存、IO、上下文切换等综合指标
- 适合分析系统整体负载
iostat：
- 专注于磁盘IO性能
- 显示每个磁盘的读写速度、IOPS、利用率
- 适合排查IO瓶颈
3.3 CPU使用率的分类
CPU使用率分为以下几类：
us (user)：
sy (system)：
ni (nice)：
- 低优先级进程占用的CPU时间
- 通过nice调整优先级的进程
id (idle)：
wa (iowait)：
hi (hardware interrupt)：
si (software interrupt)：
st (steal)：
3.4 内存使用的分类
Linux内存管理复杂，需要理解以下概念：
物理内存：
- total：总内存
- used：已使用内存
- free：完全空闲的内存
- available：可用内存(包括可回收的Page Cache)
虚拟内存：
- swap：交换空间，用于内存不足时换出页面
- si (swap in)：从swap换入内存的速率
- so (swap out)：从内存换出到swap的速率
Page Cache：
- buff：块设备缓存(如磁盘元数据)
- cache：文件内容缓存
- Linux会尽量使用空闲内存作为Page Cache，提高IO性能
3.5 磁盘IO的关键指标
IOPS (每秒IO操作数)：
- 顺序读写IOPS：HDD约100-200，SSD约几千到几万
- 随机读写IOPS：HDD约100，SSD约几千到几十万
吞吐量(带宽)：
- 顺序读写速度：HDD约100-200MB/s，SSD约500MB/s-3GB/s，NVMe约3-7GB/s
- 随机读写速度：受IOPS限制
延迟：
- HDD：5-10ms
- SATA SSD：0.1-1ms
- NVMe SSD：0.01-0.1ms
利用率：
- %util：磁盘繁忙时间占比
- 接近100%表示磁盘已饱和
四、使用top定位CPU和内存瓶颈
4.1 top基础用法
# 启动toptop# 常用交互命令# 1: 显示每个CPU的使用率# M: 按内存使用率排序# P: 按CPU使用率排序# c: 显示完整命令行# k: 杀死进程# r: 修改进程优先级# q: 退出
top输出解读：
top - 14:30:25 up 10 days, 3:42, 2 users, load average: 2.50, 2.30, 2.10Tasks: 250 total, 2 running, 248 sleeping, 0 stopped, 0 zombie%Cpu(s): 45.0 us, 15.0 sy, 0.0 ni, 35.0 id, 4.0 wa, 0.5 hi, 0.5 si, 0.0 stMiB Mem : 32000.0 total, 2000.0 free, 25000.0 used, 5000.0 buff/cacheMiB Swap: 8192.0 total, 6000.0 free, 2192.0 used. 4000.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1234 app 20 0 10.0g 8.0g 100m R 95.0 25.6 500:30 java 5678 mysql 20 0 5.0g 3.0g 200m S 25.0 9.6 200:15 mysqld
第一行：系统运行时间和负载：
load average: 2.50, 2.30, 2.10：1分钟、5分钟、15分钟平均负载- 负载含义：等待CPU的进程数 + 正在运行的进程数
- 判断标准：负载 < CPU核心数为正常，> CPU核心数说明有进程在等待
第二行：进程状态统计：
running：正在运行的进程数sleeping：休眠进程数zombie：僵尸进程数(需要关注)
第三行：CPU使用率：
us=45%：用户态CPU使用率，应用计算占用sy=15%：内核态CPU使用率，系统调用占用id=35%：CPU空闲wa=4%：等待IO的时间，>10%说明IO可能是瓶颈
第四行：内存使用：
total=32GB：总内存free=2GB：完全空闲内存used=25GB：已使用内存buff/cache=5GB：Page Cache，可回收avail=4GB：实际可用内存(free + 可回收的cache)
第五行：Swap使用：
used=2.2GB：已使用swap，说明内存不足- 如果swap使用率>10%且频繁换入换出(si/so>0)，说明内存瓶颈严重
进程列表：
%CPU：进程CPU使用率，>100%说明多线程%MEM：进程内存使用率VIRT：虚拟内存(分配的总内存)RES：物理内存(实际占用的内存)SHR：共享内存S：进程状态(R=运行,S=休眠,D=不可中断睡眠,Z=僵尸)
4.2 快速判断CPU瓶颈
场景1：CPU使用率高(id < 20%)
# 按CPU使用率排序top# 按P键# 查看哪个进程占用CPU最高
判断：
- 如果单个进程CPU>80%：应用代码可能有死循环或低效算法
- 如果多个进程CPU>50%：系统整体负载高，需要扩容或优化
- 如果sy(系统态)>30%：可能内核瓶颈，检查系统调用、中断
场景2：负载高但CPU空闲(id > 50%)
# 查看load average和CPU idletop
判断：
- load average高但id高：说明有大量进程在等待IO(状态为D)
- 需要进一步用iostat检查磁盘IO
场景3：wa(iowait)高(wa > 10%)
判断：
- wa高说明CPU在等待IO完成
- 需要用iostat定位具体是哪个磁盘慢
4.3 快速判断内存瓶颈
场景1：内存使用率高(avail < 10%)
# 按内存使用率排序top# 按M键# 查看哪个进程占用内存最高
判断：
- 如果单个进程RES>80%总内存：可能内存泄漏
- 如果多个进程总和>80%总内存：内存不足，需要扩容
- 关注VIRT和RES的差值：差值大说明内存分配多但实际使用少
场景2：swap使用率高(swap used > 2GB)
判断：
- swap used > 0：内存不足，开始使用swap
- 需要用vmstat查看si/so(换入换出速率)，>0说明频繁swap，性能严重下降
场景3：OOM Killer被触发
# 查看系统日志dmesg | grep -i "out of memory"journalctl -k | grep -i "oom"
判断：
- 出现OOM日志：内存不足，内核强制杀死进程
- 需要增加内存或优化应用内存使用
五、使用vmstat分析系统整体性能
5.1 vmstat基础用法
# 每2秒输出一次，共输出10次vmstat 2 10# 输出示例procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 1 200000 2000000 500000 5000000 10 20 1000 500 5000 8000 45 15 35 4 0 3 0 200000 1900000 500000 5000000 0 0 1200 600 5200 8500 50 16 30 3 0
字段解释：
procs (进程)：
r：等待CPU的进程数(running + runnable)b：不可中断睡眠的进程数(等待IO)
memory (内存，单位KB)：
swpd：已使用的swap空间free：空闲内存buff：块设备缓存cache：文件内容缓存
swap (交换空间，单位KB/s)：
si：从swap换入内存的速率so：从内存换出到swap的速率
io (块设备IO，单位blocks/s)：
bi：从块设备读入的数据量bo：写到块设备的数据量
system (系统)：
cpu (CPU使用率，百分比)：
us：用户态CPUsy：内核态CPUid：空闲CPUwa：等待IO的CPUst：被steal的CPU(虚拟机)
5.2 使用vmstat判断瓶颈
场景1：CPU瓶颈
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st15 0 0 5000000 500000 8000000 0 0 10 20 5000 3000 90 8 2 0 0
特征：
r > CPU核心数：有大量进程等待CPUus高(>80%)：用户态程序占用CPUcs高(>10000)：上下文切换频繁，可能进程/线程过多id低(<10%)：CPU几乎无空闲
判断：
场景2：内存瓶颈
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 3 2000000 100000 200000 500000 500 800 5000 10000 8000 5000 30 20 10 40 0
特征：
swpd > 0：已使用swapsi/so > 0：频繁换入换出free很低：几乎无空闲内存wa高(>30%)：大量时间在等待IO(因为swap在磁盘上)b > 0：有进程在等待IO
判断：
- 内存不足导致频繁swap，严重影响性能
- 需要增加内存或优化应用内存使用
场景3：磁盘IO瓶颈
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 5 0 10000000 500000 8000000 0 0 50000 30000 10000 4000 20 10 50 20 0
特征：
b > 0：有进程在等待IObi/bo高：磁盘读写量大wa > 10%：CPU在等待IOid > 0：CPU有空闲，但进程在等待IO
判断：
场景4：上下文切换过多
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 5 0 0 10000000 500000 8000000 0 0 100 200 20000 50000 40 30 30 0 0
特征：
cs > 20000：每秒上下文切换很高sy高(>20%)：内核态CPU占用高(上下文切换开销)in高：中断次数高
判断：
六、使用iostat定位磁盘IO瓶颈
6.1 iostat基础用法
# 安装iostat(sysstat包)yum install sysstat # CentOSapt install sysstat # Ubuntu# 每2秒输出一次，共输出5次iostat -x 2 5# 输出示例Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %utilsda 500.0 300.0 50000.0 30000.0 10.0 20.0 2.0 6.3 5.0 8.0 2.5 100.0 100.0 1.2 95.0sdb 50.0 20.0 5000.0 2000.0 1.0 2.0 2.0 9.1 2.0 3.0 0.1 100.0 100.0 0.5 10.0
字段解释：
读写IOPS：
读写吞吐量(KB/s)：
rkB/s：每秒读取的KB数wkB/s：每秒写入的KB数
请求合并：
rrqm/s：每秒合并的读请求数wrqm/s：每秒合并的写请求数%rrqm：读请求合并率%wrqm：写请求合并率
延迟(毫秒)：
r_await：读操作平均延迟w_await：写操作平均延迟await：总平均延迟
队列：
请求大小(KB)：
rareq-sz：平均读请求大小wareq-sz：平均写请求大小
利用率：
%util：磁盘繁忙时间占比，接近100%说明磁盘已饱和
6.2 使用iostat判断瓶颈
场景1：磁盘IOPS瓶颈
Device r/s w/s rkB/s wkB/s r_await w_await %utilsda 8000.0 2000.0 80000 20000 15.0 25.0 98.0
特征：
r/s + w/s 很高(HDD>200，SATA SSD>10000)r_await/w_await 高(>10ms)%util 接近100%rareq-sz/wareq-sz 小(<16KB)：随机IO
判断：
- 随机IO导致IOPS瓶颈
- 需要优化应用减少随机IO，或升级到NVMe SSD
场景2：磁盘带宽瓶颈
Device r/s w/s rkB/s wkB/s r_await w_await %utilsda 50.0 200.0 500000 2000000 2.0 5.0 95.0
特征：
rkB/s + wkB/s 很高(HDD>150MB/s，SATA SSD>500MB/s)rareq-sz/wareq-sz 大(>128KB)：顺序IO%util 接近100%
判断：
- 顺序IO导致带宽瓶颈
- 磁盘已达到最大吞吐量，需要优化应用或升级磁盘
场景3：IO延迟高
Device r/s w/s rkB/s wkB/s r_await w_await %utilsda 100.0 50.0 10000 5000 50.0 80.0 50.0
特征：
r_await/w_await 很高(>20ms)%util 不高(<70%)aqu-sz 高：队列积压
判断：
- 磁盘响应慢，可能磁盘故障或老化
- 需要检查磁盘健康状态(smartctl)
场景4：IO正常但应用慢
Device r/s w/s rkB/s wkB/s r_await w_await %utilsda 20.0 10.0 2000 1000 2.0 3.0 10.0
特征：
判断：
- 瓶颈不在磁盘，需要检查CPU、内存、网络
- 或应用层面的问题(如数据库慢查询)
6.3 结合iotop定位进程
# 安装iotopyum install iotop # CentOSapt install iotop # Ubuntu# 实时查看哪个进程占用IOiotop -o # 只显示有IO的进程# 输出示例 TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1234 be/4 mysql 50.00 M/s 20.00 M/s 0.00 % 95.00 % mysqld 5678 be/4 app 10.00 M/s 5.00 M/s 0.00 % 30.00 % java
判断：
- 快速找到占用IO最高的进程
- 结合应用日志分析为什么IO高
七、综合分析案例
案例1：CPU瓶颈
现象：
服务器响应慢，用户反馈超时。
第一步：top查看整体情况
输出：
load average: 8.50, 8.30, 8.10 # 负载很高(8核CPU)%Cpu(s): 95.0 us, 3.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.0 hi, 1.0 si
判断：
- 负载8.5，8核CPU，负载正常
- us=95%，sy=3%，id=0%：CPU几乎全被用户态程序占用
- wa=0%：不是IO瓶颈
- 初步判断：CPU瓶颈
第二步：top查看进程
输出：
PID USER %CPU %MEM COMMAND 1234 app 780.0 25.0 java
判断：
- 单个进程CPU 780%，说明多线程程序(10个线程)
- 该进程占用了大部分CPU
第三步：分析进程行为
# 查看进程线程top -H -p 1234# 查看进程系统调用strace -c -p 1234# 查看进程打开的文件lsof -p 1234
根因：
应用代码存在死循环或低效算法。
解决：
案例2：内存瓶颈
现象：
服务器响应慢，SSH登录卡顿。
第一步：top查看内存
输出：
MiB Mem : 32000.0 total, 100.0 free, 30000.0 used, 1900.0 buff/cacheMiB Swap: 8192.0 total, 2000.0 free, 6192.0 used. 200.0 avail Mem
判断：
- avail=200MB，几乎无可用内存
- swap used=6.2GB，已使用大量swap
- 初步判断：内存不足
第二步：vmstat查看swap换入换出
输出：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 5 6000000 100000 200000 1700000 5000 3000 10000 8000 8000 5000 20 15 10 55 0
判断：
- si=5000, so=3000：频繁swap换入换出
- wa=55%：大量时间在等待IO(因为swap在磁盘上)
- b=5：5个进程在等待IO
第三步：top查看进程内存
输出：
PID USER %CPU %MEM VIRT RES COMMAND 1234 app 5.0 60.0 20.0g 18.0g java
判断：
- 单个进程占用18GB物理内存
- VIRT=20GB, RES=18GB：内存分配和使用都很高
根因：
应用内存使用过高或内存泄漏。
解决：
案例3：磁盘IO瓶颈
现象：
数据库查询慢，CPU和内存正常。
第一步：top查看iowait
输出：
%Cpu(s): 5.0 us, 2.0 sy, 0.0 ni, 50.0 id, 40.0 wa, 1.0 hi, 2.0 si
判断：
- wa=40%：大量时间在等待IO
- id=50%：CPU有空闲
- 初步判断：IO瓶颈
第二步：vmstat查看IO
输出：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 8 0 5000000 500000 8000000 0 0 50000 20000 10000 4000 10 5 45 40 0
判断：
- b=8：8个进程在等待IO
- bi=50000 blocks/s：读IO很高
- bo=20000 blocks/s：写IO也不低
第三步：iostat查看具体磁盘
输出：
Device r/s w/s rkB/s wkB/s r_await w_await %utilsda 5000.0 1000.0 500000 100000 25.0 35.0 98.0sdb 10.0 5.0 1000 500 2.0 3.0 5.0
判断：
- sda的%util=98%：磁盘几乎满负载
- r_await=25ms, w_await=35ms：延迟很高(机械硬盘特征)
- sdb正常
第四步：iotop查看进程
输出：
TID PRIO USER DISK READ DISK WRITE COMMAND 1234 be/4 mysql 450 M/s 90 M/s mysqld
判断：
根因：
数据库查询导致大量磁盘读写，机械硬盘IOPS不足。
解决：
- 优化数据库查询，添加索引
- 增加数据库缓存(innodb_buffer_pool_size)
- 升级到SSD
八、优化建议
8.1 CPU优化
应用层：
- 优化算法，避免死循环
- 减少锁竞争，使用无锁数据结构
- 使用缓存减少重复计算
- 合理使用多线程，避免过多线程导致上下文切换
系统层：
- 调整进程优先级(nice/renice)
- 使用CPU亲和性(taskset)绑定进程到特定CPU
- 关闭不必要的服务
硬件层：
8.2 内存优化
应用层：
- 修复内存泄漏
- 优化数据结构，减少内存占用
- 使用对象池复用对象
系统层：
- 调整swap策略(vm.swappiness)
- 增加内存
- 使用huge pages减少TLB miss
监控：
8.3 磁盘IO优化
应用层：
- 减少随机IO，增加顺序IO
- 使用缓存减少磁盘访问
- 批量写入代替逐条写入
- 异步IO代替同步IO
系统层：
- 调整IO调度器(deadline/noop适合SSD)
- 增加Page Cache(增加内存)
- 使用RAID提高IOPS和带宽
- 定期清理不必要的文件
硬件层：
- 升级到SSD或NVMe SSD
- 使用多块磁盘分散IO
九、监控和告警
9.1 Prometheus监控规则
groups:-name:system_performancerules:-alert:HighCPUUsageexpr:100-(avg(irate(node_cpu_seconds_total{mode="idle"}[5m]))*100)>80for:5mlabels:severity:warningannotations:summary:"CPU使用率超过80%"-alert:HighIOWaitexpr:avg(irate(node_cpu_seconds_total{mode="iowait"}[5m]))*100>20for:5mlabels:severity:warningannotations:summary:"IO等待时间超过20%"-alert:HighMemoryUsageexpr:(1-node_memory_MemAvailable_bytes/node_memory_MemTotal_bytes)*100>90for:5mlabels:severity:warningannotations:summary:"内存使用率超过90%"-alert:HighSwapUsageexpr:(1-node_memory_SwapFree_bytes/node_memory_SwapTotal_bytes)*100>50for:5mlabels:severity:criticalannotations:summary:"Swap使用率超过50%"-alert:HighDiskUtilexpr:irate(node_disk_io_time_seconds_total[5m])*100>90for:5mlabels:severity:warningannotations:summary:"磁盘利用率超过90%"
9.2 采集性能基线
# 采集1小时的性能数据vmstat 60 60 > vmstat_baseline.txtiostat -x 60 60 > iostat_baseline.txt# 分析基线awk '{sum+=$13; count++} END {print "平均CPU使用率:", 100-sum/count "%"}' vmstat_baseline.txtawk '/^Device/,0 {if ($1 != "Device") sum+=$14; count++} END {print "平均磁盘利用率:", sum/count "%"}' iostat_baseline.txt
十、总结
快速排查流程：
- top查看整体情况 → 判断是CPU、内存还是IO瓶颈
- vmstat查看系统指标 → 确认瓶颈类型和严重程度
- iostat查看磁盘IO → 定位具体哪块磁盘慢
- top/iotop查看进程 → 找到占用资源最多的进程
- 分析应用日志 → 确定根因
关键判断指标：
| 瓶颈类型 | top指标 | vmstat指标 | iostat指标 |
|---|
| CPU瓶颈 | id<10%, us>80% | r>CPU核心数 | - |
| 内存瓶颈 | avail<10%, swap used>0 | si/so>0 | - |
| IO瓶颈 | wa>10% | b>0, bi/bo高 | %util>90%, await>10ms |
优化方向：
- CPU瓶颈：优化算法、增加CPU
- 内存瓶颈：修复泄漏、增加内存
- IO瓶颈：优化IO模式、升级磁盘
掌握这三个工具后，面对性能问题能够快速定位瓶颈，找到优化方向，避免盲目扩容或优化错方向。
十一、实用脚本和工具
11.1 一键性能诊断脚本
#!/bin/bash# perf_check.sh - 快速性能诊断echo"=== 系统负载 ==="uptimeecho -e "\n=== CPU使用率 ==="top -bn1 | grep "Cpu(s)" | awk '{print "us:"$2" sy:"$4" id:"$8" wa:"$10}'echo -e "\n=== 内存使用 ==="free -h | grep -E "Mem|Swap"echo -e "\n=== TOP 5 CPU进程 ==="ps aux --sort=-%cpu | head -6echo -e "\n=== TOP 5 内存进程 ==="ps aux --sort=-%mem | head -6echo -e "\n=== 磁盘IO统计 ==="iostat -x 1 2 | tail -n +4echo -e "\n=== 是否有swap换入换出 ==="vmstat 1 5 | awk 'NR>2 {if ($7>0 || $8>0) print "WARNING: swap活跃! si:"$7" so:"$8}'echo -e "\n=== 磁盘利用率 ==="iostat -x 1 2 | awk '/^[a-z]/ && NR>3 {if ($14>80) print "WARNING: "$1" 利用率 "$14"%"}'
11.2 常见误区
误区1：load average高就是CPU瓶颈
需要结合CPU使用率和iowait综合判断。load = 正在运行 + 等待IO的进程数。
误区2：free很低就是内存不足
Linux会把空闲内存用作Page Cache。关注available，不是free。
误区3：swap使用就是问题
需要看si/so(换入换出速率)。只有si/so>0且持续，才说明内存不足。
误区4：%util=100%就是磁盘瓶颈
NVMe SSD支持多队列并行IO。关注await和队列深度，不只看%util。
十二、总结
三大工具对比：
| 工具 | 优势 | 适用场景 | 关键指标 |
|---|
| top | 实时、直观、按进程 | 快速定位占用资源的进程 | load, CPU%, MEM%, swap |
| vmstat | 系统级、综合、历史趋势 | 分析整体负载和资源使用 | r, b, si, so, wa |
| iostat | 磁盘专项、IOPS、延迟 | 排查IO瓶颈，评估磁盘性能 | %util, await, r/s, w/s |
核心排查流程：
- top查看整体 → 判断瓶颈类型
- vmstat确认 → 系统级验证
- iostat细化 → 如果IO瓶颈
- top/iotop找进程 → 定位问题进程
- 分析根因 → 结合应用日志
- 优化验证 → 持续监控
关键经验：
- 不要只看单一指标
- 关注变化趋势
- 理解指标含义
- 结合应用日志
- 验证优化效果
掌握这三个工具和分析方法后，面对性能问题能够快速定位瓶颈，准确找到根因，采取有效的优化措施。
10个月宝宝每天需要喝多少奶粉？
