如何規劃和選擇資料庫伺服器：CPU、記憶體、磁碟、網路

標籤：pmc   各類   http   其他   必須   單位   產生   網上銀行   冗餘   

轉自：http://blog.chinaunix.net/uid-5715-id-2734517.html

 

學習如何根據業務模型來計算tpcc值，挺有協助的。

 

當一個新的業務系統開發完成後，需要在一個地區乃至全國推廣此應用軟體，如何根據業務規模來選擇伺服器配置、內外置磁碟大小、以及網路頻寬，是一件複雜的事情。

一個最真實的評估，是建立一個接近真實業務應用的作業環境，進行各種壓力測試，測算出不同的使用者數量下，系統的回應時間和輸送量，並得出當時伺服器的各種資源的利用率情況，對硬體資源的完整評估，需要考慮下列三個方面：

•   伺服器效能的評估 

•   用戶端工作站或前端案頭的評估 

•   通訊網卡和網路頻寬的評估 

如果不能建立準確的壓力測試環境，需要根據工業界的Benchmark對伺服器進行評估，推算出符合業務規模的伺服器配置,同時要考慮在做系統管理時所消耗的資源，如在做備份、恢複、問題診斷、效能分析時、軟體維護時都會對資源帶來附加的消耗，對重要資源要考慮為將來留下升級和可擴充的餘地，下列是一些通用的原則：

•   處理器：要考慮高峰時的處理器的能力，並適當保留一些緩衝，確保在業務增長時，系統有擴充的餘地。如果要保持快速的響應能力，應當為CPU保留20%至40%的富餘量。 

•   記憶體：要為運行在此伺服器的所有應用軟體考慮記憶體，所需要的記憶體主要依賴於使用者數、應用程式類型、進程的方式、和應用程式處理的資料量決定。 

•   磁碟：評估業務的實際使用者的資料量，以此推算出磁碟的最小個數，不要忘記選擇備份裝置（如磁帶機）。 

•   IO槽：盡量保留更多的IO槽，防止將來插更多的PCI卡。 

•   網路：選擇合適的網卡，保證網路不是系統的瓶頸。 

在評估資料庫伺服器效能時，最困難的事情是如何把握準確度問題，到底考慮哪些因素等。理想情況下，應考慮下列要素：

•   交易的複雜性 

•   交易率 

•   資料讀/寫比例 

•   並發串連數目 

•   並發交易數目 

•   資料庫最大表的大小 

•   效能度量的目標 

    根據各種Benchmark測試結果和對各種生產系統的檢測，下表概括了CPU、磁碟、記憶體頁面、網路和虛存頁交換的利用率，可看出一個伺服器如果其利用率保持在Good 所標示的範圍內時，是一種理想的模式。

2、         基於rPerf的推算，評估資料庫伺服器的CPU

rPerf(Relative performance)是從IBM公司解析模型得出的商務處理效能估計值。該模型類比部分系統的操作，如中央處理器、快取和記憶體，該模型沒有類比磁碟和網路的輸入/輸出操作。雖然採用了一般資料庫和作業系統的參數，但該模型不能反映出具體的資料庫或AIX版本。除非單獨說明，否則rPerf均在系統推出時估計。IBM pSeries 640-B80為基準參照系統，其值為本。雖然rPerf可用於比較商業處理效能，但實際的系統效能可能不同，取決於許多因素，包括系統硬體設定和軟體設計與配置。

評估資料庫伺服器的效能，需要理解交易的類型、高峰期的情況、使用者數量、在高峰時每個使用者的交易數量。假如在高峰時，有三種典型的交易類型：輕的、一般的、重的。需要知道高峰時，每種交易的並發使用者數目。假定高峰時間為：10:00-11:00，每個使用者的交易數目如下：

輕的交易  =120 交易/使用者

一般的交易= 60 交易/使用者

重的交易 = 15交易/使用者

2.1、每個證券交易所使用的CPU秒

