大資料小視角5:探究SSD寫放大的成因與解決思路
筆者目前開發運維的儲存系統的伺服器都跑在SSD之上,目前單機伺服器最大的SSD容量有4T之多。(公司好有錢,以前在實驗室都只有機械硬碟用的~~)但SSD本身的特性與機械硬碟差距較大,雖然說在效能上有諸多優勢,但是如果使用的方式方法不對,反而會事倍功半。所以筆者花時間調研了一下固態硬碟的結構與特性,並且總結了一些避免SSD寫放大效能下降的法則,希望對大家有所幫助~~
1.SSD的寫放大
首先我們來看看什麼是寫放大,寫放大(Write amplification)是2008年,由英特爾和SiliconSystems在論文之中首次提出:它表現為在SSD上實際寫入的資料遠遠大於使用者寫入資料。
為什麼會產生這樣的現象呢,我們要回歸到固態硬碟原本的特性。首先固態硬碟與傳統的機械硬碟不同的點在於它不能夠覆蓋寫。所以對於已經存在資料SSD來說,一次資料的寫入分為2個動作:
1、擦除SSD上已有的資料。
2、寫入新的資料。
寫入放大的問題就出了這個部分,因為SSD每次寫入的最小單位為Page,每個Page是4KB大小,而每次擦除的大小單位為Block,Block通常由64或128個Page組成。也就是說,正是由於SSD寫入與擦除的單位大小不匹配,導致了寫入放大。如果僅僅是寫入單一Page的資料,而單個Block之中沒有了空餘的Page,則需要擦除一個Block的資料,之後再寫入一個Block的資料。所以說,本身只需要4KB的寫入,"放大"了64倍甚至是128倍!由於SSD的壽命取決於擦除次數,所以寫入放大會大大影響到SSD的使用壽命
典型的一個"寫放大"的場景
OK,瞭解了寫入放大的現象之後,我們接下來怎麼樣會導致寫入放大的現象呢?
寫入量
這點應該很好理解,由上面的闡述可以看到,如果每次對SSD的寫入都是很小的量,就會產生典型的寫入放大。
剩餘容量
通常我們使用的SSD都存在預留空間(OP)來用於給SSD的主控晶片來進行一些最佳化操作。其中預留空間最為核心的兩項工作就是垃圾回收與損耗均衡,在這裡筆者簡要介紹一下垃圾回收和損耗均衡。
垃圾回收:
SSD中主流的垃圾回收演算法與Java之中的標記清除的垃圾回收演算法類似:
SSD的垃圾回收
如上圖所示,SSD首先在Block X之中寫入A-D的Page頁,之後繼續寫入到H,並且更新了A'-D',所以原先的A-D的page頁成為了需要回收的垃圾。所以主控晶片會將可用資料移動到旁邊的有空閒的Block Y,同時完整的擦除Block X。當剩餘容量越小,垃圾回收越頻發,則SSD的寫入放大就越為嚴重。就是為什麼許多手機在剛剛買來之後絲滑如順,但是之後就越用越卡,這是因為容量越來越小了,SSD需要背鍋!!(這也是筆者的64G的小米5剩餘容量只有4個G了,日常使用卡如狗的部分原因~~)需要頻繁進行垃圾回收的場景會導致寫入放大的問題更為嚴重。
損耗均衡:
我們知道,SSD的使用壽命等同於Block的擦寫次數,目前主流使用的MLC顆粒的程式設計/擦寫次數一般在3000 ~ 5000次左右。如果反覆地程式設計和擦寫某個Block,該Block則會先於其他Blcok損壞,導致壞塊大量出現。正是因為這樣的原因,SSD的主控晶片會盡可能的讓每個Block的擦寫次數均勻。所以損耗均衡的操作需要移動並沒有新資料寫入的Block,這樣同樣也會導致寫放大的上升。
2.寫放大問題的一些解決思路
瞭解了SSD的寫放大的成因之後,我們可以『對症下藥』的嘗試給出一些方案來減小寫放大問題來對我們線上服務的影響。
批次寫
這幾乎是解決磁碟io問題的通用解決方案,同樣適合於傳統的機械硬碟與SSD。儘量在程式碼邏輯之中減少隨機寫的次數,來避免由少量寫操作引發的寫放大問題,同時可以考慮透過塊對齊的方式來進一步減少寫入產生的寫放大問題。(當然這裡所謂塊對齊的思路在是與程式執行環境緊耦合的,程式的可移植性會大打折扣)預留空間,容量告警
這也是我們運維線上機器常用的思路,對於SSD的使用量要有一個閥值,超過我們的預設容量時,線上的程式需要給運維和開發人員告警。寫壓縮
寫壓縮是依賴SSD的主控晶片的,部分SSD主控晶片支援寫壓縮。也就說接受到作業系統傳送要寫入20m資料,主控晶片可以透過一些流壓縮或塊壓縮的演算法壓縮資料,在讀取資料時,再重新進行解壓。這種方式強依賴硬體,並且新的瓶頸可能會是主控晶片的壓縮,解壓的速度。TRIM命令
TRIM是作業系統層級的命令。作業系統利用TRIM命令來標記SSD上某個Page的資料可以回收。一旦某個Page被SSD標記為可以回收,在SSD空閒的時候SSD的主控晶片會將這些被標記的Page資料收集到同一個Block,然後共同擦除。這樣每次需要寫資料時,就在已經有足夠空閒的Page可以寫入新的資料。
上述幾個思路都是在實踐中可以採取的措施,其實TRIM命令需要透過Linux設定開啟,這裡筆者在這裡介紹一下如何在Linux下開啟TRIM命令:
-
確認Linux的核心是否大於 2.6.28,筆者這裡是4.9.0的核心。
檢視系統核心
2.呼叫hdparm -I /dev/sda1 命令確認SSD裝置是否支援TRIM。
SSD裝置支援TRIM
3.修改/etc/fstab檔案,在掛載選項之中新增discard,重啟之後就開啟了TRIM在fstab之中新增discard引數
3.小結
到此為止,筆者聊了聊SSD寫放大的成因,並且針對SSD寫放大的成因,提出了一些解決的思路和方法,希望大家能有所收穫,在生產環境之中能夠更好的『調教好』SSD~~~
作者:LeeHappen
連結:https://www.jianshu.com/p/8885fce8e168
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/1727/viewspace-2815018/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 大資料小視角2:ORCFile與Parquet,開源圈背後的生意大資料
- 大資料小視角1:從行儲存到RCFile大資料
- 大資料小視角3:CarbonData,來自華為的中國力量大資料
- 視角 | 微服務的資料一致性解決方案微服務
- 分享一個 JSON 相關小需求的解決過程與思路JSON
- 全新視角,探究「目標檢測」與「例項分割」的互惠關係 | AAAI系列解讀 02AI
- 資料庫層面問題解決思路資料庫
- 淺談js的this指向與解決思路JS
- 解碼智慧治理 用大資料解決民生小問題大資料
- 雲上大資料儲存:探究 JuiceFS 與 HDFS 的異同大資料UI
- 上帝視角一覽大資料開發體系大資料
- 解決AI的小資料問題AI
- 大資料解決方案大資料
- Bigkey問題的解決思路與方式探索
- 寶付大資料視覺化一文解決大資料視覺化
- 全新視角探究目標檢測與例項分割的互惠關係 | AAAI 2020AI
- 容器雲資源資料關聯與資料聯動的難點和解決思路
- MybatisPlus多資料來源及事務解決思路MyBatis
- 寫好資料分析報告,資料的思路非常重要
- 產品視角下的資料倉儲
- CDN流量放大攻擊思路
- 資料大屏視覺化解決方案,常用的資料視覺化工具軟體視覺化
- 大資料和資料倉儲解決方案大資料
- Ajax跨越問題原因分析與解決思路
- 基於 HTML5 WebGL 與 GIS 的智慧機場大資料視覺化分析HTMLWeb大資料視覺化
- Unity Webgl小遊戲存取資料的解決方案UnityWeb遊戲
- 大資料匯流排平臺DBus設計思路與工作原理大資料
- 大資料儲存解決方案中的分離式與超融合部署大資料
- 詳解:十種常用的的資料分析思路!
- 華為雲資料庫GaussDB (for Cassandra) 資料庫治理 -- 大key與熱key問題的檢測與解決資料庫
- 大資料平臺架構設計探究大資料架構
- AzureStack混合雲大資料解決方案REST大資料
- 大資料解決方案-(基礎篇)大資料
- 公安大資料系統解決方案大資料
- JAVA效能優化思路探究Java優化
- 大模型視角下的因果推斷大模型
- 短視訊與演算法:抖音、快手的生態成因(附下載)演算法
- pdb受限解決思路