DBA實驗室：Oracle性能預測的重要性
2024-08-29 13:39:20
供稿：網友
基本上來說，猜測Oracle的性能對每一個數據庫治理員的理解和工作都具有絕對的重要性。當性能開始下降的時候，是數據庫治理員對其進行審查，是數據庫治理員來進行修復。 是數據庫治理員最熟悉數據庫服務器的知識，所以他們難道不能對性能進行猜測嗎?當系統要添加一些新的用戶的時候，最快詢問的就是數據庫治理員，“這不會出現問題，是嗎?”因此，數據庫治理員需要有快速猜測性能的能力。不甚精確的猜測可以飛快的完成，這是開始猜測Oracle性能的一個很好的方式。
我們想要猜測的一個要害點就是利用率、隊列長度，以及響應時間。僅僅通過上述的三個因素，作為數據庫治理員，你可以執行各種類型的較低精度的what-if 場景。要得到價值，你基本上需要一下的三項內容:
一些簡單的公式
一些基本的操作系統統計數字
一些基本的Oracle統計數字
在你開始利用這些公式之前，理解一些概念并熟悉它們的標記是很重要的。
S:為一個工作單元服務的時間。它通常是服務時間或者服務需求。是CPU為一個單獨的事務服務的時間長度。例如，每個事務1.5秒，或者是1.5 sec/trx 。獲得Oracle系統的這個數值的最好方式就是計算。
U:利用率或者CPU繁忙度。一般來說，這個數是一個百分數，也是它在這個公式中的出現方式。例如，在公式中，它應該是類似75% 或者 0.75這樣的數字，而不是75。收集CPU利用率的一個簡單方式就是運行sar –u 60 1。這將給你在過去的60秒中CPU的平均利用率。
λ:工作到達率。這是每個單元時間內進入系統的事務的數量(例如，每秒150個事務，或者150 trx/sec)。當使用Oracle工作的時候，有許多可能的統計數字可以用來計算“事務”到達率。使用v$sysstat 收集到的一般的統計數字是針對邏輯讀取、塊交換、物理寫入、用戶調用、登錄、執行、用戶提交，以及用戶回滾。你還可以根據你的經驗將上述操作進行混和和匹配。在這篇文章里，我們將會簡單使用地使用用戶調用。
Q:隊列長度。這是正在等待服務的事務的數量。其中排除了當前正在被服務的事務的數量。我們將會導出這個數值。
M:CPU的數量。你可以從cpu_count 這個環境參數中得到數值。
計算平均數的CPU公式，如下所示:
U = ( S λ ) / M (1)
R = S / (1-U) (2)
Q = R λ – M (3)
在我們采用現實生活中的例子之前，讓我們先通過以下的理論實驗來檢查一下公式。
理論實驗1:使用公式(1)，假如1CPU的利用率是50%，那么用2個CPU就是25%。公式的結果也是如此。因為你已經計算出來了，可測量性就不再予以考慮。
理論實驗2:使用公式(1)，假如我們增加到達率，CPU的利用率也應該上升。
理論實驗3:使用公式(1)，假如我們使用更快的CPU，那么服務時間應該減少，那么利用率應該下降。
理論實驗4:使用公式(2)，假如利用率上升，分母就下降，應該導致響應時間增加。
理論實驗5:使用公式(3)，假如CPU的數量增加，那么隊列長度就應該減少。
理論實驗6:使用公式(3)，假如到達率上升，隊列長度就應該上升。
現在，你可以對公式有些感覺，并認為它是爭取的了吧，下面讓我們看看實際的例子。
例子1:讓我們說一下在過去的60秒中，你在單CPU的linux機器上收集到的CPU平均利用率和用戶調用的數量。你發現平均利用率是65%，Oracle處理了750個用戶調用。每秒鐘用戶調用的數量就是12.5(即，750/60 = 12.5)。
因此
S = 0.052 sec/call ; U = ( S λ ) / M ; 0.65 = ( S * 12.500 ) / 1
R = 0.149 sec/call ; R = S / (1-U) ; R = 0.052 / ( 1 – 0.65 )
Q = 0.863 calls ; Q = R λ – M ; Q = ( 0.149 sec/call * 12.5 calls/sec ) – 1
我們能夠立即用到的惟一一個數字就是隊列長度。平均來說，大概有一個等待CPU周期的進程。這對于性能和用戶來說是不好的。假如用戶對性能不滿足的話也沒什么驚奇的。假如他們認為性能還不錯，那么現在就開始為未來做一個計劃是一個不錯的主意。
當我們使用不同的配置或者工作場景來重新計算響應時間和服務時間會更有用。例如，我們考慮一下當你的工作量每15分鐘會增加20%的情況。當響應時間明顯增加的時候，會經過多少個15分鐘?第二個例子中，我們將會看到這個效果。
例子2:我們假設目前的性能是可以接受的，但是數據庫治理員不知道這種情況將持續多久。假設工作量每15分鐘都會增加20%，使用上面描述的情景作為我們的基本線，并使用上面的三個基本公式，下面是每15分鐘的情況。
我們可以立即看到在第三個15分鐘，利用率超過了100%(即，104%)。
這導致餓了不穩定的系統，因為隊列一直在增加。響應時間和隊列長度計算也都會受到負面影響，顯示了現在的系統很不穩定。
我們回答下面這個問題，“系統什么時候會崩潰?”，答案類似“在第二個和第三個15分鐘之間的某個時間?！比欢?，這是個非常明顯并且非常樂觀的具有高風險的答案。下面讓我們挖掘得更深一些。
當利用率達到100%之前性能下降就發生了，正如響應時間和隊列長度的變化顯示的。所以，當系統在第二個15分鐘中陷入技術性活動的時候，響應時間已經顯著增加了，并且用戶毫無疑問會感到不興奮。基于以上的情況，假如用戶對當前的性能表示滿足的話，那么他們很有可能不會在下一刻仍然感到滿足。響應時間差不多增加一倍，隊列長度也會達到災難性的2.55!
那么選項是什么?在這一點上，有許多的選項，但是我們在另一篇文章中討論這些問題。
在猜測之前清楚地理解精確需求和可獲得的準確度是重要的。使用上面描述的方法來獲得的準確度是非常低的。這是因為以下幾個原因，其中的幾個愿意就是:只收集了一個數據樣本，猜測是無效的，工作量沒有仔細地描述，并且我們的模型只考慮了CPU子系統。當需要做出更加精確的猜測的時候，可以用到HoriZone 這樣的產品。但是許多時候，一個快速但是準確度較低的猜測是必需的。在這種情況下，你可以使用上面列出的公式對當前環境有一個大概的概念。
正如你看到的，僅僅利用上面幾個基本公式和一些性能數據，可以做出有用的猜測結果結果。性能猜測將會是擴展到數據庫治理員的專業領域的猜測領域，可以用往返答那些我們在星期五下午的4點半被問到的刁鉆的問題，還可以幫助預見到糟糕的性能。
