• 公告栏使用li标签,同时你可以使用FontAwesome以及其他HTML语法
  • FontAwesome示例
  • 不必为自己的独特看法而害怕, 因为我们现在所接受的常识都曾是独特看法@《自由思想的十诫》罗素 (哲学家 数学家)

FreeBSD vmstat详解

*BSD shaobo 51次浏览 2412字 0个评论

top是给Linux设计的。在FreeBSD VM里面的Free概念和其他OS完全不同,使用top查看Free内存对于FreeBSD来说可以说没什么意义。正确的方法是看vmstat。

 # vmstat
  procs   memory          page                       disk   faults     cpu
  r b w   avm    fre      flt  re  pi   po   fr   sr ad0    in    sy   cs    us  sy id
  0 2 1   270512   20316  30   0   0    0    26   5  1223   1589  98   593   1   1  99

最好使用vmstat t [n]命令,例如 vmstat 5 10,表示在t(5)秒时间内进行n(10)次采样。如果只使用vmstat,无法反映真正的系统情况。

procs:
r-->在运行的进程数
b-->在等待io的进程数(等待i/o,paging等等)
w-->可以进入运行队列但被替换的进程
memoy(以kb为单位,包括虚拟内核和真实内存,正在运行或最近20秒在运行的进程所用的虚拟内存将被视为active)
avm-->活动的虚拟内存
free-->空闲的内存
pages(统计错误页和活动页,每5秒平均一下,以秒为单位给出数值)
flt-->错误页总数
re-->回收的页面
pi-->进入页面数
po-->出页面数
fr-->空余的页面数
sr-->每秒通过时钟算法扫描的页面
disk 显示每秒的磁盘操作(磁盘名字的前两个字母加数字,默认只显示两个磁盘,如果有多的,可以加-n来增加数字或在命令行下把磁盘名都填上。)

fault 显示每秒的中断数
in-->设备中断
sy-->系统中断
cs-->cpu交换(上下文切换)
cpu 表示cpu的使用状态
cs-->用户进程使用的时间
sy-->系统进程使用的时间
id-->cpu空闲的时间

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

以下是一个繁忙批量插入MySQL数据(大概每隔20秒可以插入50万多条数据)的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 1 0 63  23302M   803M   845   0   0   0     0   0   0   0   17  124  499  6  0 94
 1 0 63  23302M   796M   837   0   0   0     2   0   1   0   18  158  505  6  0 94
 1 0 63  23302M   790M   833   0   0   0     6   0  76   0  159  143  910  6  0 94
 1 0 63  23302M   784M   868   0   0   0    16   0   8   0   34  156  550  6  0 94
 2 0 63  23456M   709M  8317   2   0   0  2383   0  95   0  295 5504 1930  8  1 91
 1 0 63  21975M  1281M 18909   3   0   0 94840   0 620   0 1893 64333 7822 10  4 87
 1 0 63  21975M  1281M   415   0   0   0   342   0   1   0   29  611  566  6  0 94
 1 0 63  22093M   978M 43503   0   0   0  5140   0 2187   0 4225  582 16279  6  2 92

循环插入到了后面,随着表越来越大,系统调用和上下文切换越来越频繁:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 1 0 63  23233M   536M 28219   0   0   0   352 51252 869   0 1864 14542 11015  2  3 95
 1 0 63  23349M   834M 12457   0   0   0     4 51247 2078   0 3945  179 14926  6  2 92
 2 0 63  27343M  3130M  9295   0   0   0  2708   0   2      0   73 6988 1377   7  1 92
 ....中间比较正常,因为插入时间比较久
 1 0 63  28788M  2934M 25760   0   0   0  5860   0   620   8 5529 42712 12924 11  2 86
 0 0 63  25963M  3081M  4379   0   0   0 24049   0   3445  15 11274 97350 31798  2  7 91
 0 0 63  33689M  1801M   388   0   0   0  4492   0 4403  15 8780 135421 35502  2  5 93

不熟悉mysql内部机制,但是很明显,随着表越来越大,表插入速度越来越慢,因为系统调用和上下文切换越来越频繁了,浪费了很多CPU时间。
到了mysql表里有六千万多条数据时,每插入五十万条记录,已经要耗时100s,整个mysql数据库变得很繁忙,一些几万数据的插入也慢慢不能及时处理。

以下是一个拷贝4G文件到远程NFS的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 2 0 63  19731M  2400M 24415   0   0   0 70077   0  14   0  591 3915 1770 12  1 87
 0 0 63  16352M  3594M   443   0   0   0 154948   0 2471   0 5067 17602 19448  1  2 96
 0 0 63  16352M  3594M     0   0   0   0     0   0 772   0 1590  134 6577  0  0 100
 0 0 63  16352M  3594M     0   0   0   0     0   0 856   0 1750  164 7135  0  0 100
 0 0 63  16361M  3594M  1112   0   0   0  1030   0 400   0  815 1248 3620  0  0 100
 0 0 63  16361M  3594M     0   0   0   0     0   0   0   0   15  116  488  0  0 100
 0 0 63  16352M  3594M   329   0   0   0   352   0 2186   0 4275  595 15809  0  2 98
 0 0 63  16352M  3594M     0   0   0   0     0   0 270   0  532  134 3186  0  0 100
 0 0 63  16352M  3594M     0   0   0   0     0   0 185   0  368  164 2062  0  0 100

 

最后稳定下来,状态良好的vmstat例子:

 procs      memory      page                    disks     faults         cpu
 r b w     avm    fre   flt  re  pi  po    fr  sr da0 da1   in   sy   cs us sy id
 0 0 63  16292M  3564M     0   0   0   0     0   0   0   0   12  142  472  0  0 100

 


喜欢 (0)

您必须 登录 才能发表评论!