欧美日韩一区久久,综合久久2o19,久久超级碰视频

通過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 閱讀(305) 評論(0) 編輯收藏所屬分類: 測試學習專欄

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: 如何進行Web服務的性能測試？利用drozer進行Android滲透測試 Appium Android Bootstrap源碼分析之命令解析執行 Fliptest—iOS 的應用A/B測試框架 iOS功能測試工具 Frank iOS單元測試框架Kiwi for iOS Appium Android Bootstrap之控件AndroidElement 移動應用測試框架—Calabash Android 簡介 Appium Server源碼分析之作為Bootstrap客戶端移植MonkeyRunner的圖片對比功能實現-Appium篇

qileilove

通過vmstat的簡單分析數據庫操作

導航

統計

常用鏈接

留言簿(55)

隨筆分類

隨筆檔案

文章分類

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