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