ITPub博客

首页 > 数据库 > Oracle > 通过vmstat的简单分析数据库操作

通过vmstat的简单分析数据库操作

Oracle 作者:rh_linux 时间:2014-10-14 22:38:05 0 删除 编辑
vmstat一直以来就是linux/unix中进行性能监控的利器,相比top来说它的监控更加系统级,更侧重于系统整体的情况。
今天在学习vmstat的时候,突然想看看数据库中的并行对于系统级的影响到底有多紧密,自己简单测试了一下。
首先来看看vmstat的命令的解释。
可能大家并不陌生,如果需要每隔2秒,生成3次报告,可以使用vmstat 2 3
对于命令的输出解释如下:
r代表等待cpu事件的进程数
b代表处于不可中断休眠中的进程数,
swpd表示使用的虚拟内存的总量,单位是M
free代表空闲的物理内存总量,单位是M
buffer代表用作缓冲区的内存总量
cache代表用做高速缓存的内存总量
si代表从磁盘交换进来的内存总量
so代表交换到磁盘的内存总量
bi代表从块设备收到的块数,单位是1024bytes
bo代表发送到块设备的块数
in代表每秒的cpu中断次数
cs代表每秒的cpu上下文切换次数
us代表用户执行非内核代码的cpu时间所占的百分比
sy代表用于执行那个内核代码的cpu时间所占的百分比
id代表处于空闲状态的cpu时间所占的百分比
wa代表等待io的cpu时间所占的百分比

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      0 296716 399588 904276    0    0     0    16  639 1285  0  0 100  0  0
 0  0      0 296576 399588 904276    0    0    43    11  809 1484  1  1 98  0  0
 0  0      0 296576 399592 904276    0    0    53    25  764 1538  0  0 99  0  0
 0  0      0 296584 399592 904276    0    0     0    11  716 1502  0  0 100  0  0
 0  0      0 296584 399600 904276    0    0    21    16  756 1534  0  0 100  0  0

零零总总说了一大堆,我们举几个例子,一个是文件的拷贝,这个最直接的io操作。看看在vmstat的监控下会有什么样的数据变化。
黄色部分代表开始运行cp命令时vmstat的变化,我们拷贝的文件是200M,可以看到空闲内存立马腾出了将近200M的内存空间,buffer空间基本没有变化,这部分空间都放入了cache,同时从设备收到的块数也是急剧增加,cpu上下文的切换次数也是从930瞬间达到了1918,然后慢慢下降,cpu的使用率也是瞬间上升,最后基本控制在20%~30%。
 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      0 296716 399588 904276    0    0     0    16  639 1285  0  0 100  0  0
 0  0      0 296576 399588 904276    0    0    43    11  809 1484  1  1 98  0  0
 0  0      0 296576 399592 904276    0    0    53    25  764 1538  0  0 99  0  0
 0  0      0 296584 399592 904276    0    0     0    11  716 1502  0  0 100  0  0
 0  0      0 296584 399600 904276    0    0    21    16  756 1534  0  0 100  0  0
 0  0      0 296584 399600 904276    0    0     0    11  930 1625  1  1 98  0  0
 1  1      0  93960 399608 1104528    0    0 33427    24 1918 2094  0 23 71  7  0
 1  0      0  66440 399592 1131832    0    0  7573    12 1513 1323  0 25 74  2  0
 5  0      0  74988 399588 1123188    0    0  2859    33  887  594  0 24 75  1  0
11  0      0  74280 399572 1114952    0    0  1963    15  770  738  3 44 53  0  0
 2  0      0  74492 399568 1125008    0    0  3776    16 1014  812  0 20 73  6  0
 2  0      0  72640 399560 1126696    0    0  2411    23  975  619  1 21 78  0  0
 1  0      0  70532 399556 1128936    0    0  2389    16 1018  732  0 22 77  0  0
 2  0      0  75396 399532 1116288    0    0  2795    15  831  673  2 47 51  0  0
 2  0      0  79576 399536 1121416    0    0  2901    20  850  688  1 24 63 12  0
 0  3      0  67052 399536 1130252    0    0  1493 43708  701  644  0 29 24 47  0
 1  0      0  74244 399540 1125600    0    0  1323    19  842  624  0 10 65 25  0
 3  0      0  70788 399532 1127728    0    0  2539 21152  936  624  0 18 58 24  0
 5  0      0  73164 399532 1120352    0    0  1109    27  458  447  4 71 17  9  0
 0  0      0  76120 399532 1125684    0    0  1859    15  957 1182  0 19 80  1  0
 0  0      0  76128 399532 1125688    0    0    21    19  679 1399  0  0 98  1  0  --拷贝工作完成系统的负载又逐步恢复了原值。

对于文件的操作有了一个基本认识,来看看数据库级的操作吧。
首先看看全表扫描的情况。
我们对于一个170万数据的表进行查询。可以看到

从设备收到的块数是急剧增加,效果跟文件的拷贝有些类似,但是buffer,cache基本没有变化。我想这也就是数据库级别的操作和系统级别的根本区别吧。数据库的buffer_cache应该就是起这个作用的。
SQL> select count(*)from test where object_id<>1;

  COUNT(*)
----------
   1732096
