性能調整概述

為什么要進行性能調優呢？因為我們的應用系統在運行一段時間后，用戶報告系統運行會變慢，使他們不能完成所有的工作，完成事務和處理查詢花費了過長的時間，或者應用程序在一天中的某些時段變慢。要確定造成問題的本質原因，必須評估系統資源的實際使用情況并進一步地分析資源使用的瓶頸所在。
用戶通常報告以下性能問題：
●?事務或查詢的響應時間比預期的長
●?事務吞吐量不足以完成必需的工作負載
●?事務吞吐量減少
為了維持數據庫應用程序的最優性能，應該制定一個計劃用于評估系統性能，以便在性能出現問題的時候，該計劃可以根據性能問題的情況對數據庫做出調整，以維持良好的性能。定期的、特定的評估能夠幫助您預見并糾正性能問題。通過盡早識別出問題，可以有效地防止這些問題嚴重地影響用戶。
本章我們將通過一個實際生產中的客戶案例，展開對性能調整的講解。本章主要內容包括：
●?性能概述
●?性能目標
●?性能評估
●?性能模型
●?什么時候需要性能調整
●?性能調整準則
●?性能調整的方法和過程
●?保持良好性能
1.1? 性能概述
首先讓我們以一個真實的某移動公司應用案例來展開性能調整的話題，圖1-1和圖1-2分別為該移動公司營賬應用系統的邏輯架構部署圖和物理架構部署圖。
?

圖1-2中的某移動公司營賬系統是一個大型的復雜系統。在這個系統中，從上至下包括以下幾個層次：應用程序、中間件應用服務器、數據庫、主機系統(操作系統)、光纖交換機和SAN存儲網絡(IBM ESS)。在系統發生性能問題時，性能問題的定位和調優很復雜。
?

該移動公司營賬應用系統的信息架構如下：
●?存儲：采用的是IBM ESS 800存儲系統
●?操作系統：IBM AIX 5.3(p 690)
●?數據庫：IBM DB2 V8.2.1
●?中間件：IBM WebSphere 5.1
●?Web服務器：IBM Http Sever
●?應用：采用基于J2EE的Java應用
該移動公司計費業務中心營賬系統從年初開始陸續上線，營賬系統在上線運行一段時間后出現性能問題。主要表現在對最終用戶的交互響應速度不如預期，尤其在業務繁忙時更是無法得到及時的交互響應。從主機系統上觀察，主要表現在系統的I/O等待時間較長。營賬系統是由業務應用程序、DB2數據庫、AIX主機、ESS存儲多個部分組成，因此性能瓶頸的定位和性能的優化都比較復雜。
那么我們如何來解決這些性能問題呢？有兩種方法：
●?第一種方法是我們可以通過擴容硬件物理資源(增加CPU、內存以及購買更快的存儲系統)來實現。
●?第二種方法是我們試圖對應用系統作出相應的調整來優化系統以改善目前的情況。
第一種方法我們需要投入更多的經濟成本，而第二種方法需要我們利用經驗來對整個系統作出調整。本書中我要介紹的是第二種方法。
在進行調整之前，您有必要先了解關于性能調優方面的某些話題。
首先，性能的概念是什么呢？性能是業務應用系統(例如我們本章所舉的移動公司營賬系統案例)在特定硬件資源(例如32路CPU、128GB內存)和工作負載下所表現出來的處理能力。性能主要通過系統響應時間、吞吐量和可用性來衡量。
性能受以下因素影響：
●?系統中可用的物理資源
●?如何充分合理地利用這些資源
一般情況下，通過性能調整我們可以完成以下目標：
●?處理更大的或更緊迫的工作負載，而不增加處理成本，例如增加工作負載而不用購買新硬件或占用更多處理器時間
●?獲得更快的系統響應時間或更大的吞吐量，而不增加處理成本
●?降低處理成本，而不會降低對用戶的服務
1.2? 性能評估
以下評估描述了事務處理系統的性能：
●?吞吐量
●?響應時間
●?每個事務的成本
●?資源利用率
1. 吞吐量
吞吐量用于評估系統的整體性能。對于事務處理系統，吞吐量通常用每秒事務數(TPS)或每分鐘事務數(TPM)來計量。吞吐量取決于以下因素：
●?服務器硬件資源配置
●?軟件中的處理開銷
●?磁盤上數據的布局
●?硬件和軟件都支持的并行度
●?正在處理的事務類型
2. 響應時間
響應時間用于評估單個事務或查詢的性能。通常認為，響應時間是從用戶輸入一個命令或激活一個功能開始一直到應用程序指示已完成該命令或功能所消耗的時間。典型DB2應用程序的響應時間包括以下操作序列(每個操作都需要一定的時間，響應時間不包括用戶思考和輸入查詢或請求的時間)：
(1) 應用程序將查詢轉發到數據庫服務器。
(2) 數據庫服務器執行查詢最優化并檢索所有用戶定義的SQL、命令、腳本和程序。
(3) 數據庫服務器檢索、添加或更新適當的記錄并執行與查詢直接相關的磁盤I/O操作。
(4) 數據庫服務器執行在查詢或事務仍處于暫掛狀態的同期發生的所有后臺I/O操作(如日志記錄和臟頁面清除)。
(5) 數據庫服務器將結果返回給應用程序。
(6) 應用程序顯示信息或發出確認，并隨后向用戶發出新的提示。
圖1-3顯示了步驟(1)~(6)中所述的操作如何作用于整體響應時間。
?
??

