?
如何利用神經(jīng)網(wǎng)絡(luò)預(yù)測閃存尾端延遲的發(fā)生
由于用戶對低且穩(wěn)定的延遲(微秒級)的需求越來越大,人們對SSD的百分比延遲越來越關(guān)心,即SSD有99%的概率可以提供低且穩(wěn)定的延遲,但有1%的概率產(chǎn)生幾倍于正常情況的延遲,而這1%的高延遲被稱為尾端延遲。尾端延遲有什么影響?如何降低尾端延遲的影響?如何在存儲環(huán)境下利用神經(jīng)網(wǎng)絡(luò)?這些疑問,本文將一一解答。
尾端延遲與Hedged Request
百分比延遲
????也許你已經(jīng)查了維基百科中”百分比延遲“的定義,但我想對大多數(shù)人而言有點晦澀難懂,下面我將舉一個簡單的例子以幫助你理解。
????首先,我們先列舉出一系列收集到的延遲:
23,20,21,20,23,20,45,21,25,25
????對它們排序:
20,20,20,21,21,23,23,25,25,45
????接下來可以選擇前x%的延遲,例如假設(shè)我們想要得到50th百分比延遲,則選擇前5個延遲:
20,20,20,21,21
????然后選擇這一組延遲中最大的那個——即21——就是這一組延遲中的50th百分比延遲(也可以寫作p50),同理,p90是25。
尾端延遲
????尾端延遲就是百分比延遲中末尾的(通常p99之后)那些延遲??雌饋砦捕搜舆t占比并不多,但當(dāng)系統(tǒng)處理的請求達(dá)到10^6個數(shù)量級,可能足足有104個請求處理延遲遠(yuǎn)高于正常情況——你不會想成為那不幸的1%,對嗎?
????分析SSD的內(nèi)部行為后,本文作者認(rèn)為尾端延遲的產(chǎn)生源自SSD內(nèi)部日益復(fù)雜的內(nèi)部活動,如垃圾回收、負(fù)載均衡等,和用戶請求的沖突。為了降低尾端延遲或者降低尾端延遲的影響,業(yè)界提出的方案分為兩大類:
白盒子方案
此時SSD內(nèi)部的行為可知,通過改進(jìn)SSD內(nèi)部架構(gòu)來降低尾端延遲。這種方式無疑是直接而強(qiáng)有效的,但是不利于推廣到市場。
灰盒子方案
此時不需要修改SSD的內(nèi)部架構(gòu),但是需要修改上層的軟件棧。
黑盒子方案
以各種預(yù)測為代表,既不需要修改上層軟件棧,也不需要修改SSD內(nèi)部架構(gòu),是目前最流行的解決方案。其中一個經(jīng)典的方案是Hedged Request,它的原理和應(yīng)用環(huán)境將在下文中介紹。
Hedged Request
????為了保證數(shù)據(jù)安全、實現(xiàn)負(fù)載均衡,現(xiàn)代的存儲系統(tǒng)通常存在一定冗余,而多個不同的SSD的內(nèi)部行為同時和用戶請求產(chǎn)生沖突的概率非常低?;谶@樣的思考,Hedged ?Request將一個請求發(fā)給一個SSD后,若等待請求完成的時間超過了閾值,則重發(fā)請求到另一個可用的SSD。如下圖所示:
????然而,傳統(tǒng)Hedged Request中,快SSD需要等待一段時間(等待慢SSD處理的時間超過閾值)后才能處理請求,對于微秒級SSD而言,這個等待時間是致命的。如果可以學(xué)習(xí)SSD的特征,預(yù)測將要變慢的SSD而及時將請求重發(fā)到快SSD中,則可以節(jié)約出等待的時間,從而降低閃存組的尾端延遲——這就是LinnOS完成的工作,如下圖所示,用戶發(fā)送請求后,若經(jīng)過LinnOS網(wǎng)絡(luò)預(yù)測得知該SSD將變慢,則提前告知用戶重發(fā)請求,隨后請求將被送到下一個SSD,減少了Hedged Request中的等待時間。
LinnOS的三大挑戰(zhàn)
????設(shè)計LinnOS存在三大挑戰(zhàn),接下來將一一闡述。
對用戶輸出什么結(jié)果?
????需要輸出具體的延遲(如120μs)嗎?雖然這樣更靈活,但是一方面,對用戶而言,120μs或者125μs其實區(qū)別不大,另一方面,如此精確的輸出意味著準(zhǔn)確率低,并不劃算。那么如果輸出一個延遲范圍,如80~100μs、100~120μs呢?此時準(zhǔn)確率稍高了些,但不夠(僅60%-70%),處于區(qū)間交界處的延遲往往預(yù)測不準(zhǔn)確?;仡橦edged Request的原理,其實對用戶而言,知道SSD是”快“或者”慢“就足夠了!所以LinnOS使用簡單的二分類模型。
使用什么信息進(jìn)行預(yù)測?
????看起來一系列信息都和SSD快或慢有關(guān):讀寫請求?請求的塊內(nèi)偏移?長期的寫入歷史?然而,作者發(fā)現(xiàn)這些請求都對提高精確度沒有明顯幫助。首先,由于當(dāng)前SSD常有內(nèi)置寫緩存,寫之后的讀延遲常常沒有明顯提高,更為常見的其實是數(shù)據(jù)從緩存”沖“(flush)入SSD后,讀延遲會更高。其次,一組I/O請求會通過條帶均勻地寫入各個通道或者芯片,它們寫入同一個芯片的概率很低,所以塊內(nèi)偏移這個特征其實并不重要。最后,GC或者flush通常發(fā)生時間短,短期寫入歷史足矣預(yù)測。
????因此,可以使用SSD當(dāng)前I/O隊列長度來預(yù)測SSD快或者慢:一個直觀的感受是,當(dāng)I/O隊列較長時,SSD處理通常比較慢。但是這樣并不能體現(xiàn)SSD的內(nèi)部活動的發(fā)生,因此額外增加了歷史四條請求進(jìn)入SSD時的隊列長度和完成請求的時間。若某個請求進(jìn)入SSD時隊列短而完成請求的時間長,意味著SSD內(nèi)部行為可能和用戶請求沖突了。
如何最小化預(yù)測錯誤的影響?
????作者分析發(fā)現(xiàn),若將一個快的SSD預(yù)測為慢的從而錯誤地重發(fā)了,將帶來微秒級延遲,而若將一個慢的SSD預(yù)測為快,將帶來毫秒級延遲,比第一種情況嚴(yán)重許多,所以作者在訓(xùn)練時對第二種情況施加了更加嚴(yán)重的懲罰以減少它們的發(fā)生。此外,還補(bǔ)充了hedged request以減少預(yù)測失敗的損失。
實驗結(jié)果與總結(jié)
????作者上層使用了不同的軟件產(chǎn)生負(fù)載,底層使用同構(gòu)的消費(fèi)級SSD陣列或者異構(gòu)企業(yè)級SSD陣列測試它們的表現(xiàn),以讀延遲為指標(biāo)展示結(jié)果。總共比較了7種不同的方案:
Base:無優(yōu)化
Clone:同時發(fā)送兩份請求,選擇先返回的SSD的結(jié)果返回給用戶
Hedge95:等待p95之后重發(fā)請求
Hedge IP(inflection point):和上一個相比,使用針對負(fù)載優(yōu)化后的等待時間
HeurSim:隊列較長時重發(fā)請求
HeurAdv:隊列較長、且考慮歷史信息(和LinnOS一樣)后決定重發(fā)請求
LinnOS-Raw:沒有hedged補(bǔ)償?shù)腖innOS
LinnOS+HL:最終的LinnOS方案
實驗結(jié)果如下圖:
審核編輯:劉清
評論
查看更多