0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

從內(nèi)核中NVMe IO框架來看其中存在的問題

Linux閱碼場 ? 來源:lp ? 2019-04-15 13:59 ? 次閱讀

NVMeSSD具有高性能、低時(shí)延等優(yōu)點(diǎn),是目前存儲行業(yè)的研究熱點(diǎn)之一,但在光鮮的性能下也同樣存在一些沒有廣為人知的問題,而這些問題其實(shí)對于一個(gè)生產(chǎn)系統(tǒng)而言至關(guān)重要,例如:

QoS無法做到100%保證;

讀寫混合情況下,與單獨(dú)讀相比,性能下降嚴(yán)重,且讀長尾延遲比較嚴(yán)重;

所以如何利用好NVMe盤的性能,并更好的為業(yè)務(wù)服務(wù),我們需要從硬件,Linux內(nèi)核等多個(gè)角度去剖析和解決。

從內(nèi)核中NVMe IO框架來看其中存在的問題

當(dāng)前Linux內(nèi)核中對NVMeSSD的訪問是通過MQ框架來實(shí)現(xiàn)的,接入NVMe驅(qū)動后直接略過IO調(diào)度器,具體實(shí)現(xiàn)上來說是從blocklayer中的通用塊層回調(diào)make_request從而打通上下層IO通路。示意圖如下,這里面有幾個(gè)關(guān)鍵的點(diǎn):

IO發(fā)送過程

MQ的框架提升性能最主要的將鎖的粒度按照硬件隊(duì)列進(jìn)行拆分,并與底層SSD的隊(duì)列進(jìn)行綁定,理想的情況每一個(gè)CPU都有對應(yīng)的硬件發(fā)送SQ與響應(yīng)CQ,這樣可以并發(fā)同時(shí)彼此之前無影響。按照NVMeSPEC協(xié)議中的標(biāo)準(zhǔn),硬件最多支持64K個(gè)隊(duì)列,所以理想情況下硬件隊(duì)列個(gè)數(shù)將不會是我們需要擔(dān)心的地方。但是實(shí)際情況又如何呢?由于硬件隊(duì)列的增加會給NVMeSSD帶來功耗的增加,所以不同的廠商在設(shè)計(jì)硬件隊(duì)列個(gè)數(shù)時(shí)的考量是不同的,比如intelP3600支持32個(gè)隊(duì)列,intel最新的P4500支持16384個(gè),但是SUMSUNGPM963卻只支持到8個(gè)。那么當(dāng)CPU的個(gè)數(shù)超過硬件的隊(duì)列個(gè)數(shù),就會出現(xiàn)多個(gè)CPU共用一個(gè)硬件隊(duì)列的情況,對性能就會產(chǎn)生影響。

下面使用SUMSUNGPM963做一個(gè)簡單的測試:

也就是整個(gè)IOPS可以達(dá)到50w

如果使用同一個(gè)硬件隊(duì)列

整個(gè)IOPS只有44w,性能下降12%,主要原因是多個(gè)CPU共用硬件隊(duì)列進(jìn)行發(fā)送的時(shí)候會有自旋鎖爭搶的影響。所以對于共用硬件隊(duì)列的情況下,如何綁定CPU是需要根據(jù)業(yè)務(wù)的特點(diǎn)來確定的。

IO響應(yīng)過程

IO響應(yīng)過程中最主要問題是中斷的balance,由于默認(rèn)linux中并沒有對NVMe的中斷進(jìn)行有效的綁定,所以不同的綁定策略會帶來截然不同的性能數(shù)據(jù)。不過在我們的實(shí)際測試中,雖然我們沒有做中斷的綁定,但是貌似不管是性能還是穩(wěn)定性的下降并沒有那么嚴(yán)重,什么原因呢?根據(jù)我們的分析,這里面最主要的原因是(后面也會提到),我們并沒有大壓力的使用NVMe盤,所以實(shí)際的應(yīng)用場景壓力以及隊(duì)列深度并不大。

從應(yīng)用本身的IO Pattern來看使用NVMe問題

我們在評測一個(gè)NVMeSSD的性能的時(shí)候,往往都是通過benchmark工具,例如見1,見2。

然而這些測試的結(jié)果與業(yè)務(wù)實(shí)際使用NVMeSSD看到的性能相比差距很大。原因是因?yàn)檫@些性能測試存在兩個(gè)比較大的誤區(qū),因而并不能反映生產(chǎn)系統(tǒng)的真實(shí)情況。

1. 片面夸大了NVMe盤的性能

