码迷,mamicode.com
首页 > 其他好文 > 详细

vmstat-虚拟内存查看实例

时间:2019-06-30 11:18:19      阅读:108      评论:0      收藏:0      [点我收藏+]

标签:priority   sys   应用程序   使用   ps aux   ons   out   dash   solar   

虚拟内存运行原理

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

在Linux内存管理中,主要是通过“调页Paging”和“交换Swapping”来完成上述的内存调度。调页算法是将内存中最近不常使用的页面换到磁盘上,把活动页面保留在内存中供进程使用。交换技术是将整个进程,而不是部分页面,全部交换到磁盘上。

分页(Page)写入磁盘的过程被称作Page-Out,分页(Page)从磁盘重新回到内存的过程被称作Page-In。当内核需要一个分页时,但发现此分页不在物理内存中(因为已经被Page-Out了),此时就发生了分页错误(Page Fault)。

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

使用vmstat

1.用法

vmstat [-a] [-n] [-S unit] [delay [ count]]

vmstat [-s] [-n] [-S unit]

vmstat [-m] [-n] [delay [ count]]

vmstat [-d] [-n] [delay [ count]]

vmstat [-p disk partition] [-n] [delay [ count]]

vmstat [-f]

vmstat [-V]

-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版本信息。

实例

     例子1:每2秒输出一条结果

 

字段说明:

Procs(进程):

r: 运行的和等待(CPU时间片)运行的进程数,这个值也可以判断是否需要增加CPU(长期大于1)

b: 等待IO的进程数量,处于不可中断状态的进程数,常见的情况是由IO引起的

Memory(内存):

swpd: 使用虚拟内存大小,切换到交换内存上的内存(默认以KB为单位)

如果 swpd 的值不为0,或者还比较大,比如超过100M了,但是 si, so 的值长期为 0,这种情况我们可以不用担心,不会影响系统性能。

free: 空闲的物理内存

buff: 用作缓冲的内存大小

cache: 用作缓存的内存大小,文件系统的cache,如果 cache 的值大的时候,说明cache住的文件数多,如果频繁访问到的文件都能被cache住,那么磁盘的读IO bi 会非常小

Swap

si: 每秒从交换区写到内存的大小,交换内存使用,由磁盘调入内存

so: 每秒写入交换区的内存大小,交换内存使用,由内存调入磁盘

内存够用的时候,这2个值都是0,如果这2个值长期大于0时,系统性能会受到影响。磁盘IO和CPU资源都会被消耗。

常有人看到空闲内存(free)很少或接近于0时,就认为内存不够用了,实际上不能光看这一点的,还要结合si,so,如果free很少,但是si,so也很少(大多时候是0),那么不用担心,系统性能这时不会受到影响的。

IO:(现在的Linux版本块的大小为1024bytes

bi: 每秒读取的块数,从块设备读入的数据总量(读磁盘) (KB/s)

bo: 每秒写入的块数,写入到块设备的数据总理(写磁盘) (KB/s)

随机磁盘读写的时候,这2个 值越大(如超出1M),能看到CPU在IO等待的值也会越大

system

in: 每秒中断数,包括时钟中断。

cs: 每秒上下文切换数。

上面这2个值越大,会看到由内核消耗的CPU时间会越多

CPU(以百分比表示):

us: 用户进程消耗的CPU时间百分比,us 的值比较高时,说明用户进程消耗的CPU时间多,但是如果长期超过50% 的使用,那么我们就该考虑优化程序算法或者进行加速了

sy: 内核进程消耗的CPU时间百分比,sy 的值高时,说明系统内核消耗的CPU资源多,这并不是良性的表现,我们应该检查原因。

id: CPU处在空闲状态时间百分比(包括IO等待时间)

wa: IO等待消耗的CPU时间百分比,wa 的值高时,说明IO等待比较严重,这可能是由于磁盘大量作随机访问造成,也有可能是磁盘的带宽出现瓶颈(块操作)。

例子2:显示活跃和非活跃内存

    

使用-a选项显示活跃和非活跃内存时,所显示的内容除增加inact和active外,其他显示内容与例子1相同。

字段说明:

Memory(内存):

inact: 非活跃内存大小(当使用-a选项时显示)

active: 活跃的内存大小(当使用-a选项时显示)

注:如果r经常大于4,且id经常少于40,表示cpu的负荷很重,如果bi,bo长期不等于0,表示内存不足,如果disk经常不等于0,且在b中的队列大于3,表示io性能不好。

CPU问题现象:

1.)如果在processes中运行的序列(process r)是连续的大于在系统中的CPU的个数表示系统现在运行比较慢,有多数的进程等待CPU.

2.)如果r的输出数大于系统中可用CPU个数的4倍的话,则系统面临着CPU短缺的问题,或者是CPU的速率过低,系统中有多数的进程在等待CPU,造成系统中进程运行过慢.

3.)如果空闲时间(cpu id)持续为0并且系统时间(cpu sy)是用户时间的两倍(cpu us)系统则面临着CPU资源的短缺.

解决办法:

