儲存效能瓶頸分析

2022-09-11 12:39:22 字數 2506 閱讀 7827

以下是儲瓶頸發生最常見的四種典型情況:

當多個使用者同時訪問某一業務應用,無論是郵件伺服器,企業資源規劃(erp)系統或資料庫,資料請求會累積在佇列中。單個 i/o 的響應時間開始增長,短暫延時開始轉變成為漫長的等待。

這類響應時間敏感型應用的特徵是,很多隨機請求,讀取比寫入更多,i/o 較小。最好的方法是:將負載分布在多塊磁碟上,否則可能造成效能瓶頸。

如果應用增加了更多使用者,或應用 iops 請求增加,則可能需要在 raid 組中新增更多磁碟,或資料可能需要跨越更多磁碟,在更多層級做條帶化。

儲存在這樣的情況下往往首先被懷疑,但大多數情況下並非儲存引發,原因可能在於網路、應用或伺服器。

raid 組中的磁碟故障。特別是在 raid 5 中會造成效能的下降,因為系統需要重建校驗資料。相比資料讀寫操作,重建會對效能造成更大影響。

即便壞盤是造成故障的根源,但控制器還是可能成為瓶頸,因為在重建過程中它需要不停地服務資料。當重建完成時,效能才會恢復正常。

部署了一種新的應用,而捲存在於處理繁忙郵件系統的同一磁碟。如果新的應用變得繁忙,郵件系統效能將會遭受影響。額外的流量最終會將磁碟完全覆蓋。

儲存部署於集中化 san 環境時,需考慮伺服器和 san 之間的潛在網路瓶頸。例如,執行多部虛擬機器的整合伺服器可能不具備支援工作負載要求的足夠網路埠。新增網路埠或轉移網路密集型工作負載至其他伺服器可解決這一問題。如前所述,對於頻寬集中型應用,需考慮 nfs 有多少 fiber channel 埠, or iscsi 埠 or ethernet 埠,需要使用者站在頻寬的角度來考量整個架構。

可能發生的問題包括:

乙個標準的主動——被動或主動——主動控制器都有乙個效能極限。接近這條上限取決於使用者有多少塊磁碟,因為每塊磁碟的 iops 和吞吐量是固定的。

可能出現的問題包括:

由於伺服器記憶體和 cpu 遠比機械磁碟快得多,需為磁碟新增高速記憶體以快取讀寫資料。例如,寫入磁碟的資料儲存在快取中直到磁碟能夠跟上,同時磁碟中的讀資料放入快取中直到能被主機讀取。cache 比磁碟快 1000 倍,因此將資料寫入和讀出 cache 對效能影響巨大。智慧型快取演算法能夠**你需要查詢的資料,你是否會對此資料頻繁訪問,甚至是將訪問頻繁的隨機資料放在快取中。

可能發生的問題包括:

磁碟瓶頸與磁碟轉速有關, 慢速磁碟會引入較多延時。儲存效能問題的排查首先考慮的因素就是磁碟速度,同時有多少塊磁碟可進行併發讀寫。而另一因素是磁碟介面。採用更快的介面能夠緩解磁碟瓶頸,但更重要的是在快速介面與相應更大的快取大小以及轉速之間取得平衡。同樣,應避免將快速和慢速磁碟混入同一介面,因為慢速磁碟將會造成快速介面與快速磁碟的效能浪費。

可能引發的問題包括:

曾經一度儲存廠商們強調的是 iops 和吞吐量,但現在重點逐漸轉變成為響應時間。也就是說,不是資料移動的速度有多快,而在於對請求的響應速度有多快。

正常情況下,15,000 rpm fibre channel 磁碟響應時間為 4ms,sas 磁碟響應時間約為 5ms 至 6ms,sata 為 10ms,而 ssd 少於 1ms。如果發現 fibre channel 磁碟響應時間為 12ms,或 ssd 響應時間變成 5ms,那麼就說明可能產生了爭用,可能晶元發生了故障。

除了響應時間,其他需要監控的指標包括:

效能調優和改進的方式有很多種,使用者當然可以通過新增磁碟,埠,多核處理器,記憶體來改善,但問題是:價效比,以及對業務是否實用。本文建議的方式是在預算範圍內找尋效能最大化的解決方案。另外乙個需要考慮的方面是環境並非一塵不變,系統部署方案要能夠適應環境的改變需求。

首先需要考慮刷資料的效能特徵,需要了解 io 工作情況是怎樣的。是否是 cache 友好型?是否是 cpu 集中型?業務資料很大數量很少,還是很小但數量很多?另外一方面就是構成儲存環境的元件。包括應用,儲存系統本身,網路。。。瓶頸可能在**,改善**最有效?

以下是一些常規建議:

不要僅僅根據空閒空間來分配儲存,而需要結合考慮效能需求,確保為吞吐量或 iops 分配足夠多的磁碟。

在磁碟間均衡分布應用負載,以減少熱點地區的產生。

理解應用負載型別,並針對負載選擇匹配的 raid 型別。例如,寫密集型應用建議使用 raid 1 而不是 raid 5。因為當寫入 raid 5 時,需要計算校驗位,需耗費較多時間。而 raid 1,寫入兩塊磁碟速度快得多,無需計算。

磁碟型別(fibre channel, sas, sata)與期望效能相匹配。對於關鍵業務應用部署高效能磁碟,例如 15,000 rpm fibre channel。

對於 i/o 密集型應用考慮採用 ssd,但並不適用於寫效能重要型應用。只要沒有達到控制器瓶頸,ssd 對讀效能提公升顯著,但對寫效能提公升並沒有明顯效果。

採用端對端的監控工具,特別是虛擬伺服器環境。虛擬端與物理端之間有一道防火牆,所以,需要穿透防火牆進行端到端的監控。

有些效能分析工具涵蓋從應用到磁碟,有些僅侷限於儲存系統本身。由於效能是乙個連鎖反應包含很多變數,所以需要全面地分析資料。

以資料僅寫入磁碟外部扇區的方式格式化磁碟。因減少資料定位時間而在高 i/o 環境下提公升效能。負面作用是相當一部分磁碟容量未能得以使用

**自 儲存效能瓶頸的成因、定位與排查 | hellodog (wsgzao.github.io)

效能測試瓶頸分析

在效能測試過程中,瓶頸猶如功能測試的bug,瓶頸的分析猶如bug的定位。效能測試工程師好比醫生,看到病象,定位 效能瓶頸的定位更像庖丁解牛,層層解剖,最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象,其實說明不了什麼問題,就象...

效能瓶頸分析方法

oracle資料庫 1 如果自由記憶體接近於0而且庫快存或資料字典快存的命中率小於0.90,那麼需要增加shared pool size的大小。快存 共享sql區 和資料字典快存的命中率 select sum pins reloads sum pins from v librarycache sel...

效能測試瓶頸分析

在效能測試過程中,瓶頸猶如功能測試的bug,瓶頸的分析猶如bug的定位。效能測試工程師好比醫生,看到病象,定位 效能瓶頸的定位更像庖丁解牛,層層解剖,最後定位問題之所在。下面分享乙個記憶體洩漏的瓶頸分析。病象 tps波動非常大 狂打超時日誌 偶爾有500錯誤。看到這個現象,其實說明不了什麼問題,就象...