qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

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

　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不建议在正式环境测试，因为很耗费资源
　　对一个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
　　看来并行的实现还是有很多的细节，相比普通的查询来说更加复杂，而且消耗的资源更多，这个也就是在使用并行的时候需要权衡的一个原因。

posted on 2014-10-30 12:00 顺其自然EVO 阅读(300) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。
网站导航:
 
<2014年10月>
日一二三四五六
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