1、.：.；最近不斷在思索一個(gè)問(wèn)題：如何為一個(gè)數(shù)據(jù)庫(kù)建立性能模型？作為一名DBA來(lái)說(shuō)，我們面臨的一個(gè)宏大挑戰(zhàn)是：如何保證數(shù)據(jù)庫(kù)的性能可以滿足快速變化的運(yùn)用的需求，如何在數(shù)據(jù)量和訪問(wèn)量繼續(xù)增長(zhǎng)的情況下，保證運(yùn)用的呼應(yīng)時(shí)間和數(shù)據(jù)庫(kù)的負(fù)載處在合理的程度下。我們能夠會(huì)經(jīng)常面對(duì)以下的問(wèn)題：某個(gè)SQL每秒要執(zhí)行100次，呼應(yīng)時(shí)間是多少？某個(gè)運(yùn)用發(fā)布后，對(duì)數(shù)據(jù)庫(kù)的影響如何？所以，評(píng)價(jià)運(yùn)用對(duì)數(shù)據(jù)庫(kù)所產(chǎn)生的影響，優(yōu)化運(yùn)用并預(yù)測(cè)風(fēng)險(xiǎn)，保證數(shù)據(jù)庫(kù)的可用性和穩(wěn)定性，這是運(yùn)用DBA真正有價(jià)值的地方。呼應(yīng)時(shí)間為中心：假設(shè)要選擇一個(gè)評(píng)價(jià)系統(tǒng)優(yōu)劣的性能目的，毫無(wú)疑問(wèn)應(yīng)該是呼應(yīng)時(shí)間。呼應(yīng)時(shí)間是客戶體驗(yàn)的第一要素，一切的優(yōu)化都應(yīng)該為

2、降低呼應(yīng)時(shí)間而努力。對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)也是如此，我們優(yōu)化系統(tǒng)，優(yōu)化SQL，最終目的都是為了降低呼應(yīng)時(shí)間，單位時(shí)間內(nèi)可以處置更多的懇求。數(shù)據(jù)庫(kù)時(shí)間模型：呼應(yīng)時(shí)間普通分為效力時(shí)間(Service time)和等待時(shí)間(Wait time)，效力時(shí)間指進(jìn)程占用CPU的時(shí)間，包括前臺(tái)進(jìn)程(Server process)和后臺(tái)進(jìn)程(Backgroud process)，我們普通只關(guān)注前臺(tái)進(jìn)程占用的CPU time。等待時(shí)間包括很多類(lèi)型，普通最常見(jiàn)的是IO等待和并發(fā)等待，IO等待包括sequential read，scattered read和log file sync等等，而并發(fā)等待主要是latch和enq

3、ueue。SQL execute elapsed time指用戶進(jìn)程執(zhí)行SQL的呼應(yīng)時(shí)間，包含CPU time和wait time。以下是Oracle數(shù)據(jù)庫(kù)的時(shí)間模型：在Oracle系統(tǒng)中，我們可以利用AWR或Statspack報(bào)告，看到數(shù)據(jù)庫(kù)的時(shí)間信息：Statistic NameTime (s)% of DB Timesql execute elapsed time3,062.1791.52DB CPU2,842.0884.95parse time elapsed25.870.77PL/SQL execution elapsed time11.750.35sequence load ela

4、psed time7.550.23hard parse elapsed time5.060.15connection management call elapsed time3.130.09hard parse (sharing criteria) elapsed time0.040.00repeated bind elapsed time0.010.00PL/SQL compilation elapsed time0.000.00DB time3,345.74background elapsed time204.91background cpu time72.30DB time是整個(gè)數(shù)據(jù)庫(kù)用

