基本概念

性能問題

什么是性能問題？當(dāng)系統(tǒng)出現(xiàn)性能問題，那么反過來問為什么說出現(xiàn)了性能問題，或者說到底怎么樣算性能問題呢？

• CPU100%,CPU占有率過高？CPU就算是100%,但是客戶端反饋超快，算不算性能問題呢？
• 剩余內(nèi)存過低？操作系統(tǒng)剩余內(nèi)存過低有可能是SQL吃完了，所以不一定。那如何知道SQL使用的內(nèi)存情況呢？
• 查詢慢？查詢慢，是否就是性能問題？如果一段存儲過程寫了500行，里面關(guān)聯(lián)幾十個表，有復(fù)雜的邏輯運(yùn)算，執(zhí)行一次超過3000ms,這是慢還是快呢？所以所謂的查詢慢，也要有評估機(jī)制。
• 查詢鏈接超時?查詢超時，鏈接超時就更復(fù)雜了，有n多因素影響。
• …………

還有很多情況，客戶都說性能問題。所以到底什么算性能問題呢？我個人認(rèn)為是：

分為2種情況，第一是新系統(tǒng)運(yùn)行與經(jīng)驗系統(tǒng)相差巨大，性能測試和壓力測試不符合預(yù)期。第二種是正常運(yùn)行系統(tǒng)發(fā)生與通常情況反映不一致狀態(tài)，導(dǎo)致業(yè)務(wù)運(yùn)行困難。

通常性能下降是我們說的性能問題，但是：

還有性能突然提升，比如平常打開頁面3秒鐘，突然什么都沒有做變成了0.5秒。算不算性能問題呢？我認(rèn)為也算性能問題，世界上絕對沒有無緣無故的愛，也沒有無緣無故的恨。所以突然的提升一定隱藏著更為重要的問題！

那么既然有了概念，有哪些關(guān)鍵指標(biāo)來評估數(shù)據(jù)性能問題呢？有了指標(biāo)，我們就需要收集指標(biāo)，所以有昨天的文章。

衡量性能問題的關(guān)鍵指標(biāo)

響應(yīng)時間（Response Time）

響應(yīng)時間一般指的是一條SQL 語句執(zhí)行后得出結(jié)果耗費(fèi)的時間。
而一般用戶使用來說，比如BS結(jié)構(gòu)，響應(yīng)時間大家一般會認(rèn)為是訪問頁面到頁面呈現(xiàn)結(jié)束，這樣的感官時間。這個時間就需要考慮更多的因素。比如網(wǎng)絡(luò)、瀏覽器等等。曾經(jīng)我碰到的CASE 頁面打開速度超慢，但是數(shù)據(jù)庫正常，后來分析發(fā)現(xiàn)是頁面中潛入的一個很小的GIF影響了。所以要系統(tǒng)來分析。
而執(zhí)行SQL語句獲得的響應(yīng)時間是最為純粹的反饋，也是能夠得到準(zhǔn)備信息的步驟。
在系統(tǒng)跟蹤的話，可以用SQL profile 來跟蹤響應(yīng)的內(nèi)容，分析語句的反饋時間，之后再來詳細(xì)講解。

吞吐量（Thougput）

吞吐量是反映系統(tǒng)到底有多繁忙的指標(biāo)，了解此指標(biāo)可以更為清晰的知曉系統(tǒng)的使用狀況。
性能監(jiān)視器中可以用SQL Batch Request/Sec，SQL Transactions /Sec等指標(biāo)來獲取。

基線 （BaseLine）

BaseLine一直是我強(qiáng)調(diào)的指標(biāo)。
基線是反映系統(tǒng)日常狀況的指標(biāo)，如果知曉了系統(tǒng)的各種基線值。那么就清楚了底在哪里，天在哪里。這樣才能更容易去判斷和解決問題。 而基線值是靠長期經(jīng)驗和數(shù)據(jù)獲取的。

瓶頸（bottleneck）

系統(tǒng)一旦產(chǎn)生了瓶頸，我們就要去判斷瓶頸，而瓶頸一般來說多會有關(guān)聯(lián)性。比如內(nèi)存不足可能導(dǎo)致IO過高，IO過高也可能導(dǎo)致CPU等待。
所以準(zhǔn)確的知道瓶頸在哪里，這是需要去判斷的。使用性能監(jiān)視器和分析功能可以快捷的幫助大家分析瓶頸。

調(diào)優(yōu)本質(zhì)

調(diào)優(yōu)的本質(zhì)來講，一般的調(diào)優(yōu)都指的是性能出現(xiàn)過高，需要系統(tǒng)穩(wěn)定的情況。所以本質(zhì)來講是干以下事情：

降低工作負(fù)載

• 減少查詢請求的數(shù)量：去除不必要的數(shù)據(jù)庫訪問
• 降低查詢請求的復(fù)雜度：優(yōu)化查詢邏輯的設(shè)計
• 減少查詢請求之間的依賴關(guān)系：優(yōu)化事務(wù)的設(shè)計和并發(fā)性控制

優(yōu)化系統(tǒng)資源的配置

• 找出系統(tǒng)資源瓶頸，增加相應(yīng)的資源
• 優(yōu)化系統(tǒng)資源的分配

性能優(yōu)化的方法學(xué)

如下圖，性能優(yōu)化涉及的層面有：

• 構(gòu)架設(shè)計
• 查詢優(yōu)化
• 索引優(yōu)化
• 并發(fā)控制
• 存儲優(yōu)化
• 服務(wù)器優(yōu)化
  相關(guān)優(yōu)化的成效和收益還要順序，可見下圖：

優(yōu)化的平衡

• 優(yōu)化是一個持續(xù)的過程，永無止境，解決了當(dāng)前“最大”的瓶頸后，下一個“最大”的瓶頸又會出現(xiàn)
  要知道何時停止優(yōu)化
• 優(yōu)化的內(nèi)容應(yīng)該是基于業(yè)務(wù)需求的優(yōu)化
• 關(guān)注二投資回報率(ROI) ，工程師的時間也是投入，因此要懂得投資回報，需要懂得停止優(yōu)化！
• 改變選項是最有意義的優(yōu)化策略，有的優(yōu)化是業(yè)務(wù)決定，那么無法改變的時候是否可以改變業(yè)務(wù)邏輯。
• 實際上，足夠好的性能就足夠了。很多時候足夠即可，而不是去尋找極限！

調(diào)優(yōu)思路

調(diào)優(yōu)思路來說，從理論上，在數(shù)據(jù)庫構(gòu)架時候就應(yīng)該介入。但是通常我們遇到的情況都是半路出來。發(fā)生問題才找到DBA。所以遵循的思路可以是如下：

理解瓶頸，知道發(fā)生了什么，然后做優(yōu)化配置，調(diào)整執(zhí)行慢的語句。
然后再反復(fù)，反復(fù)。

總結(jié)

調(diào)優(yōu)是個體系工程，要有敏銳的觸覺，有也許一條參數(shù)改動全部體系感觸。所以深化了解原理和辦法，才干稱心如意。 詳細(xì)的辦法，東西等敬請期待新的Blog。