[ora11g@rac1 arch]$ vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b     swpd   free   buff       cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 166520 399680 1023292    0    0    17    20    6    5  1  1 98  1  0
 0  0      0 175800 399680 1023292    0    0    53    11  680 1308  0  0 100  0  0
 1  0      0 175800 399680 1023292    0    0 18021    24 1451 1826  2  7 66 25  0
 0  0      0 175800 399680 1023292    0    0    53    53  812 1577  0  0 98  2  0
 0  0      0 166256 399680 1023292    0    0     0    16  881 1614  1  1 98  0  0
 1  0      0 175908 399680 1023292    0    0    21    11  866 1605  0  0 99  0  0

接着来做一个更为消耗资源的操作,这个sql不建议在正式环境测试,因为很耗费资源,
http://blog.itpub.net/23718752/viewspace-1261467/  里面之前提到过一个运行了3天的sql语句就是类似的例子。
对一个170多万的表进行低效的连接。vmstat的情况如下。运行了较长的时间,过了好一段时间都没有结束,可以看到cpu的使用率已经达到了40~50%,在开始的时候,从设备中得到的块数急剧增加,然后基本趋于一个平均值,buffer,cache基本没有变化。
SQL> select count(*)from test t1,test t2 where t1.object_id=t2.object_id;
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      0 176024 399688 1023292    0    0    43    11  655 1284  0  0 99  1  0
 1  0      0 171420 399688 1023292    0    0     0    16  671 1302  1  1 98  0  0
 0  0      0 176164 399688 1023292    0    0     0    11  735 1331  0  1 99  0  0
 0  0      0 176164 399688 1023292    0    0    21    25  678 1291  0  0 99  0  0
 1  0      0 173452 399688 1023292    0    0 15643  5256 1835 2178  6 12 76  6  0
 2  0      0 163048 399688 1023292    0    0 15179  5748 2166 2271  7 12 67 14  0
 1  0      0 172072 399688 1023292    0    0  5541  2432 2226 1860 32  6 59  3  0
 1  0      0 169964 399688 1023292    0    0   656    24 2322 1656 46  1 50  4  0
 1  0      0 169848 399688 1023292    0    0   485    11 2335 1637 48  1 50  2  0
 1  0      0 159576 399692 1023288    0    0   448   115 2442 1738 49  1 48  2  0
 1  0      0 169344 399692 1023292    0    0   712    11 2351 1701 47  1 50  3  0
 1  0      0 169352 399696 1023288    0    0   619    24 2332 1649 48  1 49  2  0
 1  0      0 169360 399696 1023292    0    0   467    11 2339 1623 47  1 50  2  0
 1  0      0 159848 399700 1023288    0    0   693    16 2318 1673 48  1 48  3  0
 1  0      0 169368 399700 1023292    0    0   467    11 2309 1660 47  1 50  3  0
 2  0      0 169368 399700 1023292    0    0   467    28 2329 1624 48  1 50  2  0

来看看并行的效果。最后返回的条数有近亿条,这也就是这个连接低效的原因所在,但是在vmstat得到的信息来看和普通的数据查询还是有很大的差别。

首先是急剧消耗io,同时从内存中也取出了一块内存空间。然后io基本趋于稳定,开始急剧消耗cpu资源。可以看到cpu的使用率达到了90%以上。
SQL> select count(*)from test t1,test t2 where t1.object_id=t2.object_id;

  COUNT(*)
----------
 221708288
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      0 175048 399748 1023292    0    0     0    20  665 1274  0  0 100  0  0
 0  0      0 175048 399748 1023292    0    0    21    11  657 1286  0  0 100  0  0
 0  0      0 165644 399748 1023292    0    0     0    16  715 1310  1  1 98  0  0
 0  0      0 175056 399748 1023292    0    0     0    11  664 1284  0  0 99  0  0
 0  0      0 175056 399748 1023292    0    0    21    24  640 1289  0  0 99  0  0
 0  4      0 142364 399748 1025408    0    0  5957   988 1407 1869 10  8 64 18  0
 0  0      0 132092 399748 1025444    0    0 12520  4939 1903 2556 14 11 32 43  0
 0  2      0 140248 399748 1025444    0    0 10477  3973 1728 2427 11  7 29 53  0
 2  0      0 136776 399748 1025444    0    0  7987  4125 1536 2248 11  6 24 60  0
 2  0      0 136776 399748 1025444    0    0   971    20 2427 1663 98  1  0  1  0
 2  0      0 121404 399748 1025456    0    0  1160    11 2422 1730 96  3  0  1  0
 2  0      0 134528 399748 1025460    0    0  1195    17 2399 1695 97  2  0  2  0
 3  0      0 134520 399748 1025460    0    0  1325    19 2443 1693 96  1  0  3  0
 2  0      0 134536 399748 1025460    0    0  1176    16 2405 1674 99  1  0  0  0
 2  0      0 125108 399748 1025460    0    0  1139    11 2418 1647 97  2  0  1  0
 2  0      0 134628 399752 1025460    0    0  1235    16 2391 1653 98  1  0  1  0
 3  0      0 134644 399752 1025460    0    0  1197    21 2392 1640 97  2  0  1  0
 2  0      0 134652 399756 1025460    0    0  1400    16 2433 1670 97  1  0  3  0
 2  0      0 125116 399756 1025460    0    0  1008    11 2199 1564 97  2  0  1  0


看来并行的实现还是有很多的细节,相比普通的查询来说更加复杂,而且消耗的资源更多,这个也就是在使用并行的时候需要权衡的一个原因。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1696240/viewspace-1298962/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2014-05-18

  • 博文量
    43
  • 访问量
    163189