5、戶進(jìn)程耗費(fèi)的總時(shí)間，是從第一項(xiàng)到第十項(xiàng)時(shí)間的總和從sql execute elapsed time到PL/SQL compilation elapsed time，但是我們會(huì)發(fā)現(xiàn)這十項(xiàng)時(shí)間的總和比DB Time要大一些，這是由于部分時(shí)間信息有重疊的部分，比如SQL execute elapsed time就包括了很大一部分DB cpu的時(shí)間。而background elapsed time和background cpu time那么是Oracle后臺(tái)進(jìn)程耗費(fèi)的時(shí)間和cpu time。數(shù)據(jù)庫(kù)呼應(yīng)時(shí)間分析：數(shù)據(jù)庫(kù)系統(tǒng)的呼應(yīng)時(shí)間由四個(gè)要素決議：CPU，IO，內(nèi)存和網(wǎng)絡(luò)，其中CPU和IO是最重要的要素

6、。與之相比，內(nèi)存與網(wǎng)絡(luò)那么簡(jiǎn)單很多，由于通常情況下，對(duì)于一個(gè)調(diào)優(yōu)的系統(tǒng)來(lái)說(shuō)，內(nèi)存訪問(wèn)的延遲時(shí)間非常小100 ns以下，1 ms=1000000 ns相比較CPU和IO幾乎可以忽略。而網(wǎng)絡(luò)延遲那么通常是一個(gè)常數(shù)，比如在一個(gè)數(shù)據(jù)中心的情況下，網(wǎng)絡(luò)的延遲普通在3ms以下，假設(shè)存在多數(shù)據(jù)中心的情況，網(wǎng)絡(luò)延遲能夠會(huì)超越20ms，所以對(duì)于一個(gè)分布式系統(tǒng)來(lái)說(shuō)，網(wǎng)絡(luò)延遲是必需求思索的問(wèn)題。在這里，我們不思索分布式系統(tǒng)，并且忽略內(nèi)存的訪問(wèn)延遲，重點(diǎn)分析CPU和IO，我們看以下數(shù)據(jù)庫(kù)的AWR片段：我們看到這個(gè)系統(tǒng)中DB CPU占整個(gè)DB time的87.21%，User I/O占整個(gè)DB time的9.12%，c

7、ommit相關(guān)的IO等待占2.35%主要是log file sync，CPU和IO占用了整個(gè)DB time的96.68%。由于DB CPU所占的比例很高，所以這個(gè)數(shù)據(jù)庫(kù)系統(tǒng)是CPU intensive類(lèi)型，這里的DB CPU主要是執(zhí)行SQL的效力時(shí)間。我們?cè)倏戳硗獾囊粋€(gè)數(shù)據(jù)庫(kù)的AWR片段：我們看到，Commit和User I/O占DB time的81.46%，而DB CPU只占13.82%，所以這個(gè)數(shù)據(jù)庫(kù)系統(tǒng)是IO instensive類(lèi)型的。Physical readPhysical read是指Oracle在buffer cache中沒(méi)有找到相應(yīng)的block，需求從IO子系統(tǒng)讀取相應(yīng)的bl

8、ock的過(guò)程，對(duì)應(yīng)的IO稱(chēng)為物理IO，物理讀數(shù)量代表物理IO讀取的block數(shù)量。由于普通IO子系統(tǒng)都是慢速的磁盤(pán)，所以物理IO對(duì)整體呼應(yīng)時(shí)間的影響非常大，假設(shè)發(fā)生大量的物理IO，整個(gè)系統(tǒng)的呼應(yīng)時(shí)間會(huì)變得很差。系統(tǒng)的IO子系統(tǒng)能夠是文件系統(tǒng)，裸設(shè)備或者ASM，底層硬件能夠是SAN存儲(chǔ)，NAS存儲(chǔ)或者普通SAS磁盤(pán)等等。為了提高呼應(yīng)時(shí)間，通常在物理磁盤(pán)與Oracle之間添加cache層，對(duì)于Oracle來(lái)說(shuō)，物理IO并不一定是真正訪問(wèn)磁盤(pán)，很能夠是訪問(wèn)文件系統(tǒng)cache，存儲(chǔ)的cache等等。不論IO subsystem是什么，Oracle只關(guān)懷物理IO的呼應(yīng)時(shí)間。經(jīng)過(guò)AWR報(bào)告，我們可以看到物

