通过vmstat的简单分析数据库操作 (r3笔记23天)

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

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