透過vmstat的簡單分析資料庫操作
今天在學習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/28389881/viewspace-1298557/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 通過vmstat的簡單分析資料庫操作資料庫
- 如何透過SQLyog分析MySQL資料庫MySql資料庫
- ASP資料庫簡單操作教程資料庫
- php簡單操作mysql資料庫的類PHPMySql資料庫
- RUBY實踐—資料庫簡單操作資料庫
- Java操作Redis資料庫方法（簡單）JavaRedis資料庫
- 一個簡單可分享的web資料透視分析Web
- 如何透過一條資料庫語句做資料分析資料庫
- Standby資料庫簡單建立過程資料庫
- Sqlla: 資料庫操作從未如此簡單SQL資料庫
- 簡單php連線資料庫作操作PHP資料庫
- 透過等待看資料庫資料庫
- DOCKER簡明教程 : 透過容器連線REDIS資料庫DockerRedis資料庫
- ActiveRecord透過Transaction來確保對資料庫操作成功資料庫
- oracle透過expdp的remap_data實現簡單的資料脫敏OracleREM
- 【資料庫資料恢復】透過資料頁恢復Sql Server資料庫資料的過程資料庫資料恢復SQLServer
- 測了一下 透過 DBCA 透過模板 複製資料庫（資料庫架構及資料）資料庫架構
- 簡單分析Flask 資料庫遷移詳情Flask資料庫
- 透過 srvctl來管理單例項11g資料庫單例資料庫
- 一個通過rms寫成的小型資料庫引擎,簡單的資料庫引擎資料庫
- 透過socket訪問資料庫(轉)資料庫
- Teradata資料庫功能操作簡單介紹(轉載)資料庫
- Tableau簡單的資料視覺化操作視覺化
- 簡單分析oracle的資料儲存Oracle
- 【資料庫資料恢復】透過恢復NDF檔案修復資料庫的資料恢復過程資料庫資料恢復
- 透過rman全庫備份遷移資料庫資料庫
- Mysql 5.7透過mysqldump還原資料庫MySql資料庫
- 直接透過備份恢復資料庫資料庫
- 兩種簡單分析和優化MySQL資料庫表的方法優化MySql資料庫
- 資料庫的最簡單實現資料庫
- 操作簡單的BI資料分析軟體有哪些？實際體驗如何？
- 如何透過資料分析來支援TPM模式的決策？模式
- 別人是怎麼透過海關資料開單的
- 資料遷移工具簡單分析
- 如何透過.dbf檔案還原資料庫資料庫
- AIX vmstat分析AI
- Laravel Database——資料庫的 CRUD 操作原始碼分析LaravelDatabase資料庫原始碼
- Python資料分析庫pandas基本操作Python