9、理IO的呼應(yīng)時(shí)間：db file sequential read單塊讀，隨機(jī)IO的平均呼應(yīng)時(shí)間為3ms，db file scattered read多塊讀，延續(xù)IO的平均呼應(yīng)時(shí)間是4ms，logfile file sync的平均呼應(yīng)時(shí)間是3ms，前兩者的Wait class是User I/O，代表用戶進(jìn)程讀操作的呼應(yīng)時(shí)間，logfile sync的wait class是Commit，代表lgwr進(jìn)程寫(xiě)redo的呼應(yīng)時(shí)間，由于用戶commit必需完成log file sync的操作，所以它也會(huì)直接影響用戶進(jìn)程寫(xiě)操作的呼應(yīng)時(shí)間。關(guān)于物理IO的呼應(yīng)時(shí)間，我們有一個(gè)閱歷值。對(duì)于Sequential r

10、ead和Scattered read，我們以為小于10ms屬于正常形狀，而大于10ms那么以為IO subsystem的呼應(yīng)延遲過(guò)大。所以我們?cè)诤饬看鎯?chǔ)系統(tǒng)的性能時(shí)，只需呼應(yīng)時(shí)間在10ms以下的IO我們以為是有效的。這里有一個(gè)有趣的景象，就是sequential read和scattered read的呼應(yīng)時(shí)間幾乎相差無(wú)幾，也就是說(shuō)隨機(jī)IO讀取8K數(shù)據(jù)和延續(xù)IO讀取128K數(shù)據(jù)，呼應(yīng)時(shí)間差別很小，這是由磁盤(pán)的機(jī)械特性呵斥的，延遲時(shí)間=尋道時(shí)間+對(duì)于log file sync的呼應(yīng)時(shí)間，由于用戶commit必需完成log file sync，所以整個(gè)系統(tǒng)的寫(xiě)操作的呼應(yīng)時(shí)間都取決于它的呼應(yīng)時(shí)間，而

11、且從整個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的角度去看，log file sync幾乎是串行的，所以這個(gè)呼應(yīng)時(shí)間對(duì)寫(xiě)操作影響非常大，我們的閱歷值是必需保證在5ms以下，假設(shè)超越5ms整個(gè)系統(tǒng)的寫(xiě)操作都會(huì)遭到嚴(yán)重的影響。Logical readLogical read是Oracle從buffer cache中讀取block的過(guò)程，對(duì)應(yīng)的IO稱(chēng)為邏輯IO，邏輯讀數(shù)量代表邏輯IO讀取的block數(shù)量。由于Oracle必需首先將block讀入buffer cache中(direct path read除外)，所以邏輯讀數(shù)量包含了物理讀數(shù)量。對(duì)于一個(gè)SQL來(lái)說(shuō)，邏輯讀數(shù)量是衡量其性能的規(guī)范，而不是物理讀。雖然物理IO的呼應(yīng)延遲比

12、邏輯IO大很多，但是物理讀數(shù)量會(huì)隨著執(zhí)行次數(shù)而變化頻繁讀取導(dǎo)致block被緩存在buffer cache中。對(duì)于一個(gè)系統(tǒng)也是如此，邏輯讀應(yīng)該是數(shù)據(jù)庫(kù)性能評(píng)價(jià)模型的中心，我們需求建立邏輯讀與呼應(yīng)時(shí)間的對(duì)應(yīng)關(guān)系。每個(gè)邏輯讀的呼應(yīng)時(shí)間是多少，這是一個(gè)宏大的挑戰(zhàn)。由于每個(gè)邏輯讀背后隱藏了很多動(dòng)作，能夠包括物理讀，等待事件，CPU time等等。我對(duì)很多數(shù)據(jù)庫(kù)的AWR報(bào)告做了分析，期望根據(jù)閱歷值建立一個(gè)簡(jiǎn)化的模型。我們假設(shè)一個(gè)數(shù)據(jù)庫(kù)假設(shè)是充分調(diào)優(yōu)的，除CPU time和IO以外的等待時(shí)間應(yīng)該盡能夠少應(yīng)小于DB time 10%。在這個(gè)前提下，我們只關(guān)懷CPU time和IO的影響，并將系統(tǒng)分為三類(lèi)：CP