評估出交易類型後，需要評估出運行每個證券交易所消耗的CPU秒，如果假定B80伺服器每秒中支援10個交易，則每個交易需要消耗0.1個CPU秒。如果不知道如何評定CPU秒，則根據應用類型參照下列表。

2.2、評估伺服器所需的rPerf值

伺服器所需要的rPerf值=SUM(NU * TX * CS/PP) / MC

NU:高峰時並發的使用者數

TX:高峰時每個使用者的交易數量

CS:在rPerf=1的伺服器上，每個證券交易所需要的CPU秒

PP:高峰持續的時間

MC:最大的CPU利用率（推薦< 70%）

下面舉例說明如何計算所需的rPerf值，假定某公司的情況如下：

業務高峰時間：  10:00-11:00=1Hour=3600秒

交易類型：      無複雜查詢的簡單應用

相對交易類型，使用者數目分布:輕的=2000,   一般=50,   重的=5

在高峰時，每個使用者的交易數量：

   輕的=120交易/使用者

   一般=60交易/使用者

   重的=15交易/使用者

對於rPerf=1的伺服器，每個交易響應的CPU秒

   輕的=1

   一般=3

   重的=15

最大的CPU利用率：60%

根據上述公式，可推算出不同交易類型所對應的rPerf值。

輕的交易：NU*TX*CS/PP=2000*120*1/3600=66.0

一般交易：NU*TX*CS/PP=50*60*3/3600=2.5

重的交易：NU*TX*CS/PP=5*15*15/3600=0.3

所需的總的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf

3、基於TPC-C的推算，評估資料庫伺服器的CPU

TPC-C基準是交易處理委員會建立的一個專門示範線上交易處理效能（OLTP）的效能基準，它的測量方法是為了使客戶能夠評估不同的線上交易處理系統的效能，這些事務進程於一個可控制的狀態下在一個標準的資料庫中運行。

TPC-C測試包括5個典型的OLTP事務，它們是：

新訂單　：一個使用者提交一個新的訂單

支付　　：更新使用者的賬戶餘額以反映一個支付

交付　　：訂單的交付（通過一個批交易處理實現）

訂單狀態：返回使用者最新訂單的狀態

庫存水平：監控當前倉庫庫存

TPC-C的交易處理是在一個９個表的資料庫上實現的交易處理過程包括：更新、插入、刪除、終止，以及對主和次級鍵的訪問,每種交易處理９０％的回應時間應小於或等於５秒，其中，庫存水平的回應時間可以在２０秒以內。

TPC-C的輸送量值是終端活動水平的直接結果，如每一個倉庫有10個終端，在每一個終端上上述5個事務都是可用的，一個遠端終端模擬器被用來在效能測試過程中進行必要的事務混合工作。這個混合代表著一個完整的訂單商務處理流程：錄入、支付、檢驗、交付。更專業的是，這個必要的混合被定義為產生一個相等數量的新訂單和支付事務，以及在每10個新訂單事務中產生一個交付事務，一個訂單狀態檢驗事務和一個庫存水平檢驗事務

遠程終端模擬器也被用來測量每一個事務的回應時間，以及用來類比鍵入時間及考慮時間，鍵入時間是指在終端上錄入資料所花費的時間，考慮時間是指操作人員在終端讀取事務的結果，進行下一個事務請求之前所花費的時間。每一個事物都有一個最小鍵入時間和最小考慮時間。另外，這個回應時間必須在一個給定的極限值之下。

TPC-C基準測試的結果--TPC-C的輸送量（tpmC），代表的是系統的最大的持久性能，它被定義為系統每分鐘可以處理多少個新訂單事務，與此同時，系統還在處理其他四種事務類型（支付、訂單狀態、交付、庫存水平）。所有５個TPC-C事務都有某個限定的使用者回應時間要求，其中新訂單事務的回應時間是５秒以內。因此如果一個系統的TPC-C值是100tpmC/min，說明該系統在每分鐘處理其他的混合的TPC-C事務的工作的同時，可以產生１００個新訂單事務。

