通过Vmstat诊断虚拟内存找出内存IO瓶颈

当系统响应变慢但CPU未满载时,可能是虚拟内存管理问题。本文介绍了如何通过vmstat命令分析内存IO瓶颈,重点关注swpd、free、si、so等字段的变化,以诊断内存交换频繁和系统性能下降的情况。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >


当你的Windows连续开机一个星期时,你是不是发现机器特别慢,点啥啥不开。但是你去看资源管理器的又发现内存占用也没有到90%,CPU也没跑满。那为什么这个时候会那么卡呢?

其中一个原因就是由于长期使用机器且没有关机,导致内存中缓存了大量的数据。由于系统的虚拟内存管理,当内存使用达到一定程度时,系统会将内存中 的数据交换到硬盘中,也就是Windos的虚拟内存,在Linux中叫Swap分区。此时如果要使用交换到硬盘上的数据,那么系统首先要把内存中最远最久没有 使用的数据交换到硬盘,再把硬盘中需要的数据加载到内存,然后才可以跑逻辑,这样就造成了“点啥啥不开”的残像了。

那么这样的情况会不会发生在我们的Server端Linux上呢?答案当然是肯定的。而且一旦该情况发生,有可能产生雪崩效应,一下就把服务器弄回老家了。 这里的典型案例就有云风大大遇到的Redis转储。又或者可以自己手写一个无限分配 内存并使用的例子。然后静静等待系统挂掉的那一刻。

那么什么时候会发生这样的情况?或者说当我们的系统表现出什么的症状时我们要考虑这样的情况?如何进行确诊?

一般当系统频繁的需要新内存时可能发生这样的情况,如频繁的读文件而不释放、网络接收大量文件写磁盘(写磁盘跟不上内存从网络接收的量)。此时我们的系统 对外相应速度会急剧下降但是CPU又没有跑满。这时我们就应该考虑是不是虚拟内存频繁交换的问题了。通过使用vmstat可以帮助我们来确诊是不是这个原因。

1. vmstat输出

裸奔运行vmstat命令,可以看到一行输出。该行输出内容表示的自系统最近启动后虚拟内存和CPU的平均情况。 在输出的第一行我们称之为表头。依次包含了:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----

几个字段,第二行我们称之为子表头,依次包含了:

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

其意义分别为:

  1. procs : 使用内存IO的进程统计

    • r : 获取了IO资源而等待cpu运行的进程数目
    • b : 因为等待IO资源而阻塞休眠的进程数目
  2. memory: 虚拟内存相关统计

    • swpd : 用掉的虚拟内存大小。也就是交换分区内用掉的大小
    • free : 空闲的内存大小。
    • buff : 被用作系统buffer的大小。比如write系统调用的时候,系统不会立马写磁盘,而是先缓冲到buffer中然后在合适的时候写入磁盘。
    • cache : 被用作系统cache的大小。

这里,free的大小表示一定可以使用的大小,即malloc不会出错的大小。但是超过free时malloc会一定出错么?也不一定。因为系统的buff和cache在必要 的时候也会优先给malloc使用。只有在不可使用时才会出错,如被设置为共享内存。因此观察时要综合这四个位置一起作判断。当分配内存时首先使用free,free不够的时候从buff和cache中匀得,当还不够时选择从swap分区中取得。

  1. swap: 交换分区的使用情况

    • si : 每秒从硬盘中交换到内存中的大小。
    • so :每秒从内存中交换到硬盘中的大小。
  2. io : 块设备IO统计

    • bi : 每秒从块设备读入内存的大小
    • bo : 每秒从内存中写入快设备的大小

什么是块设备?Linux下的设备主要分成字符设备和块设备(可以参考LDD《linux device driver》),类似于Socket属于流设备,而磁盘一般属于块设备。因此这个参数可以用来衡量写磁盘的性能。

  1. system : 操作系统中断和上下文切换统计

    • in : 操作的系统每秒触发的中断数目
    • cs : 操作系统每秒上下文切换次数,这里上下文切换可以认为是系统态到用户态或者反过来的切换
  2. cpu: cpu相关统计

    • us : 用户态代码执行占用的cpu时间。
    • sy :系统态代码执行占用的cpu时间。
    • id : cpu空闲时间,也就是执行系统idle的时间,cpu是不可能停机的。
    • wa : 耗费在等待IO上的时间
    • st : 其他的等待时间。

2. vmstat的使用

