Linux 線程庫效能測試與分析

簡介： NPTL 成為 glibc "正選"線程庫後，它的效能如何受到很多人的關注。本文就針對NPTL 與 LinuxThreads 的效能比較，以及超執行緒、核心可搶佔等特性對線程效能的影響進行了全面評測。

 

 

一、 前言

在 Linux 2.6.x 核心中，調度效能的改進是其中最令人信服的一部分[1]。NPTL（Native Posix Thread Library）[2]使用核心的新特性重寫了 Linux 的線程庫，取代曆史悠久而備受爭議的 LinuxThreads[3] 成為 glibc 的首選線程庫。

NPTL 的效能究竟如何？相對 LinuxThreads 又有哪些明顯的改進？在對NPTL進行全面分析之前，本文針對這兩種線程庫，以及核心中"核心可搶佔"（Preemptible）和超執行緒（HyperThreading）[4]等特性進行了全面的效能評測，結果表明NPTL絕對值得廣大伺服器系統期待和使用。

回頁首

二、 Benchmark

1. 測試平台

進行本測試的硬體平台為浪潮NF420R伺服器[7]，4個Hyperthreading-enabled Intel Xeon 2.2G處理器，4G記憶體。Linux選擇了Slackware 9.0發行版[8]，所使用的核心源碼來自 www.kernel.org。

2. 針對測試：LMBench

lmbench是一個用於評價系統綜合效能的多平台開源benchmark[5]，但其中沒有對線程的支援。其中有兩個測試進程效能的benchmark：lat_proc用於評測進程建立和終止的效能，lat_ctx用於評測進程切換的開銷。lmbench擁有良好的benchmark結構，只需要修改具體的Target程式（如lat_proc.c和lat_ctx.c），就可以借用lmbench的計時、統計系統得到我們關心的線程庫效能的資料。

基於lat_proc和lat_ctx的演算法，本文實現了lat_thread和lat_thread_ctx兩個benchmark。在lat_thread中，lat_proc被改造成使用線程，用pthread_create()替代了fork()，用pthread_join()替代wait()；在lat_thread_ctx中，沿用lat_ctx的評測演算法（見lat_ctx手冊頁），將建立進程的過程改寫為建立線程，仍然使用管道進行通訊和同步。

lat_thread null

null參數表示線程不進行任何實際操作，建立後即刻返回。

lat_thread_ctx -s<size> #threads

size參數與lat_ctx定義相同，可表示線程的大小（實際編程時為分配<size>K資料；#threads參數為線程數，即參與令牌傳遞的線程總數，相當於程式負載情況。

3. 綜合測試：Volanomark

volanomark是一個純java的benchmark，專門用於測試系統調度器和線程環境的綜合效能[6]，它建立一個類比Client/Server方式的Java聊天室，通過擷取每秒平均發送的訊息數來評測宿主機綜合效能（數值越大效能越好）。Volanomark測試與Java虛擬機器平台相關，本文使用Sun Java SDK 1.4.2作為測試用Java平台，Volanomark版本2.5.0.9。

回頁首

三、 測試結果

測試計劃中將核心分為2.4.26、2.6.6/支援核心搶佔和2.6.6/不支援核心搶佔三類；通過配置核心以及NF420R的BIOS實現三類SMP規模：單處理機(UP)、4CPU的SMP（SMP4）和開啟超執行緒支援的虛擬8CPU SMP（SMP8*）。核心配置和SMP規模的每一種組合都針對LinuxThreads和NPTL使用lat_thread、lat_thread_ctx和volanomark擷取一組資料。由於NPTL無法在2.4.x核心上使用，該項資料空缺。

回頁首

四、 結果分析

1. LinuxThreads vs NPTL：線程建立/銷毀開銷

使用2.6.6/preemptible核心配置下UP和SMP4的測試資料獲得：

圖1

線上程建立/銷毀開銷方面，NPTL的改進相當明顯（降低約600%）。實際上，NPTL不再像LinuxThreads那樣需要使用使用者級的管理線程來維護線程的建立和銷毀[9]，因此，很容易理解它在這方面的開銷能夠大幅度降低。

同時，由圖可見，單CPU下建立線程總是比多CPU下迅速。