3.1、如何使用TPC-C進行伺服器的評估

由上可知，TPC-C測試基準主要用於測試主機伺服器每分鐘能夠處理的聯機交易筆數，測試產生的單位結果是TPM值（Transaction Per Minute，即每分鐘處理的交易比數）。

TPC-C雖然客觀的反映了各個電腦廠商的系統處理效能，並且測試基準也在不斷完善以更加貼近現實應用的交易環境，但是仍然無法與紛繁多樣的各類實際應用完全吻合；而且參加TPC測試的主機系統都做了適當程度的系統最佳化。因此，在實際業務應用系統選擇主機伺服器乘載體時，必須考慮到多方面的因素，以最大程度的做到適合應用系統的生產需求。

以下計算公式是IBM公司在金融綜合業務系統的實際應用中總結的經驗方法論，基本反映了金融業務特點對主機處理能力的需求：

TPM=TASK x 80% x S x F / (T x C)

其中：

TASK：為每日業務統計峰值交易量

T：為每日峰值交易時間，假設每日80%交易量集中在每天的4小時，即240分鐘內完成：T=240。

S：為實際銀行業務交易操作相對於標準TPC-C測試基準環境交易的複雜程度比例。由於實際的金融業務交易的複雜程度與TPC?C標準測試中的交易存在較大的差異，須設定一個合理的對應值。以普通儲蓄業務交易為例，一筆交易往往需要同時開啟大量資料庫表，取出其相關資料進行操作，相對於TPC-C標準交易的複雜度，要複雜很多；根據科學的統計結果，每筆交易操作相比較於TPC標準測試中的每筆交易的複雜度此值可設定為10~20。

C：為主機CPU處理餘量。實際應用經驗表明，一台主機伺服器的CPU利用率高於80%則表明CPU的利用率過高會產生系統瓶頸，而利用率處於75%時，是處於利用率最佳狀態。因此，在推算主機效能指標時，必須考慮CPU的冗餘，設定C=75%。

F：為系統未來3~5年的業務量發展冗餘預留。

綜上所述，為保障聯機業務處理效能要求，我們可推算得出主機所需的處理能力，據此得出相應的機型和配置。

4、舉例說明，使用TPC-C進行資料庫伺服器評估

  下面針對XYZ行的網上銀行業務的需求，我們進行資料庫伺服器的選型分析。

由於目前XYZ行只有17個分行開通了網上銀行業務，據我們估計，按照目前的客戶數量，全部分行都開通網上銀行業務後，總的客戶數量可以達到10萬。考慮INTERNET在我國的迅猛發展，客戶數量的年增長率按照50%計算，那麼，3年後的客戶數量將達到10萬×（1+50%）3≈34萬。

  這些客戶當中，至少有一半是個人客戶，另一半是企業客戶。企業客戶的交易頻率比較高，我們按平均每個企業客戶每天做1.5筆交易計算；個人客戶常用的交易是查詢、取款、存款，並且每個月還要交電話費，因此我們假定個人客戶平均每個月做4次交易；那麼，每天的交易量就是：

  34萬×50%×1.5+34萬×50%×(4÷30) ≈28萬筆

  假設網上銀行的交易複雜度達到15，那麼，每天的資料庫運算元達到：

  28萬×15=420萬次

高法訴訟費繳費：

  由於訴訟費的增長量不大，我們按年遞增率5%計算。根據XYZ總行的統計，全國共37家分行，繳費量比較大的分行可以達到25000筆每月，佔分行總數的20%；繳費量中等的省可達到15000筆每月，佔分行總數的30%；繳費量小的省可達到7000筆每月，佔分行總數的50%；按一個月20個工作日計算。這樣，三年後每天的交易數量可以達到：

  （25000×20%+15000×30%+7000×50%）×37÷20×（1+5%）3≈28740筆

  我們假設高法訴訟繳費的交易複雜度達到13，那麼每天的資料庫操作達到：

  28740*13=373620次