当发生以上问题的时候请先调整应用程序对CPU的占用情况.使得应用程序能够更有效的使用CPU.同时可以考虑增加更多的CPU.  关于CPU的使用情况还可以结合mpstat,   ps aux top   prstat –a等等一些相应的命令来综合考虑关于具体的CPU的使用情况,和那些进程在占用大量的CPU时间.一般情况下,应用程序的问题会比较大一些.比如一些SQL语句不合理等等都会造成这样的现象.

内存问题现象:

内存的瓶颈是由scan rate (sr)来决定的.scan rate是通过每秒的始终算法来进行页扫描的.如果scan rate(sr)连续的大于每秒200页则表示可能存在内存缺陷.同样的如果page项中的pi和po这两栏表示每秒页面的调入的页数和每秒调出的页数.如果该值经常为非零值,也有可能存在内存的瓶颈,当然,如果个别的时候不为0的话,属于正常的页面调度这个是虚拟内存的主要原理.

解决办法:

1.调节applications & servers使得对内存和cache的使用更加有效.

2.增加系统的内存.

3. Implement priority paging in s in pre solaris 8 versions by adding line "set priority paging=1" in

/etc/system. Remove this line if upgrading from Solaris 7 to 8 & retaining old /etc/system file.

关于内存的使用情况还可以结ps aux top   prstat –a等等一些相应的命令来综合考虑关于具体的内存的使用情况,和那些进程在占用大量的内存.一般情况下,如果内存的占用率比较高,但是,CPU的占用很低的时候,可以考虑是有很多的应用程序占用了内存没有释放,但是,并没有占用CPU时间,可以考虑应用程序,对于未占用CPU时间和一些后台的程序,释放内存的占用

案例

     案例学习:

1:在这个例子中,这个系统被充分利用

# vmstat 1

procs                      memory      swap          io     system         cpu

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

3  0 206564  15092  80336 176080    0    0     0     0  718    26 81 19  0  0

2  0 206564  14772  80336 176120    0    0     0     0  758    23 96  4  0  0

1  0 206564  14208  80336 176136    0    0     0     0  820    20 96  4  0  0

1  0 206956  13884  79180 175964    0  412     0  2680 1008    80 93  7  0  0

2  0 207348  14448  78800 175576    0  412     0   412  763    70 84 16  0  0

2  0 207348  15756  78800 175424    0    0     0     0  874    25 89 11  0  0

1  0 207348  16368  78800 175596    0    0     0     0  940    24 86 14  0  0

1  0 207348  16600  78800 175604    0    0     0     0  929    27 95  3  0  2

3  0 207348  16976  78548 175876    0    0     0  2508  969    35 93  7  0  0

4  0 207348  16216  78548 175704    0    0     0     0  874    36 93  6  0  1

4  0 207348  16424  78548 175776    0    0     0     0  850    26 77 23  0  0

2  0 207348  17496  78556 175840    0    0     0     0  736    23 83 17  0  0

0  0 207348  17680  78556 175868    0    0     0     0  861    21 91  8  0  1

根据观察值,我们可以得到以下结论:

1.有大量的中断(in) 和较少的上下文切换(cs).这意味着一个单一的进程在产生对硬件设备的请求.

2.进一步显示某单个应用,user time(us)经常在85%或者更多.考虑到较少的上下文切换,这个应用应该还在处理器中被处理.

3.运行队列还在可接受的性能范围内,其中有2个地方,是超出了允许限制.

2:在这个例子中,内核调度中的上下文切换处于饱和

# vmstat 1

procs                      memory      swap          io     system         cpu

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

2  1 207740  98476  81344 180972    0    0  2496     0  900  2883  4 12 57 27

0  1 207740  96448  83304 180984    0    0  1968   328  810  2559  8  9 83  0

0  1 207740  94404  85348 180984    0    0  2044     0  829  2879  9  6 78  7

0  1 207740  92576  87176 180984    0    0  1828     0  689  2088  3  9 78 10

2  0 207740  91300  88452 180984    0    0  1276     0  565  2182  7  6 83  4

3  1 207740  90124  89628 180984    0    0  1176     0  551  2219  2  7 91  0

4  2 207740  89240  90512 180984    0    0   880   520  443   907 22 10 67  0

5  3 207740  88056  91680 180984    0    0  1168     0  628  1248 12 11 77  0

4  2 207740  86852  92880 180984    0    0  1200     0  654  1505  6  7 87  0

6  1 207740  85736  93996 180984    0    0  1116     0  526  1512  5 10 85  0

0  1 207740  84844  94888 180984    0    0   892     0  438  1556  6  4 90  0

根据观察值,我们可以得到以下结论:

1.上下文切换数目高于中断数目,说明kernel中相当数量的时间都开销在上下文切换线程.

2.大量的上下文切换将导致CPU 利用率分类不均衡.很明显实际上等待io 请求的百分比(wa)非常高,以及user time百分比非常低(us).

3.因为CPU 都阻塞在IO请求上,所以运行队列里也有相当数目的可运行状态线程在等待执行.

vmstat-虚拟内存查看实例

标签:priority   sys   应用程序   使用   ps aux   ons   out   dash   solar   

原文地址:https://www.cnblogs.com/fanweisheng/p/11108990.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!