天天看點

MySQL資料庫性能優化之硬體瓶頸分析

轉載 http://isky000.com/database/mysql-performance-tuning-hardware  

接着上一篇 MySQL資料庫性能優化之存儲引擎選擇,這是 MySQL資料庫性能優化專題 系列的第六篇文章:MySQL資料庫性能優化之硬體優化

在過往與很多人的交流過程中發現,在談到基于硬體來進行資料庫性能瓶頸分析的時候,常被大家誤解為簡單的使用更為強勁的主機或者存儲來替換現有的裝置。

個人覺得這其中可能存在一個非常大的誤區。我們在談論基于硬體進行優化的時候,不能僅僅将資料庫使用的硬體劃分為主機和存儲兩部分,而是需要進一步對硬體進行更細的分解,至少也應該分解到如下範疇:

  • 主機
    • CPU:僅僅隻能決定運算速度,及時是運算速度都還取決于與記憶體之間的總線帶寬以及記憶體本身的速度
    • 記憶體:大小決定了所能緩存的資料量,主要決定了熱點資料的通路速度
    • 磁盤:
      • 大小:決定了你最終能存放多少資料量
      • 轉速:決定了你每一次IO請求的延時時間,也就是決定了我們常說的IOPS和MBPS
      • 數目:磁盤數目決定了
      • 類型
        • 機械:SAS or SATA or FC ?
        • SSD:磁盤 or PCI卡?
    • Raid卡:
      • 緩存:緩存大小對資料寫入速度有較大影響,使用政策也會直接影響IO效率
      • 電池:電池充放電政策會影響到瞬時IO的波動
    • 其他:如總線帶寬等,決定了CPU與記憶體間資料傳輸效率,這一點很多時候關注較少,但也可能會出現瓶頸
  • 存儲
    • 記憶體:儲存設備同樣也有記憶體,用來存儲前端主機通路的熱點資料。存儲的記憶體大小同樣決定了熱點資料的通路速度
    • 磁盤:和主機磁盤類似
    • 線路/環路帶寬:環路帶寬必須能夠比對磁盤帶寬,至少不能少于磁盤所能輸出的能力,否則就想被堵在高速收費站等待通行的車輛一樣
  • 網絡
    • 延時:不同的網絡裝置其延時會有差異,對于 OLTP 裝置來說,延時自然是越小越好
    • 吞吐量:對于資料庫叢集來說,各個節點之間的網絡吞吐量可能直接決定叢集的處理能力
    • iops:對于 OLTP 系統,資料傳輸更多是以小IO多并發方式,有時候光有大帶寬并不一定能滿足需求

硬體角度所能提供的處理能力,一定是上面所列的多個方面(這裡僅僅隻是主要部分,可能還有其他)共同決定的整體能力,任何一個方面出現瓶頸,都能導緻整體性能上不去,也就是我們常說的木桶原理。

在以往的經驗中,最容易出現性能瓶頸的地方主要會出現在以下幾個方面:

  • IO資源方面瓶頸

    出現 IO 資源方面瓶頸的時候,主要表現在伺服器 iowait 很高,usr 占比較少,系統響應較慢,資料庫中經常會存在大量執行狀态的 session。

    遇到 IO 資源方面的瓶頸,我們可以使用的硬體層面優化方案主要就是:

    • 增加記憶體加大可緩存的資料量:這個方案能否達到效果取決于系統熱點資料的總量,畢竟記憶體的成本也是比較高的,而且單台裝置所能管理的記憶體量也是有限的
    • 改善底層儲存設備的 IO 能力:如本文前面所述,底層存儲能力的改善同時取決于多個方面,既有單個磁盤本身的能力問題,也包括磁盤數目方面的政策,同時還受到存儲自身以及存儲和主機之間的帶寬限制。是以在優化底層存儲能力的同時需要同時考慮到這3方面的因素,做好總體分析和局部的平衡
  • CPU資源方面瓶頸

    當 CPU 方面資源遇到瓶頸的時候,主要表現在伺服器CPU使用率中 usr 所占比例很高,iowait卻很小。這類問題大多出現在資料量并不是太大,同時又有足夠記憶體來對資料進行緩存的應用場景。同時也是目前大多數中小網站所面臨的資料庫性能瓶頸。

    當遇到 CPU 方面的資源瓶頸的時候,可能由兩個方面造成:

    • 過多依賴資料庫進行邏輯運算:對于這種狀況,最好的優化方式是将運算盡可能從資料庫端遷移到應用端,降低資料庫主機的計算量。畢竟對有狀态的系統裝置(資料庫)進行擴容的成本遠高于無狀态類系統裝置(應用)。當然如果非要從資料庫端的硬體來解決問題,那就隻有通過增加裝置CPU數目(如果支援),或者是使用CPU能力更為高端的主機來替換老主機
    • 資料庫邏輯IO太大:對于這類狀況,從硬體角度來說能做的就隻有提升CPU處理能力。要麼增加 CPU 數目(如果支援),要麼換CPU更強勁的主機。但是在這之前,還是建議先嘗試從應用角度優化看看是否能夠盡量降低非必要請求或者是減少每次請求的資料量。同時從資料庫角度針對 Schema結構以及索引進行相應的優化調整,盡可能讓完成一次請求所需要檢索的資料量更小,進而達到降低邏輯IO的目的
  • 網絡資源方面的瓶頸

    一般來說應用與資料庫之間的網絡互動所需的資源并不是非常大,是以這個環境遇到瓶頸的可能并不是非常大。但是在分布式的叢集環境中,各個資料庫節點之間的網絡環境經常會稱為系統的瓶頸。

    比較常見的場景如 MySQL Cluster 或者是 Oracle RAC 環境中,節點之間的資料交換網絡環境的優劣可能直接影響到系統的整體處理能力,因為在節點間會存在大量的資料交換,都是依賴網絡傳輸來完成。

    在這樣的場景中,廉價一點的解決方案是通過 萬兆交換機 來替換現在常用的 千兆交換機 來提升網絡處理能力降低網絡延時。不過這個方案主要提升的是吞吐量方面,對于延時方面的提升可能并不一定能滿足某些要求非常高的場景。這時候就該考慮使用更為昂貴但也更高效的方案:用 Infiniband 替換普通交換機來極大的降低網絡方面所帶來的資料交換延時。

以上僅僅隻針對主要類型的硬體資源瓶頸做了一些分析和相應可能的處理方式,歡迎大家一起探讨,也可以包括目前比較“熱”的SSD。後面我可能還會再寫一篇關于 SSD 的文章,國内接觸 SSD 并将之正式用于核心産品環境的,可能比我更早人還是比較少的。