4.1、整體效能要求：

  總的資料庫操作次數是：4200000+373620=4573620

  假設每天的交易的80%集中在4小時內發生，那麼高峰交易時間內每分鐘的資料庫聯機交易次數為：4573620×80%÷（4×60）≈15250

要為將來陸續加入的應用預留40%的處理能力；另外，考慮到CPU的繁忙時間低於70%時，系統的效能較好，我們把這個比例定在65%。所以系統的TPC-C值應達到：15250÷（1－40%）÷65%≈39000

4.2、記憶體容量需求分析

首先根據資料庫容量算出所需的資料庫緩衝大小，再估計出作業系統、系統軟體等所需記憶體，合計即是所需的記憶體容量。

網銀資料量分析：

  XYZ總行網上銀行系統的資料庫由CIF資訊，交易日誌、交易流水三部分組成。

  其中：CIF資訊包括企業客戶和個人客戶資訊，企業客戶資訊平均大小為20K左右，個人客戶資訊平均大小為5K左右；每一筆交易都要記交易日誌，日誌的平均大小為4K左右；每一筆轉帳交易都要記交易流水，交易流水的大小為2K左右。

  這些客戶當中，至少有一半是個人客戶，另一半是企業客戶。企業客戶的交易頻率比較高，我們按平均每個企業客戶每天做1.5筆交易計算；個人客戶常用的交易是查詢、取款、存款，並且每個月還要交電話費，因此我們假定個人客戶平均每個月做4次交易；那麼，每天的交易量就是：

  所有的交易日誌和交易流水都要保留三個月。由於個人客戶的轉帳交易非常少，可以忽略不計；假定企業客戶的轉帳交易佔總交易量的70%。我們就可以計算網上銀行對儲存系統容量的要求：

CIF資訊容量=20K×（34萬×50%）+5K×（34萬×50%）=3.25GB+421MB ≈ 4GB

  交易日誌容量=[34萬×50%×1.5+34萬×50%×(4÷30)] ×4K×30×3  =277667×4K×30×3  ≈95GB

  交易流水容量=（34萬×50%×1.5）×70%×2K×30×3  ≈30GB

XYZ網上銀行總體資料容量要求：=4GB+95GB+30GB=129GB

高法訴訟費資料量分析：

  高法的交易資料按要求要保留三年，每筆交易記錄的大小為512位元組，總體容量為：（25000×20%+15000×30%+7000×50%）×37×12×3×0.5K≈8.2GB

因此，資料庫的總資料量為： 129GB+8.2GB=137.2GB

  資料庫系統在緩衝容量達到資料庫總容量的5%時效能較好，因此，資料庫緩衝大小為：6.86GB。

從而計算出系統記憶體需求為：

 

1.	AIX作業系統所佔的記憶體	128MB
2.	資料庫管理系統所佔的記憶體	256MB
3.	雙機熱備等系統軟體所佔的記憶體	128MB
4.	應用程式所佔的記憶體	256MB
5.	資料庫緩衝	6.86GB
6.	合理的記憶體利用率	75%
	總計	10GB

 

4.3、  儲存容量需求分析

  除了上述的XYZ網上銀行系統和高法訴訟費繳費系統的儲存容量要求之外，還有非同步查詢下載服務的儲存要求。

  非同步查詢下載服務每隔1小時產生一個下載資料包，每個資料包的大小為3MB，需要下載的資料包是上午十點產生的資料包，這個資料包需要儲存2年，其它資料包只要儲存3個月。因此，儲存容量為：

  23×3M×30×3＋1×3M×365*2=6GB+2GB=8GB

  為避免儲存系統成為系統效能的瓶頸，系統儲存系統的使用率應小於40%，建議採用鏡像方式儲存資料，因此總的儲存容量為：

  (137.2GB+8GB)÷40% ×2= 766GB

如何規劃和選擇資料庫伺服器：CPU、記憶體、磁碟、網路（轉）