上面我们裸跑vmstat就可以得到一个输出,表示的是:自系统最近启动后虚拟内存和CPU的平均情况。

vmstat的调用格式为:

vmstat delay count [options]

这里先介绍一个“-a”选项。 如果使用了 “-a” 选项,我们会发现其输出和上面描述的有点不一样。在memory的下面,没有了buff和cache子列了,取而代之的是inact和active子列。 他们分别表示激活的和非激活的内存大小。那怎样理解“激活”呢?对比增加了-a选和没有增加-a选项的结果我们可以发现inact + active = cache大小。 也就是我们上面讨论,如果系统中free的内存不够了,那么就去用cache和buff里面的内存。但是并不是都可以用的,其中可以用的就是inact部分。因此 我们可以知道,系统此时还可以使用的内存大小为 free+inact大小。如果该和持续下降,那么我们就要注意了。是不是有内存泄露、或者内存分配洪请求等 情况的出现了。

除此之外还有个"-d"选项 通过使用“-d”选项,可以仅查看写磁盘的性能。有一级表头 disk, reads, writes, IO四大块。disk表示的是分区名称。reads和writes分别表示 读写扇区数目。其中都有: total merged sectors ms : total : 总共读取/写入成功的数目 merged : 合在一起读取操作的数目 sectors :读取/写入成功的扇区数目 ms :一次读或者写耗费的时间,单位是毫秒

IO中包含了cur表示当前正在处理的IO数目,s表示每处理一个IO请求耗费的时间,单位是秒。 “-d”选项中包含了很多ram开头的随机分区。为了更清楚的查看可以使用 “-p”选项 指定某个分区。如 :

vmstat -dp /dev/sda1

可以仅查看该分区硬盘的读写情况。

3. 通过vmstat进行诊断

从上面我们了解了vmstat的基本使用,就可以拿它当听诊器进行诊断了。运行

vmstat 1 100

会每个一秒输出一次统计

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
0  0     64 180428 394096 30058348    0    0    41   183    3    5  0  0 99  0  0
0  0     64 180428 394096 30058348    0    0     0    44  267  138  0  1 99  0  0
0  0     64 181048 394096 30058348    0    0     0     0  259  223  0  0 100  0  0
0  0     64 181048 394096 30058348    0    0     0     0  254  124  0  0 100  0  0
  1. 情景1:swpd 大小不断变化,si/so持续变化。 此时说明内存频繁进行换入换出操作,此时系统系能会急剧下降
  2. 情景2:id较高但是free 非常低,如果加上-a参数free+inactiv非常低。 此时内存可能被耗尽。
  3. 情景3:wa较高 系统等待IO时间过长,考虑IO的阻塞
  4. 。。。 有待补充