13、U密集型，IO密集型和混合型：1.IO密集型User IO 85%DB CPU 5%每邏輯讀呼應(yīng)時(shí)間0.1-0.5ms2.CPU密集型DB CPU 85%User IO 10%每邏輯讀呼應(yīng)時(shí)間小于0.01ms3.混合型User I/O 60%DB CPU 20%每邏輯讀呼應(yīng)時(shí)間0.05-0.1ms以上數(shù)據(jù)是根據(jù)很多個(gè)典型數(shù)據(jù)庫(kù)的AWR報(bào)告計(jì)算出來(lái)的閱歷值，計(jì)算公式很簡(jiǎn)單：DB time/邏輯讀=每邏輯讀呼應(yīng)時(shí)間。由于并沒(méi)有思索硬件和OS上的差別，所以這個(gè)數(shù)值并不是特別準(zhǔn)確，但我們還是可以發(fā)現(xiàn)一些規(guī)律：隨著IO所占比例從10%添加到85%，呼應(yīng)時(shí)間也從小于0.01ms到0.5ms。預(yù)測(cè)系統(tǒng)瓶頸對(duì)

14、于數(shù)據(jù)庫(kù)來(lái)說(shuō)，IO子系統(tǒng)對(duì)性能影響非常大，必需保證在一定的IO的壓力下，呼應(yīng)延遲控制在合理的范圍內(nèi)前面說(shuō)的10ms和5ms。由于每塊磁盤(pán)可以接受的IOPS是根本確定的，比如15K的SAS磁盤(pán)，在呼應(yīng)延遲不超越10ms的前提下，可以提供150個(gè)IOPS，假設(shè)不思索cache的影響，整個(gè)存儲(chǔ)子系統(tǒng)的IOPS是比較容易計(jì)算的。我們可以在系統(tǒng)上線前，進(jìn)展大量充分的測(cè)試，建立存儲(chǔ)IOPS與呼應(yīng)延遲的模型，這樣我們就可以預(yù)測(cè)出性能出現(xiàn)拐點(diǎn)的風(fēng)險(xiǎn)，提早做出擴(kuò)容的判別。在AWR報(bào)告中，我們可以得到每秒的物理IO的數(shù)量和呼應(yīng)時(shí)間，可以方便的實(shí)現(xiàn)性能監(jiān)控和趨勢(shì)預(yù)警。評(píng)價(jià)CPU的容量瓶頸相對(duì)簡(jiǎn)單，Oracle中CP

15、U time的計(jì)算是每個(gè)CPU耗費(fèi)時(shí)間的總和，假設(shè)有16顆(核)CPU，1個(gè)小時(shí)實(shí)際上可以提供360016=57600s CPU time，不超越57600s CPU time我們可以以為不會(huì)在CPU上排隊(duì)，系統(tǒng)不會(huì)出現(xiàn)CPU瓶頸。但是需求留意的是，除了用戶進(jìn)程運(yùn)用CPU以外，操作系統(tǒng)也需求占用CPU資源，用來(lái)管理內(nèi)存和進(jìn)程調(diào)度等。我們?cè)贠S上看到的CPU運(yùn)用率中的sys部分就是系統(tǒng)占用的CPU資源，所以應(yīng)該思索至少保管10-20%的CPU資源給OS運(yùn)用。并發(fā)訪問(wèn)對(duì)數(shù)據(jù)庫(kù)的影響Oracle是一個(gè)Disk-based database，設(shè)計(jì)的出發(fā)點(diǎn)就是大部分?jǐn)?shù)據(jù)在外部存儲(chǔ)中，而只需小部分?jǐn)?shù)據(jù)被c

16、ache在buffer中，它既不同于Memcache這類(lèi)KV cache，也不同于timesten這類(lèi)In-memory database。所以，就算是一切的數(shù)據(jù)都可以被cache在buffer中，在高并發(fā)訪問(wèn)的情況下，也能夠會(huì)出現(xiàn)大量的latch等待，最常見(jiàn)的情況就是cache buffer chain。當(dāng)大量并發(fā)訪問(wèn)同一塊數(shù)據(jù)時(shí)，就很能夠會(huì)出現(xiàn)cache buffer chain的latch爭(zhēng)用，也就是我們常說(shuō)的“熱點(diǎn)。需求留意的是：Oracle中的latch等待分為spin和sleep兩個(gè)部分，spin耗費(fèi)cpu time，而sleep那么是等待時(shí)間。所以大量的latch等待不僅僅會(huì)產(chǎn)生