從上面兩篇文章中的測試中我們可以看到,大多數(shù)壓測中使用的隊(duì)列深度為128,并且是用libaio這樣的異步IO模式來下發(fā)IO。但是在實(shí)際應(yīng)用場景中很少有這么大的隊(duì)列深度。在這種場景下,根據(jù)“色子效應(yīng)”,并不會將NVMe盤的并發(fā)性能充分發(fā)揮出來。

2. 低估了NVMe的長尾延遲

然而在另外一些場景下,隊(duì)列深度又會非常高(比如到1024甚至更高),在這種情況下NVMeSSD帶來的QoS長尾延遲影響比上面的benchmark的測試又嚴(yán)重得多。

所以綜合起來看,這種評測選擇了一個(gè)看上去沒啥大用的場景做了測試,所以得出的結(jié)果也對我們實(shí)際的應(yīng)用基本沒有參考價(jià)值。那么問題出在什么地方么?

問題分析

首先讓我們再次強(qiáng)調(diào)一下一般評測文章中benchmark進(jìn)行的測試場景的特點(diǎn):

大多是fio工具,開啟libaio引擎增加IO壓力

隊(duì)列深度到128或者256

在這種場景下確實(shí)基本都可以將NVMe盤的壓力打滿。

在展開分析問題的原因之前,我們先看看Linux內(nèi)核的IO棧。

在實(shí)際應(yīng)用中,VFS提供給應(yīng)用的接口,從IO的特點(diǎn)來分類,大致上可以分為兩類:directIO與bufferIO。使用directIO的業(yè)務(wù)大多在應(yīng)用本身就已經(jīng)做了一層cache,不依賴OS提供的pagecache。其他的情況大多使用的都是bufferIO。linuxkernel中的blocklayer通過REQ_SYNC與~REQ_SYNC這兩種不同的標(biāo)志來區(qū)分這兩類IO。大家常用的directIO這個(gè)類型,內(nèi)核要保證這次IO操作的數(shù)據(jù)落盤,并且當(dāng)響應(yīng)返回以后,應(yīng)用程序才能夠認(rèn)為這次IO操作是完成的。所以是使用了這里的REQ_SYNC標(biāo)志,而對應(yīng)的bufferIO,則大量使用了~REQ_SYNC的標(biāo)志。讓我們一個(gè)一個(gè)看過去。

direct IO

由于在實(shí)際使用方式中AIO還不夠成熟,所以大多使用directIO。但是directIO是一種SYNC模式,并且完全達(dá)不到測試用例中128路并發(fā)AIO的效果。這主要兩個(gè)方面原因:

direct io在下發(fā)過程中可能會使用文件粒度的鎖inode->i_mutex進(jìn)行互斥。

前面說的IO SYNC模式

也就是說,我們很難通過directIO來達(dá)到壓滿NVMe盤的目的。如果一定要打滿NVMe盤,那么一方面要提高進(jìn)程并發(fā),另外一方面還要提高多進(jìn)程多文件的并發(fā)。而這是生產(chǎn)系統(tǒng)中很難滿足的。

buffer IO

我們再來看看bufferIO的特點(diǎn)。下面我使用了比較簡單的fio通過bufferIO的模式下發(fā),而且通過rate限速,我們發(fā)現(xiàn)平均下來每秒的數(shù)據(jù)量不到100MB,整個(gè)IO的特點(diǎn)如下:

抓取了下submit_bio在每秒的調(diào)用次數(shù)并分析可以得出,bufferIO在下刷的時(shí)候并不會考慮QD的多少,而是類似aio那樣,kworker將需要下發(fā)的臟頁都會bio形式下發(fā),而且不需要等待某些bio返回。注意這里面有一個(gè)細(xì)節(jié)從qusize觀察到IO最大值986,并沒有達(dá)到百K,或者幾十K,這個(gè)原因是由本身MQ的框架中tag機(jī)制nr_request決定,目前單Q設(shè)置默認(rèn)值一般為1024??傊産ufferIO這樣特點(diǎn)的結(jié)果就是突發(fā)量的高iops的寫入,bufferIO對于應(yīng)用程序來說是不可見的,因?yàn)檫@是linuxkernel的本身的刷臟頁行為。但是它帶給應(yīng)用的影響確實(shí)可見的,筆者曾經(jīng)總結(jié)過異步IO的延時(shí)對長尾的影響,如下圖所示,分別是bufferIO與directIO在相同帶寬下延時(shí)表現(xiàn),可以看出這延遲長尾比我們簡單的通過fiobenchmark測試嚴(yán)重的多,特別是盤開始做GC的時(shí)候,抖動更加嚴(yán)重;而且隨著盤的容量用著越來越多,GC的影響越來越大,長尾的影響也是越來越嚴(yán)重。