3. 響應時間和吞吐量
響應時間和吞吐量是相關聯的。在您增加總體吞吐量時一般事務的響應時間會減少。但是，可以通過為特定查詢分配不成比例的資源數量，在犧牲總體吞吐量的情況下減少該查詢的響應時間。與之相反，可以通過限制數據庫分配給大型查詢的資源數來維持總體吞吐量。
當嘗試在對高事務吞吐量的當前需求和對執行大型決策支持查詢的即時需求之間取得平衡時，吞吐量與響應時間之間的平衡就變得明顯起來。應用于查詢的資源越多，可用于處理事務的資源就越少，并且查詢對事務吞吐量的影響就越大。相反，提供給查詢的資源越少，查詢花費的時間就越長。
4. 每個事務的成本
每個事務的成本是財務上的量度，通常用于比較應用程序、數據庫服務器或硬件平臺之同的總體操作成本。
要評估每個事務的成本，通常采用下面的方法：
(1) 計算與運行應用程序相關的所有成本，這些成本可能包括硬件和軟件的安裝成本、運作成本及其他費用。
(2) 設計應用程序有效期的事務和查詢的總數。
(3) 用總成本除以事務總數。
盡管該測量對于進行規劃和評估很有用，但是它與達到最佳性能的運行問題幾乎無關。
5. 資源利用率和性能
典型的事務處理應用程序在其各個運行周期中需要滿足的要求各不相同。一天、一周、一月、一年中的峰值負載以及決策支持(DSS)查詢或備份操作所施加的負載對于任何容量將用盡的系統都會產生明顯的影響。可以使用從特定系統派生的直接歷史數據精確地測定這種影響。
必須對系統的工作負載和性能進行定期評估，以預測峰值負載并比較使用周期中不同時刻的性能評估。定期評估有助于為數據庫服務器上的應用程序開發總體的性能概要文件，該概要文件對于確定如何可靠地提高性能具有關鍵意義。
關于操作系統提供的用于評估對系統和硬件資源的性能影響的工具，請參閱本書第2章“操作系統及存儲的性能調優”。
資源利用率是與系統資源可用的總時間相比，該系統資源實際被占用的時間的百分比。例如，如果CPU在一分鐘內總共用42秒處理事務，那么在這段時間間隔內的利用率就是70％。
定期評估并記錄以下系統資源的利用率：
●?CPU
●?內存
●?磁盤
●?網絡
當某項資源被過度使用或者它的利用率與其他系統資源的利用率不成比例時，就稱該資源對于性能是臨界的。例如，當一個磁盤的利用率達到70％，而系統中其他所有磁盤的利用率只有30％的時候，可以認為該磁盤是臨界的或是被過度使用。盡管70％并不表示磁盤被嚴重過度使用，但可以通過重新安排數據來平衡整個磁盤集上的I/O請求，從而提高系統的性能。
如何評估資源利用率取決于操作系統為報告系統活動和資源利用率所提供的工具。一旦發現看起來被過度使用的資源，就可以使用數據庫服務器的性能監視實用程序來收集數據，并對可能占用該系統資源上負載的數據庫活動進行干涉。可以調整數據庫的配置參數或操作系統的相關I/O配置，以減少那些數據庫活動或將它們分散到其他資源中(關于這部分的詳細內容請參見本書第2章)。

?

循序漸進DB2 (第2版)——DBA系統管理、運維與應用案例