<think>好的,用户现在问的是磁盘IO瓶颈,之前他们问过nmon文件中如何分析磁盘瓶颈,现在这个问题更泛一些,可能是想了解更一般的情况。我需要先回顾之前的回答,确保不重复,同时扩展信息。 首先,用户可能是系统管理员或者运维人员,他们在处理服务器性能问题,特别是磁盘相关的。需要给出具体的指标、分析方法和解决方案。 之前的回答已经覆盖了nmon中的指标,比如DISKBUSY、吞吐量、AvgWait等。现在需要更通用的磁盘IO瓶颈分析,可能不局限于nmon工具。需要包括常见指标如IOPS、吞吐量、延迟,以及工具方面的扩展,比如iostat、sar等。 还要考虑用户可能遇到的场景,比如数据库慢、应用响应时间长,这时候如何确认是否是磁盘IO的问题。需要分步骤讲解如何识别和分析,可能包括监控工具的使用,指标阈值,以及不同瓶颈类型的解决方案。 另外,用户可能需要实际案例来理解,比如高IOPS导致延迟上升,或者顺序读写与随机读写的区别。需要举例子说明。 还要注意避免太技术化的术语,用中文清晰解释概念,比如IOPS是什么,吞吐量的单位,延迟的意义。同时,确保LaTeX公式正确,按照之前的系统级指令使用$$和$符号。 可能需要补充的工具部分,比如iostat的输出解读,pidstat找进程,fio测试工具。这些都是实际排查中常用的,用户可能想知道具体怎么做。 最后,解决方案部分要具体,比如升级硬件、优化应用、调整内核参数等,给出实际可行的建议。同时提醒用户结合硬件规格分析,比如不同类型的磁盘性能差异。 检查是否有遗漏点,比如并发请求的影响,队列长度,以及RAID配置的影响。确保覆盖全面,但不过于冗长。结构要清晰,分步骤和子点,方便用户逐步排查。</think>在分析磁盘I/O瓶颈时,需要从**吞吐量、IOPS、延迟、队列深度**四个核心维度综合判断。以下是系统级分析框架: --- ### 一、关键性能指标 $$ \begin{cases} \text{IOPS(每秒I/O操作数)} & \text{随机读写能力} \\ \text{吞吐量(MB/s)} & \text{顺序读写带宽} \\ \text{延迟(Latency)} & \text{单次I/O响应时间} \\ \text{队列深度(Queue Depth)} & \text{并发I/O请求数} \\ \end{cases} $$ --- ### 二、瓶颈识别步骤 #### 1. 监控工具选择 - **Linux**:`iostat -x 1`(关注`%util`, `await`, `svctm`) - **Windows**:PerfMon(计数器:`Avg. Disk sec/Read`, `Disk Transfers/sec`) - **通用工具**:`sar`, `dstat`, `iotop` #### 2. 阈值判断 | 指标 | 机械硬盘(HDD) | SSD | |--------------|----------------------|---------------------| | **IOPS** | < 200 | 5万~100万+ | | **延迟** | > 20ms(异常) | > 5ms(异常) | | **%util** | > 70%(瓶颈风险) | > 90%(需警惕) | #### 3. 瓶颈类型诊断 - **IOPS瓶颈**: - 现象:`iostat`中`r/s + w/s`接近磁盘标称IOPS - 场景:数据库大量小事务、日志高频写入 - **吞吐量瓶颈**: - 现象:`MB_read/s + MB_wrtn/s`接近磁盘带宽上限 - 场景:大数据顺序读写、视频流处理 - **延迟瓶颈**: - 现象:`await` > 磁盘标称延迟2倍(如HDD > 40ms) - 根源:队列堆积或硬件性能不足 --- ### 三、深度分析工具链 1. **定位高负载进程**: ```bash pidstat -d 1 # 按进程统计I/O iotop # 实时I/O进程排名 ``` 2. **分析I/O模式**: ```bash blktrace /dev/sda # 跟踪块设备请求 ``` 3. **压测验证**: ```bash fio --name=test --ioengine=libaio --rw=randread --bs=4k --numjobs=16 --size=1G --runtime=60 ``` --- ### 四、典型瓶颈场景与解决方案 #### 场景1:随机读密集型(如数据库) - **现象**:`%util`高但吞吐量低,`await`飙升 - **优化**: - 升级SSD并启用NVMe协议 - 调整MySQL的`innodb_buffer_pool_size` - 使用`deadline`或`none`调度器(SSD场景) #### 场景2:顺序写洪峰(如日志写入) - **现象**:周期性`MB_wrtn/s`触达磁盘带宽上限 - **优化**: - 启用写合并(write coalescing) - 分离日志盘与数据盘 - 使用LVM条带化提升并行度 #### 场景3:虚拟化环境I/O争抢 - **现象**:多VM同时高负载时`svctm`(服务时间)异常 - **优化**: - 启用Hypervisor的I/O控制组(cgroups) - 为关键VM分配virtio-blk的独立队列 - 配置QoS限制(如Ceph RBD的IOPS上限) --- ### 五、高级排查技巧 1. **内核参数调优**: ```bash echo 256 > /sys/block/sda/queue/nr_requests # 调整队列深度 echo deadline > /sys/block/sda/queue/scheduler ``` 2. **RAID配置影响**: - RAID5写惩罚:$ \text{实际IOPS} = \frac{\text{理论IOPS}}{4} $ - RAID10可提供最佳随机读写性能 3. **文件系统选择**: - 小文件密集型:XFS > ext4 - 海量文件:ZFS/Btrfs(需权衡内存开销) --- ### 六、验证瓶颈消除 通过**阿姆达尔定律**估算优化效果: $$ S = \frac{1}{(1-\alpha) + \frac{\alpha}{k}} $$ 其中: - $ \alpha $ = 受I/O限制的任务比例 - $ k $ = 磁盘性能提升倍数 当$ \alpha > 30\% $时,优化磁盘可获得显著收益。 > **注**:真实场景需结合`vmstat`的`bi`(块入)、`bo`(块出)和CPU的`wa`(I/O等待)综合判断。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值