在HDD的時(shí)代上面的問題同樣會存在,但是為什么沒有那么嚴(yán)重,原因主要是HDD大多使用CFQ調(diào)度器,其中一個(gè)特性是同步、異步IO隊(duì)列分離。并且在調(diào)度過程中同步優(yōu)先級比較高,在調(diào)度搶占、時(shí)間片等都是同步優(yōu)先。

解決問題

前面描述了使用NVMe硬盤的嚴(yán)重性,下面介紹一下如何解決這些問題。(1)MQ綁定的問題,需要根據(jù)當(dāng)前業(yè)務(wù)的特點(diǎn),如果硬件的隊(duì)列小于當(dāng)前CPU的個(gè)數(shù),盡量讓核心業(yè)務(wù)上跑的進(jìn)程分散在綁定不同硬件隊(duì)列的CPU上,防止IO壓力大的時(shí)候鎖資源的競爭。

(2)中斷綁定CPU,建議下發(fā)的SQ的CPU與響應(yīng)的CQ的CPU保持一致,這樣各自CPU來處理自己的事情,互相業(yè)務(wù)與中斷不干擾。

(3)解決directIO狀態(tài)下長尾延遲,因?yàn)殚L尾延遲是本身NVMeSSDController帶來,所以解決這個(gè)問題還是要從控制器入手,使用的方法有WRR(WeightRoundRobin),這個(gè)功能在當(dāng)前主流廠商的最新的NVMeSSD中已經(jīng)支持。

(4)解決bufferIO狀態(tài)下長尾延遲,可以通過控制NVMeSSD處理的QD來解決,使用的NVME多隊(duì)列IO調(diào)度器,充分利用了MQ框架,根據(jù)同步寫、讀延遲動態(tài)調(diào)整異步IO的隊(duì)列,很好的解決bufferio帶來的長尾延遲。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    10813

    瀏覽量

    210883
  • Linux
    +關(guān)注

    關(guān)注

    87

    文章

    11215

    瀏覽量

    208748
  • nvme
    +關(guān)注

    關(guān)注

    0

    文章

    214

    瀏覽量

    22567

