簡介:
mpiBLAST是一開放原始碼的平行化BLAST程式,mpiBLAST將資料庫切割,並將切割後的數個子資料庫分派給計算叢集中的每個節點,每個節點均被分到一個唯一的子資料庫。資料庫分割後,讓每個節點只需搜尋資料庫中較小的子集,期望能將所需搜尋的資料全部都能存於記憶體(RAM)中,減少磁碟存取(disk I/O,disk I/O耗費的時間遠大於RAM存取的時間),以增加BLAST的效能。
但是,mpiBLAST在進行資料庫切割、分配子資料庫與工作、傳輸資料、收集彙整節點所產生之結果上,均花費額外的時間,因此,本次實習主要在測試在不同資料庫、不同節點數量、不同長度序列上mpiBLAST效能的差異。
測試環境:
硬體:
IBM Xseries 335 × 8
CPU: Dual Xeon 2.4 G
RAM: 1G
軟體:
OS: Rocks Cluster Distribution
Application: mpiBLAST 1.2.1
測試序列:
從已知序列隨意取:
100 bs × 10
200 bs × 10
300 bs × 10
400 bs × 10
500 bs × 10
600 bs × 10
700 bs × 10
800 bs × 10
900 bs × 10
1000 bs × 10
測試結果:
經由實際執行結果發現在胺基酸的資料庫上,mpiBLAST執行效能不但並未因計算節點的增加而加速,反而會因節點的增加而增長計算的時間,推斷應是胺基酸資料庫之大小均在1G (RAM Size)以下,因為本來就不會使用到磁碟做為虛擬記憶體,所以並未達到減少磁碟存取而加快速度的效果,反而因為需做額外的資料庫切割、分配子資料庫與工作、傳輸資料、收集彙整節點所產生之結果等工作,因此增加電腦的負擔,減慢計算的效能 (如圖1)。
胺基酸資料庫的大小
db |
Size(G) |
alu.a |
0.00 |
drosoph.aa |
0.01 |
ecoli.aa |
0.00 |
env_nr |
0.24 |
igSeqProt |
0.01 |
mito.aa |
0.00 |
month.aa |
0.05 |
nr |
0.92 |
pataa |
0.05 |
pdbaa |
0.01 |
swissprot |
0.07 |
yeast.aa |
0.00 |
Yeast_aa
圖1
相似的結果亦出現在核酸資料庫中,但是我們發現當資料庫大小超過1G時,計算時間即會因節點的增加而減少,可是當達到某個節點數時,又會發生計算時間增加的情形,推斷應是原本因減少磁碟存取所節省的時間,被過多的資料庫切割…等等額外工作所消耗,甚至增加計算的時間 (資料庫切割、分配子資料庫與工作、傳輸資料、收集彙整節點所產生之結果等工作所需的時間會與節點的數量成正比)。
此外,我們發現當資料庫越大時,計算節點的增加使計算時間減少的情形更為顯著,即邊際效益增加 (如圖2)。
Patnt (Size = 1.28G)
Est_human (Size =3.44G)
圖2
除了以上幾點,我們還發現到,當查詢的序列越長時,相同長度的相異序列在mpiBLAST計算上所需花費的時間較為穩定,短序列則波動較大,較看不出一致的趨勢 (如下圖)。
Est_human
結論:
當我們要建置mpiBLAST系統時,應該注意到cost-performance的問題,越多電腦其運算能力當然越強,但是增加的運算能力究竟是充份被利用或是被閒置,則是我們要考慮的問題。
經過這次測試我們可以知道,在此軟硬體環境下,胺基酸的資料庫應該只用一台電腦計算即可,核酸資料庫中大小少於1G者亦同,est_mouse、est_human、human_genomic建議採3台電腦(即5~6顆CPU),因為6台以上時,其邊際效益並不顯著,patnt、other_genomic則建議2~3台電腦(即4~5顆CPU)為佳,gss建議6~7台,est_others建議8~9台,nt與wgs因測試電腦的硬碟空間不足,所以無法進行測試,但推測nt應用11~12台電腦,wgs則應用26~27台電腦。
此外,由於記憶體的數量正好與電腦數量成正比,從以上的數據可發現,運算時間最短的電腦所含之記憶體數量,正巧與該資料庫之大小一致,故推測當記憶體大小=序列資料庫大小時,cost-performance為最佳。
然而,此次測試並非一個標準,只能說在此軟硬體環境下,提供一個電腦資源分配的參考,以求最高的成本效益。
日後若欲建置類似系統時,建議先進行此類測試,以達最佳的計算效率,並節省不必要的硬體成本,也可做為工作資源配置的參考。