17、大量的等待時(shí)間，而且會(huì)耗費(fèi)大量的CPU time。Oracle是一個(gè)為并發(fā)操作而設(shè)計(jì)的數(shù)據(jù)庫(kù)，大量的并發(fā)讀寫(xiě)懇求，能夠會(huì)帶來(lái)額外的性能耗費(fèi)。比如讀取一部分頻繁修正的數(shù)據(jù)，Oracle為了保證一致性讀的需求，會(huì)利用undo信息構(gòu)造產(chǎn)生大量CR block，同時(shí)會(huì)產(chǎn)生大量的邏輯讀，這樣會(huì)耗費(fèi)額外的CPU和呼應(yīng)時(shí)間。存儲(chǔ)也能夠存在熱點(diǎn)的問(wèn)題，需求前期對(duì)存儲(chǔ)系統(tǒng)充分的優(yōu)化，常見(jiàn)的手段是利用RAID技術(shù)，將數(shù)據(jù)分散在不同的磁盤(pán)上，防止出現(xiàn)“熱點(diǎn)盤(pán)。Oracle ASM提供了Rebalance的功能，允許DBA將存儲(chǔ)中的的數(shù)據(jù)重新分布，到達(dá)消除熱點(diǎn)的目的。總之，Oracle是一個(gè)可以提供大量并發(fā)讀寫(xiě)訪問(wèn)的

18、數(shù)據(jù)庫(kù)系統(tǒng)，但是在很多地方，Oracle又不得采用一些串行的控制手段，比如latch，enqueue和mutex，我們要做的就是盡量降低這些串行控制對(duì)數(shù)據(jù)庫(kù)整體性能的影響。數(shù)據(jù)庫(kù)優(yōu)化原那么基于呼應(yīng)時(shí)間的Oracle優(yōu)化原那么：盡量減少等待時(shí)間Wait time，提高效力時(shí)間Service time。這也是基于Oracle等待事件的分析方法的根本原那么：盡量消除各種等待事件對(duì)系統(tǒng)的影響，從而提高系統(tǒng)性能和呼應(yīng)時(shí)間。假設(shè)數(shù)據(jù)庫(kù)系統(tǒng)除了CPU和IO以外的等待時(shí)間超越DB time的5%以上的話，能夠存在某些性能問(wèn)題，需求DBA采用等待事件的分析方法，對(duì)系統(tǒng)或運(yùn)用進(jìn)展優(yōu)化。EOF后記：為什么要寫(xiě)這么一個(gè)主題，由于最近和一位同事討論機(jī)器自動(dòng)審核SQL的問(wèn)題，就想建立一個(gè)簡(jiǎn)單的模型，用來(lái)開(kāi)發(fā)一個(gè)SQL審核工具，開(kāi)發(fā)人員經(jīng)過(guò)工具和預(yù)先建立好的模型，就可以確定這個(gè)SQL能否存在性能風(fēng)險(xiǎn)。之前我們?cè)谧鯯QL優(yōu)化的時(shí)候，只是關(guān)注這個(gè)SQL本身能否優(yōu)化，邏輯讀是多少。但是，很少有人把邏輯讀和呼應(yīng)時(shí)間之間的關(guān)系建立起來(lái)，我試圖想回答這個(gè)問(wèn)題。關(guān)于容量規(guī)劃和風(fēng)險(xiǎn)預(yù)測(cè)其實(shí)是一個(gè)很有意義的命題，但是我們很多時(shí)候都局限在一些詳細(xì)的技術(shù)細(xì)節(jié)中，而忽略了對(duì)整個(gè)系統(tǒng)容量的把握，現(xiàn)實(shí)上，這也是非常難的一件事。也許到目前為