原文標(biāo)題:你所不知道到的NVMe

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏

    評論

    相關(guān)推薦

    Xilinx FPGA NVMe Host Controller IP,NVMe主機(jī)控制器

    ,實(shí)現(xiàn)必須以及可選的NVMe Admin Command Set和NVM Command Set,實(shí)現(xiàn)對PCIe SSD的復(fù)位/斷電管理、IO(Page)讀寫、DMA讀寫和數(shù)據(jù)擦除功能,提供用戶一個(gè)
    發(fā)表于 02-21 10:16

    Xilinx FPGA高性能NVMe SSD主機(jī)控制器,NVMe Host Controller IP

    ,實(shí)現(xiàn)必須以及可選的NVMe Admin Command Set和NVM Command Set,實(shí)現(xiàn)對PCIe SSD的復(fù)位/斷電/SMART/Error Information管理、IO(Page
    發(fā)表于 03-27 17:23

    高性能NVMe主機(jī)控制器,Xilinx FPGA NVMe Host Accelerator IP

    ,實(shí)現(xiàn)必須以及可選的NVMe Admin Command Set和NVM Command Set,實(shí)現(xiàn)對PCIe SSD的復(fù)位/斷電/SMART/Error Information管理、IO(Page
    發(fā)表于 04-10 22:55

    ThreadX內(nèi)核的IAR方式移植和設(shè)計(jì)框架

    了解后再來看,這樣將事半功倍。但是本章的工程模板框架一定要學(xué)習(xí)。雖然本章節(jié)是以我們開發(fā)板為例進(jìn)行移植的,但是教會大家如何移植到自己的板子上以及移植過程的..
    發(fā)表于 08-10 06:47

    RK3399 Android7.1系統(tǒng)WiFi的SDIO和電源框架介紹

    1、WiFi的SDIO和電源框架  Platform: RK3399  OS: Android 7.1  Kernel: v4.4.83  框架:  引用網(wǎng)友一張框圖,畫得很不錯(cuò)  
    發(fā)表于 11-30 17:47

    LX2160用RT內(nèi)核檢測不到NVME怎么解決?

    GB (976773168 x 512) 在下一階段,nvme 磁盤不見了。附加了帶/不帶 rt 內(nèi)核的引導(dǎo)日志
    發(fā)表于 03-15 08:19

    Nvme硬盤掛載失敗如何解決?

    內(nèi)核啟動時(shí)卡住,然后提示 nvme nvme0: I/O 401 QID 4 timeout, completion polled,硬盤型號為:致態(tài) PC005 Active 512GB
    發(fā)表于 09-12 06:35

    網(wǎng)絡(luò)IO套路分享

    無情的掛起,等待內(nèi)核完成操作,因?yàn)榇藭r(shí)的內(nèi)核可能將CPU時(shí)間切換到了其他需要的進(jìn)程,在我們的應(yīng)用程序看來感覺被卡主(阻塞)了。 阻塞IO 傳統(tǒng)阻塞
    的頭像 發(fā)表于 10-13 14:52 ?1877次閱讀
    網(wǎng)絡(luò)<b class='flag-5'>IO</b>套路分享

    如何使用Linux內(nèi)核實(shí)現(xiàn)USB驅(qū)動程序框架

    Linux內(nèi)核提供了完整的USB驅(qū)動程序框架。USB總線采用樹形結(jié)構(gòu),在一條總線上只能有唯一的主機(jī)設(shè)備。 Linux內(nèi)核主機(jī)和設(shè)備兩個(gè)角度觀察USB總線結(jié)構(gòu)。本節(jié)介紹 Linux
    發(fā)表于 11-06 17:59 ?20次下載
    如何使用Linux<b class='flag-5'>內(nèi)核</b>實(shí)現(xiàn)USB驅(qū)動程序<b class='flag-5'>框架</b>

    NVMe over Fabrics的優(yōu)勢是什么?

    NVMe- oF字面上來看是網(wǎng)絡(luò)上的NVMe協(xié)議的擴(kuò)展,其擴(kuò)展范圍遠(yuǎn)遠(yuǎn)超出了目前搭載SSD的服務(wù)器。NVMe早在2011年就出現(xiàn)了,而fa
    的頭像 發(fā)表于 01-14 09:12 ?5196次閱讀

    Linux內(nèi)核開發(fā)框架學(xué)習(xí)資料匯總

    Linux內(nèi)核開發(fā)框架學(xué)習(xí)資料匯總
    發(fā)表于 06-17 09:29 ?24次下載

    OpenHarmony工作委員會PMC委員萬承臻帶你領(lǐng)略O(shè)penHarmony3.1內(nèi)核框架

    OpenHarmony工作委員會PMC委員萬承臻帶你領(lǐng)略O(shè)penHarmony3.1內(nèi)核框架 OpenHarmony各版本不斷迭代不斷完善;今天以“共建新技術(shù)、開拓新領(lǐng)域”作為
    的頭像 發(fā)表于 04-25 17:12 ?2276次閱讀
    OpenHarmony工作委員會PMC委員萬承臻帶你領(lǐng)略O(shè)penHarmony3.1<b class='flag-5'>從</b><b class='flag-5'>內(nèi)核</b>到<b class='flag-5'>框架</b>

    信號驅(qū)動IO與異步IO的區(qū)別

    , 是開始處理IO, 這個(gè)時(shí)候還是存在阻塞的,將數(shù)據(jù)內(nèi)核態(tài)拷貝進(jìn)入到用戶態(tài)的過程至少是阻塞住的 (應(yīng)用程序?qū)?shù)據(jù)
    的頭像 發(fā)表于 11-08 15:32 ?976次閱讀
    信號驅(qū)動<b class='flag-5'>IO</b>與異步<b class='flag-5'>IO</b>的區(qū)別

    linux異步io框架iouring應(yīng)用

    Linux內(nèi)核5.1支持了新的異步IO框架iouring,由Block IO大神也即Fio作者Jens Axboe開發(fā),意在提供一套公用的網(wǎng)絡(luò)和磁盤異步
    的頭像 發(fā)表于 11-08 15:39 ?631次閱讀
    linux異步<b class='flag-5'>io</b><b class='flag-5'>框架</b>iouring應(yīng)用

    異步IO框架iouring介紹

    前言 Linux內(nèi)核5.1支持了新的異步IO框架iouring,由Block IO大神也即Fio作者Jens Axboe開發(fā),意在提供一套公用的網(wǎng)絡(luò)和磁盤異步
    的頭像 發(fā)表于 11-09 09:30 ?2120次閱讀
    異步<b class='flag-5'>IO</b><b class='flag-5'>框架</b>iouring介紹