如何規(guī)劃和選擇數(shù)據(jù)庫服務(wù)器?
一個最真實的評估，是建立一個接近真實業(yè)務(wù)應(yīng)用的操作環(huán)境，進(jìn)行各種壓力測試，測算出不同的用戶數(shù)量下，系統(tǒng)的響應(yīng)時間和吞吐量，并得出當(dāng)時服務(wù)器的各種資源的利用率情況，對硬件資源的完整評估，需要考慮下列三個方面:
服務(wù)器性能的評估
客戶端工作站或前端桌面的評估
通訊網(wǎng)卡和網(wǎng)絡(luò)帶寬的評估
如果不能建立準(zhǔn)確的壓力測試環(huán)境，需要根據(jù)工業(yè)界的Benchmark對服務(wù)器進(jìn)行評估，推算出符合業(yè)務(wù)規(guī)模的服務(wù)器配置,同時要考慮在做系統(tǒng)管理時所消耗的資源，如在做備份、恢復(fù)、問題診斷、性能分析時、軟件維護時都會對資源帶來附加的消耗，對重要資源要考慮為將來留下升級和可擴展的余地，下列是一些通用的原則:
處理器:要考慮高峰時的處理器的能力，并適當(dāng)保留一些緩沖，確保在業(yè)務(wù)增長時，系統(tǒng)有擴展的余地。如果要保持快速的響應(yīng)能力，應(yīng)當(dāng)為CPU保留20%至40%的富余量。
內(nèi)存:要為運行在此服務(wù)器的所有應(yīng)用軟件考慮內(nèi)存，所需要的內(nèi)存主要依賴于用戶數(shù)、應(yīng)用程序類型、進(jìn)程的方式、和應(yīng)用程序處理的數(shù)據(jù)量決定。
磁盤:評估業(yè)務(wù)的實際用戶的數(shù)據(jù)量，以此推算出磁盤的最小個數(shù)，不要忘記選擇備份設(shè)備(如磁帶機)。
IO槽:盡量保留更多的IO槽，防止將來插更多的PCI卡。
網(wǎng)絡(luò):選擇合適的網(wǎng)卡，保證網(wǎng)絡(luò)不是系統(tǒng)的瓶頸。
在評估數(shù)據(jù)庫服務(wù)器性能時，最困難的事情是如何把握準(zhǔn)確度問題，到底考慮哪些因素等。理想情況下，應(yīng)考慮下列要素:
交易的復(fù)雜性
交易率
數(shù)據(jù)讀/寫比例
并發(fā)連接數(shù)目
并發(fā)交易數(shù)目
數(shù)據(jù)庫最大表的大小
性能度量的目標(biāo)
根據(jù)各種Benchmark測試結(jié)果和對各種生產(chǎn)系統(tǒng)的檢測，下表概括了CPU、磁盤、內(nèi)存頁面、網(wǎng)絡(luò)和虛存頁交換的利用率，可看出一個服務(wù)器如果其利用率保持在Good 所標(biāo)示的范圍內(nèi)時，是一種理想的模式。
基于rPerf的推算，評估數(shù)據(jù)庫服務(wù)器的CPU
rPerf(Relative performance)是從IBM公司解析模型得出的商務(wù)處理性能估計值。該模型模擬部分系統(tǒng)的操作，如中央處理器、高速緩存和內(nèi)存，該模型沒有模擬磁盤和網(wǎng)絡(luò)的輸入/輸出操作。雖然采用了一般數(shù)據(jù)庫和操作系統(tǒng)的參數(shù)，但該模型不能反映出具體的數(shù)據(jù)庫或AIX版本。除非單獨說明，否則rPerf均在系統(tǒng)推出時估計。IBM pSeries 640-B80為基準(zhǔn)參照系統(tǒng)，其值為本。雖然rPerf可用于比較商業(yè)處理性能，但實際的系統(tǒng)性能可能不同，取決于許多因素，包括系統(tǒng)硬件配置和軟件設(shè)計與配置。
評估數(shù)據(jù)庫服務(wù)器的性能，需要理解交易的類型、高峰期的情況、用戶數(shù)量、在高峰時每個用戶的交易數(shù)量。假如在高峰時，有三種典型的交易類型:輕的、一般的、重的。需要知道高峰時，每種交易的并發(fā)用戶數(shù)目。假定高峰時間為:10:00-11:00，每個用戶的交易數(shù)目如下:
輕的交易 =120 交易/用戶
一般的交易= 60 交易/用戶
重的交易 = 15交易/用戶
每個交易所使用的CPU秒
評估出交易類型后，需要評估出運行每個交易所消耗的CPU秒，如果假定B80服務(wù)器每秒中支持10個交易，則每個交易需要消耗0.1個CPU秒。如果不知道如何評定CPU秒，則根據(jù)應(yīng)用類型參照下列表。
基于rPerf的推算，評估數(shù)據(jù)庫服務(wù)器的CPU
rPerf(Relative performance)是從IBM公司解析模型得出的商務(wù)處理性能估計值。該模型模擬部分系統(tǒng)的操作，如中央處理器、高速緩存和內(nèi)存，該模型沒有模擬磁盤和網(wǎng)絡(luò)的輸入/輸出操作。雖然采用了一般數(shù)據(jù)庫和操作系統(tǒng)的參數(shù)，但該模型不能反映出具體的數(shù)據(jù)庫或AIX版本。除非單獨說明，否則rPerf均在系統(tǒng)推出時估計。IBM pSeries 640-B80為基準(zhǔn)參照系統(tǒng)，其值為本。雖然rPerf可用于比較商業(yè)處理性能，但實際的系統(tǒng)性能可能不同，取決于許多因素，包括系統(tǒng)硬件配置和軟件設(shè)計與配置。 #p#page_title#e#
評估數(shù)據(jù)庫服務(wù)器的性能，需要理解交易的類型、高峰期的情況、用戶數(shù)量、在高峰時每個用戶的交易數(shù)量。假如在高峰時，有三種典型的交易類型:輕的、一般的、重的。需要知道高峰時，每種交易的并發(fā)用戶數(shù)目。假定高峰時間為:10:00-11:00，每個用戶的交易數(shù)目如下:
輕的交易 =120 交易/用戶
一般的交易= 60 交易/用戶
重的交易 = 15交易/用戶
下面舉例說明如何計算所需的rPerf值，假定某公司的情況如下:
業(yè)務(wù)高峰時間: 10:00-11:00=1Hour=3600秒
交易類型: 無復(fù)雜查詢的簡單應(yīng)用
相對交易類型，用戶數(shù)目分布:輕的=2000, 一般=50, 重的=5
在高峰時，每個用戶的交易數(shù)量:
輕的=120交易/用戶
一般=60交易/用戶
重的=15交易/用戶
對于rPerf=1的服務(wù)器，每個交易響應(yīng)的CPU秒
輕的=1
一般=3
重的=15
最大的CPU利用率:60%
根據(jù)上述公式，可推算出不同交易類型所對應(yīng)的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
基于TPC-C的推算，評估數(shù)據(jù)庫服務(wù)器的CPU
TPC-C基準(zhǔn)是事務(wù)處理委員會建立的一個專門演示在線事務(wù)處理性能(OLTP)的性能基準(zhǔn)，它的測量方法是為了使客戶能夠評估不同的在線事務(wù)處理系統(tǒng)的性能，這些事務(wù)進(jìn)程于一個可控制的狀態(tài)下在一個標(biāo)準(zhǔn)的數(shù)據(jù)庫中運行。
TPC-C測試包括5個典型的OLTP事務(wù)，它們是:
新訂單 :一個用戶提交一個新的訂單
支付 :更新用戶的賬戶余額以反映一個支付
交付 :訂單的交付(通過一個批事務(wù)處理實現(xiàn))
訂單狀態(tài):返回用戶最新訂單的狀態(tài)
庫存水平:監(jiān)控當(dāng)前倉庫庫存
TPC-C的事務(wù)處理是在一個9個表的數(shù)據(jù)庫上實現(xiàn)的事務(wù)處理過程包括:更新、插入、刪除、終止，以及對主和次級鍵的訪問,每種事務(wù)處理90%的響應(yīng)時間應(yīng)小于或等于5秒，其中，庫存水平的響應(yīng)時間可以在20秒以內(nèi)。
TPC-C的吞吐量值是終端活動水平的直接結(jié)果，如每一個倉庫有10個終端，在每一個終端上上述5個事務(wù)都是可用的，一個遠(yuǎn)程的終端仿真器被用來在性能測試過程中進(jìn)行必要的事務(wù)混合工作。這個混合代表著一個完整的訂單商務(wù)處理流程:錄入、支付、檢驗、交付。更專業(yè)的是，這個必要的混合被定義為產(chǎn)生一個相等數(shù)量的新訂單和支付事務(wù)，以及在每10個新訂單事務(wù)中產(chǎn)生一個交付事務(wù)，一個訂單狀態(tài)檢驗事務(wù)和一個庫存水平檢驗事務(wù)
遠(yuǎn)程終端仿真器也被用來測量每一個事務(wù)的響應(yīng)時間，以及用來模擬鍵入時間及思考時間，鍵入時間是指在終端上錄入數(shù)據(jù)所花費的時間，思考時間是指操作人員在終端讀取事務(wù)的結(jié)果，進(jìn)行下一個事務(wù)請求之前所花費的時間。每一個事物都有一個最小鍵入時間和最小思考時間。另外，這個響應(yīng)時間必須在一個給定的極限值之下。
TPC-C基準(zhǔn)測試的結(jié)果--TPC-C的吞吐量(tpmC)，代表的是系統(tǒng)的最大的持續(xù)性能，它被定義為系統(tǒng)每分鐘可以處理多少個新訂單事務(wù)，與此同時，系統(tǒng)還在處理其他四種事務(wù)類型(支付、訂單狀態(tài)、交付、庫存水平)。所有5個TPC-C事務(wù)都有某個限定的用戶響應(yīng)時間要求，其中新訂單事務(wù)的響應(yīng)時間是5秒以內(nèi)。因此如果一個系統(tǒng)的TPC-C值是100tpmC/min，說明該系統(tǒng)在每分鐘處理其他的混合的TPC-C事務(wù)的工作的同時，可以產(chǎn)生100個新訂單事務(wù)。
如何使用TPC-C進(jìn)行服務(wù)器的評估
由上可知，TPC-C測試基準(zhǔn)主要用于測試主機服務(wù)器每分鐘能夠處理的聯(lián)機交易筆數(shù)，測試產(chǎn)生的單位結(jié)果是TPM值(Transaction Per Minute，即每分鐘處理的交易比數(shù))。
TPC-C雖然客觀的反映了各個計算機廠商的系統(tǒng)處理性能，并且測試基準(zhǔn)也在不斷完善以更加貼近現(xiàn)實應(yīng)用的交易環(huán)境，但是仍然無法與紛繁多樣的各類實際應(yīng)用完全吻合;而且參加TPC測試的主機系統(tǒng)都做了適當(dāng)程度的系統(tǒng)優(yōu)化。因此，在實際業(yè)務(wù)應(yīng)用系統(tǒng)選擇主機服務(wù)器乘載體時，必須考慮到多方面的因素，以最大程度的做到適合應(yīng)用系統(tǒng)的生產(chǎn)需求。 #p#page_title#e#
以下計算公式是IBM公司在金融綜合業(yè)務(wù)系統(tǒng)的實際應(yīng)用中總結(jié)的經(jīng)驗方法論，基本反映了金融業(yè)務(wù)特點對主機處理能力的需求:
TPM=TASK x 80% x S x F / (T x C)
其中:
TASK:為每日業(yè)務(wù)統(tǒng)計峰值交易量
T:為每日峰值交易時間，假設(shè)每日80%交易量集中在每天的4小時，即240分鐘內(nèi)完成:T=240。
S:為實際銀行業(yè)務(wù)交易操作相對于標(biāo)準(zhǔn)TPC-C測試基準(zhǔn)環(huán)境交易的復(fù)雜程度比例。由于實際的金融業(yè)務(wù)交易的復(fù)雜程度與TPC?C標(biāo)準(zhǔn)測試中的交易存在較大的差異，須設(shè)定一個合理的對應(yīng)值。以普通儲蓄業(yè)務(wù)交易為例，一筆交易往往需要同時打開大量數(shù)據(jù)庫表，取出其相關(guān)數(shù)據(jù)進(jìn)行操作，相對于TPC-C標(biāo)準(zhǔn)交易的復(fù)雜度，要復(fù)雜很多;根據(jù)科學(xué)的統(tǒng)計結(jié)果，每筆交易操作相比較于TPC標(biāo)準(zhǔn)測試中的每筆交易的復(fù)雜度此值可設(shè)定為10~20。
C:為主機CPU處理余量。實際應(yīng)用經(jīng)驗表明，一臺主機服務(wù)器的CPU利用率高于80%則表明CPU的利用率過高會產(chǎn)生系統(tǒng)瓶頸，而利用率處于75%時，是處于利用率最佳狀態(tài)。因此，在推算主機性能指標(biāo)時，必須考慮CPU的冗余，設(shè)定C=75%。
F:為系統(tǒng)未來3~5年的業(yè)務(wù)量發(fā)展冗余預(yù)留。
綜上所述，為保障聯(lián)機業(yè)務(wù)處理性能要求，我們可推算得出主機所需的處理能力，據(jù)此得出相應(yīng)的機型和配置。
舉例說明，使用TPC-C進(jìn)行數(shù)據(jù)庫服務(wù)器評估
下面針對XYZ行的網(wǎng)上銀行業(yè)務(wù)的需求，我們進(jìn)行數(shù)據(jù)庫服務(wù)器的選型分析。
由于目前XYZ行只有17個分行開通了網(wǎng)上銀行業(yè)務(wù)，據(jù)我們估計，按照目前的客戶數(shù)量，全部分行都開通網(wǎng)上銀行業(yè)務(wù)后，總的客戶數(shù)量可以達(dá)到10萬?？紤]INTERNET在我國的迅猛發(fā)展，客戶數(shù)量的年增長率按照50%計算，那么，3年后的客戶數(shù)量將達(dá)到10萬×(1+50%)3≈34萬。
這些客戶當(dāng)中，至少有一半是個人客戶，另一半是企業(yè)客戶。企業(yè)客戶的交易頻率比較高，我們按平均每個企業(yè)客戶每天做1.5筆交易計算;個人客戶常用的交易是查詢、取款、存款，并且每個月還要交電話費，因此我們假定個人客戶平均每個月做4次交易;那么，每天的交易量就是:
34萬×50%×1.5+34萬×50%×(4÷30) ≈28萬筆
假設(shè)網(wǎng)上銀行的交易復(fù)雜度達(dá)到15，那么，每天的數(shù)據(jù)庫操作數(shù)達(dá)到:
28萬×15=420萬次
高法訴訟費繳費:
由于訴訟費的增長量不大，我們按年遞增率5%計算。根據(jù)XYZ總行的統(tǒng)計，全國共37家分行，繳費量比較大的分行可以達(dá)到25000筆每月，占分行總數(shù)的20%;繳費量中等的省可達(dá)到15000筆每月，占分行總數(shù)的30%;繳費量小的省可達(dá)到7000筆每月，占分行總數(shù)的50%;按一個月20個工作日計算。這樣，三年后每天的交易數(shù)量可以達(dá)到:
(25000×20%+15000×30%+7000×50%)×37÷20×(1+5%)3≈28740筆
我們假設(shè)高法訴訟繳費的交易復(fù)雜度達(dá)到13，那么每天的數(shù)據(jù)庫操作達(dá)到:
28740*13=373620次
整體性能要求:
總的數(shù)據(jù)庫操作次數(shù)是:4200000+373620=4573620
假設(shè)每天的交易的80%集中在4小時內(nèi)發(fā)生，那么高峰交易時間內(nèi)每分鐘的數(shù)據(jù)庫聯(lián)機交易次數(shù)為:4573620×80%÷(4×60)≈15250
要為將來陸續(xù)加入的應(yīng)用預(yù)留40%的處理能力;另外，考慮到CPU的繁忙時間低于70%時，系統(tǒng)的性能較好，我們把這個比例定在65%。所以系統(tǒng)的TPC-C值應(yīng)達(dá)到:15250÷(1-40%)÷65%≈39000
內(nèi)存容量需求分析
首先根據(jù)數(shù)據(jù)庫容量算出所需的數(shù)據(jù)庫緩存大小，再估計出操作系統(tǒng)、系統(tǒng)軟件等所需內(nèi)存，合計即是所需的內(nèi)存容量。
網(wǎng)銀數(shù)據(jù)量分析:
XYZ總行網(wǎng)上銀行系統(tǒng)的數(shù)據(jù)庫由CIF信息，交易日志、交易流水三部分組成。
其中:CIF信息包括企業(yè)客戶和個人客戶信息，企業(yè)客戶信息平均大小為20K左右，個人客戶信息平均大小為5K左右;每一筆交易都要記交易日志，日志的平均大小為4K左右;每一筆轉(zhuǎn)帳交易都要記交易流水，交易流水的大小為2K左右。 #p#page_title#e#
這些客戶當(dāng)中，至少有一半是個人客戶，另一半是企業(yè)客戶。企業(yè)客戶的交易頻率比較高，我們按平均每個企業(yè)客戶每天做1.5筆交易計算;個人客戶常用的交易是查詢、取款、存款，并且每個月還要交電話費，因此我們假定個人客戶平均每個月做4次交易;那么，每天的交易量就是:
所有的交易日志和交易流水都要保留三個月。由于個人客戶的轉(zhuǎn)帳交易非常少，可以忽略不計;假定企業(yè)客戶的轉(zhuǎn)帳交易占總交易量的70%。我們就可以計算網(wǎng)上銀行對存儲系統(tǒng)容量的要求:
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網(wǎng)上銀行總體數(shù)據(jù)容量要求:=4GB+95GB+30GB=129GB
高法訴訟費數(shù)據(jù)量分析:
高法的交易數(shù)據(jù)按要求要保留三年，每筆交易記錄的大小為512字節(jié)，總體容量為:(25000×20%+15000×30%+7000×50%)×37×12×3×0.5K≈8.2GB
因此，數(shù)據(jù)庫的總數(shù)據(jù)量為: 129GB+8.2GB=137.2GB
數(shù)據(jù)庫系統(tǒng)在緩存容量達(dá)到數(shù)據(jù)庫總?cè)萘康?%時性能較好，因此，數(shù)據(jù)庫緩存大小為:6.86GB。
從而計算出系統(tǒng)內(nèi)存需求為:
1. AIX操作系統(tǒng)所占的內(nèi)存 128MB
2. 數(shù)據(jù)庫管理系統(tǒng)所占的內(nèi)存 256MB
3. 雙機熱備等系統(tǒng)軟件所占的內(nèi)存 128MB
4. 應(yīng)用程序所占的內(nèi)存 256MB
5. 數(shù)據(jù)庫緩存 6.86GB
6. 合理的內(nèi)存利用率 75%
總計 10GB
存儲容量需求分析
除了上述的XYZ網(wǎng)上銀行系統(tǒng)和高法訴訟費繳費系統(tǒng)的存儲容量要求之外，還有異步查詢下載服務(wù)的存儲要求。
異步查詢下載服務(wù)每隔1小時生成一個下載數(shù)據(jù)包，每個數(shù)據(jù)包的大小為3MB，需要下載的數(shù)據(jù)包是上午十點生成的數(shù)據(jù)包，這個數(shù)據(jù)包需要保存2年，其它數(shù)據(jù)包只要保存3個月。因此，存儲容量為:
23×3M×30×3+1×3M×365*2=6GB+2GB=8GB
為避免存儲系統(tǒng)成為系統(tǒng)性能的瓶頸，系統(tǒng)存儲系統(tǒng)的使用率應(yīng)小于40%，建議采用鏡像方式存儲數(shù)據(jù)，因此總的存儲容量為:
(137.2GB+8GB)÷40% ×2= 766GB
