歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Linux綜合 >> Linux資訊 >> 更多Linux >> 改善 Linux 內核和可伸縮性適應企業環境

改善 Linux 內核和可伸縮性適應企業環境

日期:2017/2/27 9:31:02   编辑:更多Linux
  改善 Linux 性能的第一步是對其進行量化。但如何精確地對 Linux 的性能或與它相當的系統性能進行量化呢?在本文中,IBM Linux 技術中心的成員描述了他們在去年底對 Linux 2.4 和 2.5 內核所做的幾個基准程序測試,就這些專家經驗,以飨讀者。    目前,Linux 操作系統是最成功的開放源碼項目之一。Linux 作為 Web 服務器操作系統,展示了其高可靠性,在 Web 服務器市場,它占據了很大的份額。這些 Web 服務器通常是低端及位於中間檔次的系統,帶有最多可達 4 路的對稱多處理器(SMP);而企業級系統有更復雜的需求,譬如需要更多的處理器個數和 I/O 配置以及大的內存和帶寬。為了使 Linux 為進入企業環境而作好准備,以及能夠作為商業性應用進入 SMP 市場,與商業 UNIX 系統相比,它的 SMP 可伸縮性、磁盤和網絡 I/O 性能、調度程序和虛擬內存管理器必須得到改善。    Linux 可伸縮性研究計劃(Linux Scalability Effort,LSE)(請參閱參考資料中的鏈接)是一個開放源碼項目,解決了用於企業級機器的 Linux 內核問題,這些機器的可伸縮性達到 8 路或更高。    IBM Linux 技術中心(Linux Technology Center,LTC)的 Linux 性能團隊(請參閱參考資料的相關鏈接)積極地參與了 LSE 活動。此外,他們的目標是,通過改進 Linux 內核性能(尤其針對 SMP 可伸縮性)而使 Linux 更優秀。    本文描述了在著重平台無關性問題的同時,該團隊在測量、分析與改進 Linux 內核性能和可伸縮性上所采用的策略和方法。該團隊使用了一套基准測試程序來完成此項任務。這些基准測試程序考慮到了各種工作負載,其中包括 Web 服務、數據庫和文件服務。此外,我們還將向您展示每個基准測試程序所著重的各個內核組件(例如,磁盤 I/O 子系統)。    分析方法  這裡我們討論用來量化針對 SMP 可伸縮性的 Linux 性能的分析方法。如果您願意,可以直接跳到基准測試程序結果這一節。    我們用來改進 Linux 性能和可伸縮性的策略包括:運行幾個業界接受的和組件級的基准測試程序,選擇合適的硬件和軟件,開發基准測試程序運行規則,設定性能和可伸縮性目標,以及測量、分析和改進性能和可伸縮性。在這一節中將詳細講述這些過程。    性能被定義為單處理器(UP)或 SMP 上的原始吞吐量。我們將 SMP 可伸縮性(CPU)和資源可伸縮性(例如,網絡連接數目)區別開來。    硬件和軟件  這項工作的大部分都使用 IA-32(即 x86)體系結構,從 1 個到 8 個處理器。我們還研究了與為將來之用的非一致內存訪問(NUMA)IA-32 和 NUMA IA-64 體系結構相關的問題。硬件的選擇通常是根據基准測試程序和相關工作負載的選擇。軟件的選擇要與 IBM 的 Linux 中間件策略和/或開放源碼中間件相結合。例如:    數據庫  我們采用查詢數據庫基准測試程序,而在硬件上,采用帶大磁盤配置的 8 路 SMP 系統。數據庫軟件采用 IBM DB2 for Linux,SCSI 控制器是 IBM ServeRAID 4H。這個數據庫是針對 8 路 SMP。   SMB 文件服務  基准測試程序是 NetBench,硬件是 4 路 SMP 系統,驅動 SMP 服務器的客戶機可多達 48 個。中間件是 Samba(開放源碼)。SMB 文件服務是針對 4 路 SMP。   Web 服務  基准測試程序是 SPECweb99,硬件是 8 路 SMP,並帶有大內存配置,客戶機可達 32 個。這個基准測試僅用於研究目的,不做它用(有關這方面的更多細節,請參閱基准測試程序這一節)。Web 服務器是 Apache,它是 IBM HTTP 服務器的基礎。我們選擇 8 路 SMP 是為了研究可伸縮性,而選擇 Apache 是因為它支持對下一代 posix 線程(NGPT)的測量和分析(請參閱參考資料)。此外,它是開放源碼,而且是最流行的 Web 服務器。   Linux 內核版本  采用哪個版本的 Linux kernel.org 內核(2.2.x、2.4.x 或 2.5.x)取決於基准測試程序;這將在基准測試程序一節做進一步討論。為了簡化管理,所選的 Linux 分發版是 Red Hat 7.1 或 7.2。我們的重點是內核性能,不是分發版的性能:我們用要評估的 kernel.org 內核和補丁替代了 Red Hat 內核。     運行規則  在設置基准測試程序期間,我們開發了運行規則以詳細地指出如何安裝、配置和運行基准測試程序,以及如何解釋結果。這些運行規則的目的如下:     定義度量,使用此度量來測量基准測試程序的性能和可伸縮性(例如,消息/秒)。   確保基准測試程序的結果適合於測量工作負載和內核組件的性能和可伸縮性。   提供文檔化的說明,這將使其他人可以重復該性能測試。   定義所收集的數據集,以便可以分析被測系統(System Under Tes,SUT)的性能和可伸縮性,從而確定瓶頸在哪裡。     設定目標  針對某個基准測試程序的性能及可伸縮性與具體的 SUT(硬件和軟件配置)有關。設定性能和可伸縮性目標需要:     基線測量,用來確定針對基線內核版本的基准測試程序的性能。然後計算基線可伸縮性。   最初的性能分析,用來確定增強性能的可行方向(例如,顯示調度程序非常忙的概要文件可能會建議嘗試 O(1) 調度程序)。   將基線結果與類似的已公布結果進行比較(例如,在 spec.org 上查找類似 8 路 SMP 上相同 Web 服務器上的 SPECweb99 公開結果)。     如果沒有可用的外部公開結果,則可以嘗試使用內部結果。還可以嘗試與其它操作系統進行比較。給定具有競爭性的數據和基線,然後選擇 UP 和 SMP 機器的性能目標。    最後,可以聲明應用程序變更了目標。例如,如果知道某個應用程序采用異步 I/O 方式效率不高,則可以通過假定改變 I/O 方法,公布該性能目標。    調優、測量和分析  在做任何測量之前,需要調優硬件和軟件配置。調優和測量是一個不斷循環的調優和測量過程。它涉及了系統組件(譬如 CPU 利用率和內存使用率)的測量,還可能涉及系統硬件參數、系統資源參數和中間件參數的調整。調優是性能分析的第一步中的環節。沒有調優,測量出的結果可能會使人產生誤解;即,這些結果可能不會指出內核的限制,而顯示出別的問題。    根據運行規則來運行基准測試程序,從而可以根據已定義的性能度量來測量性能和可伸縮性。對給定機器計算 SMP 可伸縮性時,可以選擇根據 UP 內核的性能來計算此度量值,也可以選擇根據 SMP 內核(其中處理器數目設為 1 — 一個處理器)的性能來計算它。我們決定使用 UP 測量來計算 SMP 可伸縮性,這樣可以更精確地反映 SMP 內核性能的改進。    使用前面確定下來的 Linux 內核版本來測量基線。對於大多數基准測試程序,需要測量 UP 和 SMP 基線。對於少數基准測試程序,只需測量 8 路 SMP 性能,因為收集 UP 性能信息受到時間限制。大多數其它基准測試程序測量在特定時間段內完成的工作量,在 UP 上的測量時間不超過在 8 路 SMP 上的測量時間。     分析 SUT(被測系統)的性能和可伸縮性所需的第一步是理解被測試的基准測試程序和工作負載。最初的性能分析是針對經過調優的系統而作出的。有時,分析揭示了對調優參數的其它修改。    對 SUT 性能和可伸縮性的分析需要一組性能工具。我們的策略是盡可能地使用開放源碼社區(Open Source community,OSC)的工具。這使我們可以將分析數據在 OSC 上公布,以說明性能和可伸縮性上的瓶頸。這也使 OSC 中的成員可以用工具重復我們的結果,或者在用該工具對另一個應用程序做完試驗之後,能夠理解這些結果。如果開發出專門的性能工具來更好地理解某個具體性能瓶頸,則隨後通常會將此專門的性能工具在 QSC 上共享。這些專門的性能工具通常是一些簡單工具,它們為特定的 Linux 內核組件提供了測試手段。我們所使用的性能工具包括:    /proc 文件系統  meminfo、slabinfo、中斷、網絡狀態、I/O 狀態等。   SGI 的 lockmeter   來自 SMP 鎖分析   SGI 的內核概要分析器(kernprof)  基於時間的概要分析、基於性能計數器概要分析、僅關於內核空間的帶注釋的調用圖(annotated call graph,ACG)   IBM 跟蹤工具  針對用戶空間和系統空間的單步(mtrace)並同時基於時間和基於性能計數器的概要分析     開發專門的性能工具,以進一步理解系統具體某個方面。    例如:    sstat   收集調度程序統計信息   schedret   確定哪些內核功能因調查空閒時間而阻塞了   acgparse   後處理 kernprof ACG   復制進/出工具  確定緩沖區的調整、復制大小和復制進/出算法的 CPU 利用率     然後使用性能分析數據來確定性能和可伸縮性的瓶頸。需要對 SUT 有寬泛的理解,並要對基准測試程序所著重的 Linux 內核組件有更具體的理解,從而理解性能瓶頸存在於何處。還必須理解造成瓶頸的 Linux 內核源代碼。此外,我們需要與 LTC Linux 內核開發團隊和 OSC(開放源碼社區)緊密合作,以便開發補丁來修正瓶頸。    退出策略  對 Linux 內核性能的評估可能需要運行基准測試程序,然後分析結果來確定性能和可伸縮性的瓶頸,接著將補丁集成進 Linux 內核來解決所有這些瓶頸,最後再次運行該基准測試程序,這是一個周而復始的過程。作為一名性能團隊成員,要與 Linux 內核開發團隊或 OSC 通力合作,通過在 OSC 查找現有的補丁或者開發新的補丁來獲取補丁。有一組用來確定何時 Linux 已經“足夠好了”和可以結束該過程的標准。    首先,如果我們已經達到了目標,並且,針對某個具體基准測試程序,不存在需要解決的任何突出的 Linux 內核問題(解決這些問題可以很大程度地改善




Copyright © Linux教程網 All Rights Reserved