zdq0394.github.com

Tech study and research.

Follow me on GitHub

vmstat命令详解

虚拟内存运行原理

在系统中运行的每个进程都需要使用到内存，但不是每个进程都需要每时每刻使用系统分配的内存空间。

当系统运行所需内存超过实际的物理内存时，内核会释放某些进程所占用但未使用的部分或所有物理内存，将这部分资料存储在磁盘上直到进程下一次调用，并将释放出的内存提供给有需要的进程使用。

在Linux内存管理中，主要是通过调页Paging和交换Swapping来完成上述的内存调度。

  • 调页算法是将内存中最近不常使用的页面换到磁盘上，把活动页面保留在内存中供进程使用。
  • 交换技术是将整个进程，而不是部分页面，全部交换到磁盘上。

分页(Page)写入磁盘的过程被称作Page-Out；分页(Page)从磁盘重新回到内存的过程被称作Page-In。

当内核需要一个分页时，但发现此分页不在物理内存中(因为已经被Page-Out了)，此时就发生了分页错误（Page Fault）。

当系统内核发现可运行内存变少时，就会通过Page-Out来释放一部分物理内存。 尽管Page-Out不是经常发生，但是如果Page-out频繁不断的发生，直到当内核管理分页的时间超过运行程序的时间时，系统效能会急剧下降。 这时的系统已经运行非常慢或进入暂停状态，这种状态亦被称作thrashing(颠簸)。

vmstat命令

命令

vmstat 1 表示每秒采集一次 vmstat 2 1 表示2秒采集一次，1表示只采集一次

[root@SCSP01815 ~]$ vmstat 1 5
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 105988 15388432 12526160 30483060    0    0    32  2025    0    0   21  2 75  2  0
 2  1 105988 15386956 12526160 30484112    0    0   308 33588 23859 33940 13  3 82  1  0
 2  2 105988 15394820 12526188 30488520    0    0   760 40768 29743 33784 15  3 78  3  0
 5  1 105988 15290092 12526188 30497112    0    0   404 22132 22040 28969 10  2 84  3  0
 2  1 105988 15355652 12526316 30486592    0    0   752 33820 20124 27949 10  2 86  2  0

选项

  • -a：显示活跃和非活跃内存
  • -f：显示从系统启动至今的fork数量
  • -m：显示slabinfo
  • -n：只在开始时显示一次各字段名称
  • -s：显示内存相关统计信息及多种系统活动数量
    • delay：刷新时间间隔。如果不指定，只显示一条结果
    • count：刷新次数。如果不指定刷新次数，但指定了刷新时间间隔，这时刷新次数为无穷
  • -d：显示磁盘相关统计信息
  • -p：显示指定磁盘分区统计信息
  • -S：使用指定单位显示。参数有k 、K 、m 、M ，分别代表1000、1024、1000000、1048576字节（byte）。默认单位为K（1024 bytes）
  • -V：显示vmstat版本信息。

    输出分析

    procs

  • r 表示运行队列(就是说多少个进程真的分配到CPU) 当这个值超过了CPU数目，就会出现CPU瓶颈了。 这个也和top的负载有关系，一般负载超过了3就比较高，超过了5就高，超过了10就不正常了，服务器的状态很危险。 top的负载类似每秒的运行队列。 如果运行队列过大，表示CPU很繁忙，一般会造成CPU使用率很高。
  • b 表示阻塞的进程。

memory

  • swpd 虚拟内存已使用的大小。 如果大于0，表示机器物理内存不足了，如果不是程序内存泄露的原因，那么该升级内存了或者把耗内存的任务迁移到其他机器。
  • free 空闲的物理内存的大小
  • buff 设备和设备之间的缓冲 Linux/Unix系统是用来存储，目录里面有什么内容，权限等的缓存
  • cache cpu和内存之间的缓冲 cache直接用来记忆我们打开的文件,给文件做缓冲，本机大概占用300多M(这里是Linux/Unix的聪明之处，把空闲的物理内存的一部分拿来做文件和目录的缓存，是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。)

swap

  • si 每秒从磁盘读入虚拟内存的大小，如果这个值大于0，表示物理内存不够用或者内存泄露了，要查找耗内存进程解决掉。
  • so 每秒虚拟内存写入磁盘的大小，如果这个值大于0，同上。

io

  • bi 块设备每秒接收的块数量，这里的块设备是指系统上所有的磁盘和其他块设备，默认块大小是1024byte 处理拷贝大量数据(2-3T)的机器上看过可以达到140000/s，磁盘写入速度差不多140M每秒
  • bo 块设备每秒发送的块数量，例如我们读取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO过于频繁，需要调整。

system

  • in 每秒CPU的中断次数，包括时间中断
  • cs 每秒上下文切换次数 例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。

cpu

  • us 用户CPU时间 曾经在一个做加密解密很频繁的服务器上，可以看到us接近100,r运行队列达到80(机器在做压力测试，性能表现不佳)。
  • sy 系统CPU时间，如果太高，表示系统调用时间长，例如是IO操作频繁。
  • id 空闲 CPU时间，一般来说，id + us + sy = 100,一般我认为id是空闲CPU使用率，us是用户CPU使用率，sy是系统CPU使用率。
  • wa 等待IO CPU时间。

性能分析信息

性能分析信息：

IO/CPU/men连锁反应：

  1. free急剧下降
  2. buff和cache被回收下降，但也无济于事
  3. 依旧需要使用大量swap交换分区swpd
  4. 等待进程数，b增多
  5. 读写IO，bi bo增多
  6. si so大于0开始从硬盘中读取
  7. cpu等待时间用于 IO等待，wa增加

内存不足：

  1. 开始使用swpd，swpd不为0
  2. si so大于0开始从硬盘中读取

io瓶颈：

  1. 读写IO，bi bo增多超过2000
  2. cpu等待时间用于 IO等待，wa增加 超过20
  3. sy 系统调用时间长，IO操作频繁会导致增加 >30%
  4. wa io等待时间长
    • iowait% <20% 良好
    • iowait% <35% 一般
    • iowait% >50%
  5. 进一步使用iostat观察

CPU瓶颈：load,vmstat中r列

  1. 反应为CPU队列长度
  2. 一段时间内，CPU正在处理和等待CPU处理的进程数之和，直接反应了CPU的使用和申请情况。
  3. 理想的load average：核数CPU数0.7
    • CPU个数：grep ‘physical id’ /proc/cpuinfo sort -u
    • 核数：grep ‘core id’ /proc/cpuinfo sort -u wc -l
  4. 超过这个值就说明已经是CPU瓶颈了

CPU瓶颈

  1. us 用户CPU时间高超过90% 涉及到web服务器，cs 每秒上下文切换次数 例如我们调用系统函数，就要进行上下文切换，线程的切换，也要进程上下文切换，这个值要越小越好，太大了，要考虑调低线程或者进程的数目,例如在apache和nginx这种web服务器中，我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。系统调用也是，每次调用系统函数，我们的代码就会进入内核空间，导致上下文切换，这个是很耗资源，也要尽量避免频繁调用系统函数。上下文切换次数过多表示你的CPU大部分浪费在上下文切换，导致CPU干正经事的时间少了，CPU没有充分利用，是不可取的。
  2. cs可以对apache和nginx线程和进程数限制起到一定的参考作用

  3. 我们一般做性能测试时会进行几千并发甚至几万并发的测试，选择web服务器的进程可以由进程或者线程的峰值一直下调，压测，直到cs到一个比较小的值，这个进程和线程数就是比较合适的值了。

  4. 较好的趋势：主要是 swap使用少，swpd数值低。si so分页读取写入数值趋近于零