2. LinuxThreads vs NPTL：線程切換開銷

同樣使用2.6.6/preemptible核心配置下UP和SMP4的資料：

圖2

隨著lat_thread_ctx的參與線程增多，不管是哪個線程庫，單處理機條件下的線程切換開銷都陡峭上升，而SMP條件下則上升比較平緩。在這方面，LinuxThreads和NPTL表現基本相同。

3. 核心影響

圖3

圖4

圖5

圖6

從上面四張圖中我們可以得出兩點結論：

• "核心可搶佔"是Linux對即時應用提供更好支援的有力保障，但對線程效能影響很小，甚至有一點損失，畢竟搶佔鎖的開銷不可忽略；
• 升級核心並不會對LinuxThreads線程庫效能帶來多少變化，因此，對於伺服器系統而言，不能指望僅僅編譯使用新核心就能提高效能。

圖7

圖8

從圖3、圖4我們已經知道，開啟超執行緒支援對線程建立/銷毀效能幾乎沒有影響，而這兩張圖表也進一步說明，超執行緒技術對於線程切換開銷也沒有明顯的影響。超執行緒技術是CPU內部的最佳化技術，和真正的雙CPU完全不同。大量研究表明，如果沒有核心與使用者應用相結合的專門最佳化措施，超執行緒並不會帶來很大的效能變化。除非是高負載綜合伺服器系統（例如繁忙的資料庫系統），購買超線支援的CPU並不能帶來多少好處。

4. 綜合效能

圖9

圖9

前面幾節分析讓我們瞭解了線程庫效能改進的細節，通過volanomark測試，我們可以近似得到在綜合應用環境下，特別是網路服務需求中線程庫以及核心對系統整體效能的影響程度。

圖9綜合了不同核心、不同處理機數條件下，兩種線程庫的volanomark結果。可以觀察到以下三點：

• NPTL能極大提高SMP環境下伺服器系統的整體效能（超過65%），相對而言，對單處理機系統影響較小（10%左右）；
• 2.6核心的搶佔特性對系統效能影響很小（不超過±1%），某些情況下甚至有所下降；
• 超執行緒技術在LinuxThreads中的影響是負面的，在NPTL中是正面的，但影響幅度都很小（5%-6%）。

以上結論中前兩點與LMBench針對性測試結果完全吻合，第三點的偏差實際上反映了超執行緒技術對於綜合伺服器環境還是有一定加速的。

回頁首

五、 總結

我們的評測為廣大Linux使用者，特別是伺服器使用者提供了一點有價值的參考：

• 如果你的是多處理機系統，那麼毫不猶豫地升級你的核心，並記住，一定要同時升級你的線程庫，它通常與glibc緊密耦合；
• 如果你的系統並沒有即時應用，不要開啟"核心可搶佔"開關，它只會讓你的系統更慢；
• 謹慎考慮是否使用超執行緒技術，即使你已經購買了支援超執行緒的CPU，有時關閉它可能更適合你的需求。

參考資料

1. [pubb@163.net，2004] Linux 2.6調度系統分析，IBM DeveloperWorks, www.ibm.com/developerworks/cn/linux/kernel/l-kn26sch/index.shtml
2. [Ulrich Drepper，2002] Native Posix Threading Library， people.redhat.com/drepper/nptl-design.pdf
3. [Xavier.Leroy@inria.fr，1996] LinuxThreads線程庫， pauillac.inria.fr/~xleroy/linuxthreads/
4. [Intel Co.，2002]HyperThreading超執行緒技術， www.intel.com/technology/hyperthread/
5. [Larry McVoy,lm@bitmover.com，1998]LMbench， www.bitmover.com/lmbench/
6. [volano LLC，2004] Volanomark Benchmark， http://www.volano.com/benchmarks.html
7. [Slackware，1993]Slackware Linux Distribution， www.slackware.com
8. [pubb@163.net，2003] Linux 線程實現機制分析， www.ibm.com/developerworks/cn/linux/kernel/l-thread/index.shtml
9. [jim@2cpu.com，2004] Exploring Hyper-Threading Performance ， http://www.2cpu.com/articles/42_1.html