當(dāng)前位置:首頁(yè) > 公眾號(hào)精選 > 小林coding
[導(dǎo)讀]磁盤可以說(shuō)是計(jì)算機(jī)系統(tǒng)最慢的硬件之一,讀寫速度相差內(nèi)存10倍以上,所以針對(duì)優(yōu)化磁盤的技術(shù)非常的多,比如零拷貝、直接I/O、異步I/O等,這些優(yōu)化的目的就是為了提高系統(tǒng)的吞吐量,另外操作系統(tǒng)內(nèi)核中的磁盤高速緩存區(qū),可以有效的減少磁盤的訪問(wèn)次數(shù)。本文以「文件傳輸」作為切入點(diǎn),來(lái)分析I/O工作方式以及如何優(yōu)化傳輸文件的性能。


前言

磁盤可以說(shuō)是計(jì)算機(jī)系統(tǒng)最慢的硬件之一,讀寫速度相差內(nèi)存 10 倍以上,所以針對(duì)優(yōu)化磁盤的技術(shù)非常的多,比如零拷貝、直接 I/O、異步 I/O 等等,這些優(yōu)化的目的就是為了提高系統(tǒng)的吞吐量,另外操作系統(tǒng)內(nèi)核中的磁盤高速緩存區(qū),可以有效的減少磁盤的訪問(wèn)次數(shù)。

這次,我們就以「文件傳輸」作為切入點(diǎn),來(lái)分析 I/O 工作方式,以及如何優(yōu)化傳輸文件的性能。


正文

為什么要有 DMA 技術(shù)?

在沒(méi)有 DMA 技術(shù)前,I/O 的過(guò)程是這樣的:

  • CPU 發(fā)出對(duì)應(yīng)的指令給磁盤控制器,然后返回;

  • 磁盤控制器收到指令后,于是就開(kāi)始準(zhǔn)備數(shù)據(jù),會(huì)把數(shù)據(jù)放入到磁盤控制器的內(nèi)部緩沖區(qū)中,然后產(chǎn)生一個(gè)中斷;

  • CPU 收到中斷信號(hào)后,停下手頭的工作,接著把磁盤控制器的緩沖區(qū)的數(shù)據(jù)一次一個(gè)字節(jié)地讀進(jìn)自己的寄存器,然后再把寄存器里的數(shù)據(jù)寫入到內(nèi)存,而在數(shù)據(jù)傳輸?shù)钠陂g CPU 是無(wú)法執(zhí)行其他任務(wù)的。

為了方便你理解,我畫了一副圖:

可以看到,整個(gè)數(shù)據(jù)的傳輸過(guò)程,都要需要 CPU 親自參與搬運(yùn)數(shù)據(jù)的過(guò)程,而且這個(gè)過(guò)程,CPU 是不能做其他事情的。

簡(jiǎn)單的搬運(yùn)幾個(gè)字符數(shù)據(jù)那沒(méi)問(wèn)題,但是如果我們用千兆網(wǎng)卡或者硬盤傳輸大量數(shù)據(jù)的時(shí)候,都用 CPU 來(lái)搬運(yùn)的話,肯定忙不過(guò)來(lái)。

計(jì)算機(jī)科學(xué)家們發(fā)現(xiàn)了事情的嚴(yán)重性后,于是就發(fā)明了 DMA 技術(shù),也就是直接內(nèi)存訪問(wèn)(Direct Memory Access?技術(shù)。

什么是 DMA 技術(shù)?簡(jiǎn)單理解就是,在進(jìn)行 I/O 設(shè)備和內(nèi)存的數(shù)據(jù)傳輸?shù)臅r(shí)候,數(shù)據(jù)搬運(yùn)的工作全部交給 DMA 控制器,而 CPU 不再參與任何與數(shù)據(jù)搬運(yùn)相關(guān)的事情,這樣 CPU 就可以去處理別的事務(wù)。

那使用 DMA 控制器進(jìn)行數(shù)據(jù)傳輸?shù)倪^(guò)程究竟是什么樣的呢?下面我們來(lái)具體看看。

具體過(guò)程:

  • 用戶進(jìn)程調(diào)用 read 方法,向操作系統(tǒng)發(fā)出 I/O 請(qǐng)求,請(qǐng)求讀取數(shù)據(jù)到自己的內(nèi)存緩沖區(qū)中,進(jìn)程進(jìn)入阻塞狀態(tài);

  • 操作系統(tǒng)收到請(qǐng)求后,進(jìn)一步將 I/O 請(qǐng)求發(fā)送 DMA,然后讓 CPU 執(zhí)行其他任務(wù);

  • DMA 進(jìn)一步將 I/O 請(qǐng)求發(fā)送給磁盤;

  • 磁盤收到 DMA 的 I/O 請(qǐng)求,把數(shù)據(jù)從磁盤讀取到磁盤控制器的緩沖區(qū)中,當(dāng)磁盤控制器的緩沖區(qū)被讀滿后,向 DMA 發(fā)起中斷信號(hào),告知自己緩沖區(qū)已滿;

  • DMA 收到磁盤的信號(hào),將磁盤控制器緩沖區(qū)中的數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)中,此時(shí)不占用 CPU,CPU 可以執(zhí)行其他任務(wù);

  • 當(dāng) DMA 讀取了足夠多的數(shù)據(jù),就會(huì)發(fā)送中斷信號(hào)給 CPU;

  • CPU 收到 DMA 的信號(hào),知道數(shù)據(jù)已經(jīng)準(zhǔn)備好,于是將數(shù)據(jù)從內(nèi)核拷貝到用戶空間,系統(tǒng)調(diào)用返回;

可以看到, 整個(gè)數(shù)據(jù)傳輸?shù)倪^(guò)程,CPU 不再參與數(shù)據(jù)搬運(yùn)的工作,而是全程由 DMA 完成,但是 CPU 在這個(gè)過(guò)程中也是必不可少的,因?yàn)閭鬏斒裁磾?shù)據(jù),從哪里傳輸?shù)侥睦?,都需?CPU 來(lái)告訴 DMA 控制器。

早期 DMA 只存在在主板上,如今由于 I/O 設(shè)備越來(lái)越多,數(shù)據(jù)傳輸?shù)男枨笠膊槐M相同,所以每個(gè) I/O 設(shè)備里面都有自己的 DMA 控制器。


傳統(tǒng)的文件傳輸有多糟糕?

如果服務(wù)端要提供文件傳輸?shù)墓δ?,我們能想到的最?jiǎn)單的方式是:將磁盤上的文件讀取出來(lái),然后通過(guò)網(wǎng)絡(luò)協(xié)議發(fā)送給客戶端。

傳統(tǒng) I/O 的工作方式是,數(shù)據(jù)讀取和寫入是從用戶空間到內(nèi)核空間來(lái)回復(fù)制,而內(nèi)核空間的數(shù)據(jù)是通過(guò)操作系統(tǒng)層面的 I/O 接口從磁盤讀取或?qū)懭搿?/p>

代碼通常如下,一般會(huì)需要兩個(gè)系統(tǒng)調(diào)用:

read(file,?tmp_buf,?len);
write(socket,?tmp_buf,?len);

代碼很簡(jiǎn)單,雖然就兩行代碼,但是這里面發(fā)生了不少的事情。

首先,期間共發(fā)生了 4 次用戶態(tài)與內(nèi)核態(tài)的上下文切換,因?yàn)榘l(fā)生了兩次系統(tǒng)調(diào)用,一次是?read()?,一次是?write(),每次系統(tǒng)調(diào)用都得先從用戶態(tài)切換到內(nèi)核態(tài),等內(nèi)核完成任務(wù)后,再?gòu)膬?nèi)核態(tài)切換回用戶態(tài)。

上下文切換到成本并不小,一次切換需要耗時(shí)幾十納秒到幾微秒,雖然時(shí)間看上去很短,但是在高并發(fā)的場(chǎng)景下,這類時(shí)間容易被累積和放大,從而影響系統(tǒng)的性能。

其次,還發(fā)生了 4 次數(shù)據(jù)拷貝,其中兩次是 DMA 的拷貝,另外兩次則是通過(guò) CPU 拷貝的,下面說(shuō)一下這個(gè)過(guò)程:

  • 第一次拷貝,把磁盤上的數(shù)據(jù)拷貝到操作系統(tǒng)內(nèi)核的緩沖區(qū)里,這個(gè)拷貝的過(guò)程是通過(guò) DMA 搬運(yùn)的。

  • 第二次拷貝,把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到用戶的緩沖區(qū)里,于是我們應(yīng)用程序就可以使用這部分?jǐn)?shù)據(jù)了,這個(gè)拷貝到過(guò)程是由 CPU 完成的。

  • 第三次拷貝,把剛才拷貝到用戶的緩沖區(qū)里的數(shù)據(jù),再拷貝到內(nèi)核的 socket 的緩沖區(qū)里,這個(gè)過(guò)程依然還是由 CPU 搬運(yùn)的。

  • 第四次拷貝,把內(nèi)核的 socket 緩沖區(qū)里的數(shù)據(jù),拷貝到網(wǎng)卡的緩沖區(qū)里,這個(gè)過(guò)程又是由 DMA 搬運(yùn)的。

我們回過(guò)頭看這個(gè)文件傳輸?shù)倪^(guò)程,我們只是搬運(yùn)一份數(shù)據(jù),結(jié)果卻搬運(yùn)了 4 次,過(guò)多的數(shù)據(jù)拷貝無(wú)疑會(huì)消耗 CPU 資源,大大降低了系統(tǒng)性能。

這種簡(jiǎn)單又傳統(tǒng)的文件傳輸方式,存在冗余的上文切換和數(shù)據(jù)拷貝,在高并發(fā)系統(tǒng)里是非常糟糕的,多了很多不必要的開(kāi)銷,會(huì)嚴(yán)重影響系統(tǒng)性能。

所以,要想提高文件傳輸?shù)男阅?,就需要減少「用戶態(tài)與內(nèi)核態(tài)的上下文切換」和「內(nèi)存拷貝」的次數(shù)。


如何優(yōu)化文件傳輸?shù)男阅埽?/span>

先來(lái)看看,如何減少「用戶態(tài)與內(nèi)核態(tài)的上下文切換」的次數(shù)呢?

讀取磁盤數(shù)據(jù)的時(shí)候,之所以要發(fā)生上下文切換,這是因?yàn)橛脩艨臻g沒(méi)有權(quán)限操作磁盤或網(wǎng)卡,內(nèi)核的權(quán)限最高,這些操作設(shè)備的過(guò)程都需要交由操作系統(tǒng)內(nèi)核來(lái)完成,所以一般要通過(guò)內(nèi)核去完成某些任務(wù)的時(shí)候,就需要使用操作系統(tǒng)提供的系統(tǒng)調(diào)用函數(shù)。

而一次系統(tǒng)調(diào)用必然會(huì)發(fā)生 2 次上下文切換:首先從用戶態(tài)切換到內(nèi)核態(tài),當(dāng)內(nèi)核執(zhí)行完任務(wù)后,再切換回用戶態(tài)交由進(jìn)程代碼執(zhí)行。

所以,要想減少上下文切換到次數(shù),就要減少系統(tǒng)調(diào)用的次數(shù)。

再來(lái)看看,如何減少「數(shù)據(jù)拷貝」的次數(shù)?

在前面我們知道了,傳統(tǒng)的文件傳輸方式會(huì)歷經(jīng) 4 次數(shù)據(jù)拷貝,而且這里面,「從內(nèi)核的讀緩沖區(qū)拷貝到用戶的緩沖區(qū)里,再?gòu)挠脩舻木彌_區(qū)里拷貝到 socket 的緩沖區(qū)里」,這個(gè)過(guò)程是沒(méi)有必要的。

因?yàn)槲募鬏數(shù)膽?yīng)用場(chǎng)景中,在用戶空間我們并不會(huì)對(duì)數(shù)據(jù)「再加工」,所以數(shù)據(jù)實(shí)際上可以不用搬運(yùn)到用戶空間,因此用戶的緩沖區(qū)是沒(méi)有必要存在的。


如何實(shí)現(xiàn)零拷貝?

零拷貝技術(shù)實(shí)現(xiàn)的方式通常有 2 種:

  • mmap + write

  • sendfile

下面就談一談,它們是如何減少「上下文切換」和「數(shù)據(jù)拷貝」的次數(shù)。

mmap + write

在前面我們知道,read()?系統(tǒng)調(diào)用的過(guò)程中會(huì)把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到用戶的緩沖區(qū)里,于是為了減少這一步開(kāi)銷,我們可以用?mmap()?替換?read()?系統(tǒng)調(diào)用函數(shù)。

buf?=?mmap(file,?len);
write(sockfd,?buf,?len);

mmap()?系統(tǒng)調(diào)用函數(shù)會(huì)直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)「映射」到用戶空間,這樣,操作系統(tǒng)內(nèi)核與用戶空間就不需要再進(jìn)行任何的數(shù)據(jù)拷貝操作。

具體過(guò)程如下:

  • 應(yīng)用進(jìn)程調(diào)用了?mmap()?后,DMA 會(huì)把磁盤的數(shù)據(jù)拷貝到內(nèi)核的緩沖區(qū)里。接著,應(yīng)用進(jìn)程跟操作系統(tǒng)內(nèi)核「共享」這個(gè)緩沖區(qū);

  • 應(yīng)用進(jìn)程再調(diào)用?write(),操作系統(tǒng)直接將內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到 socket 緩沖區(qū)中,這一切都發(fā)生在內(nèi)核態(tài),由 CPU 來(lái)搬運(yùn)數(shù)據(jù);

  • 最后,把內(nèi)核的 socket 緩沖區(qū)里的數(shù)據(jù),拷貝到網(wǎng)卡的緩沖區(qū)里,這個(gè)過(guò)程是由 DMA 搬運(yùn)的。

我們可以得知,通過(guò)使用?mmap()?來(lái)代替?read(), 可以減少一次數(shù)據(jù)拷貝的過(guò)程。

但這還不是最理想的零拷貝,因?yàn)槿匀恍枰ㄟ^(guò) CPU 把內(nèi)核緩沖區(qū)的數(shù)據(jù)拷貝到 socket 緩沖區(qū)里,而且仍然需要 4 次上下文切換,因?yàn)橄到y(tǒng)調(diào)用還是 2 次。

sendfile

在 Linux 內(nèi)核版本 2.1 中,提供了一個(gè)專門發(fā)送文件的系統(tǒng)調(diào)用函數(shù)?sendfile(),函數(shù)形式如下:

#include?
ssize_t?sendfile(int?out_fd,?int?in_fd,?off_t?*offset,?size_t?count);

它的前兩個(gè)參數(shù)分別是目的端和源端的文件描述符,后面兩個(gè)參數(shù)是源端的偏移量和復(fù)制數(shù)據(jù)的長(zhǎng)度,返回值是實(shí)際復(fù)制數(shù)據(jù)的長(zhǎng)度。

首先,它可以替代前面的?read()?和?write()?這兩個(gè)系統(tǒng)調(diào)用,這樣就可以減少一次系統(tǒng)調(diào)用,也就減少了 2 次上下文切換的開(kāi)銷。

其次,該系統(tǒng)調(diào)用,可以直接把內(nèi)核緩沖區(qū)里的數(shù)據(jù)拷貝到 socket 緩沖區(qū)里,不再拷貝到用戶態(tài),這樣就只有 2 次上下文切換,和 3 次數(shù)據(jù)拷貝。如下圖:

但是這還不是真正的零拷貝技術(shù),如果網(wǎng)卡支持 SG-DMA(The Scatter-Gather Direct Memory Access)技術(shù)(和普通的 DMA 有所不同),我們可以進(jìn)一步減少通過(guò) CPU 把內(nèi)核緩沖區(qū)里的數(shù)據(jù)拷貝到 socket 緩沖區(qū)的過(guò)程。

你可以在你的 Linux 系統(tǒng)通過(guò)下面這個(gè)命令,查看網(wǎng)卡是否支持 scatter-gather 特性:

$?ethtool?-k?eth0?|?grep?scatter-gather
scatter-gather:?on

于是,從 Linux 內(nèi)核?2.4?版本開(kāi)始起,對(duì)于支持網(wǎng)卡支持 SG-DMA 技術(shù)的情況下,?sendfile()?系統(tǒng)調(diào)用的過(guò)程發(fā)生了點(diǎn)變化,具體過(guò)程如下:

  • 第一步,通過(guò) DMA 將磁盤上的數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)里;

  • 第二步,緩沖區(qū)描述符和數(shù)據(jù)長(zhǎng)度傳到 socket 緩沖區(qū),這樣網(wǎng)卡的 SG-DMA 控制器就可以直接將內(nèi)核緩存中的數(shù)據(jù)拷貝到網(wǎng)卡的緩沖區(qū)里,此過(guò)程不需要將數(shù)據(jù)從操作系統(tǒng)內(nèi)核緩沖區(qū)拷貝到 socket 緩沖區(qū)中,這樣就減少了一次數(shù)據(jù)拷貝;

所以,這個(gè)過(guò)程之中,只進(jìn)行了 2 次數(shù)據(jù)拷貝,如下圖:

這就是所謂的零拷貝(Zero-copy)技術(shù),因?yàn)槲覀儧](méi)有在內(nèi)存層面去拷貝數(shù)據(jù),也就是說(shuō)全程沒(méi)有通過(guò) CPU 來(lái)搬運(yùn)數(shù)據(jù),所有的數(shù)據(jù)都是通過(guò) DMA 來(lái)進(jìn)行傳輸?shù)摹?/strong>

零拷貝技術(shù)的文件傳輸方式相比傳統(tǒng)文件傳輸?shù)姆绞?,減少了 2 次上下文切換和數(shù)據(jù)拷貝次數(shù),只需要 2 次上下文切換和數(shù)據(jù)拷貝次數(shù),就可以完成文件的傳輸,而且 2 次的數(shù)據(jù)拷貝過(guò)程,都不需要通過(guò) CPU,2 次都是由 DMA 來(lái)搬運(yùn)。

所以,總體來(lái)看,零拷貝技術(shù)可以把文件傳輸?shù)男阅芴岣咧辽僖槐兑陨?/strong>。

使用零拷貝技術(shù)的項(xiàng)目

事實(shí)上,Kafka 這個(gè)開(kāi)源項(xiàng)目,就利用了「零拷貝」技術(shù),從而大幅提升了 I/O 的吞吐率,這也是 Kafka 在處理海量數(shù)據(jù)為什么這么快的原因之一。

如果你追溯 Kafka 文件傳輸?shù)拇a,你會(huì)發(fā)現(xiàn),最終它調(diào)用了 Java NIO 庫(kù)里的?transferTo方法:

@Overridepublic?
long?transferFrom(FileChannel?fileChannel,?long?position,?long?count)?throws?IOException?{?
????return?fileChannel.transferTo(position,?count,?socketChannel);
}

如果 Linux 系統(tǒng)支持?sendfile()?系統(tǒng)調(diào)用,那么?transferTo()?實(shí)際上最后就會(huì)使用到?sendfile()?系統(tǒng)調(diào)用函數(shù)。

曾經(jīng)有大佬專門寫過(guò)程序測(cè)試過(guò),在同樣的硬件條件下,傳統(tǒng)文件傳輸和零拷拷貝文件傳輸?shù)男阅懿町?,你可以看到下面這張測(cè)試數(shù)據(jù)圖,使用了零拷貝能夠縮短?65%?的時(shí)間,大幅度提升了機(jī)器傳輸數(shù)據(jù)的吞吐量。

數(shù)據(jù)來(lái)源于:https://developer.ibm.com/articles/j-zerocopy/

另外,Nginx 也支持零拷貝技術(shù),一般默認(rèn)是開(kāi)啟零拷貝技術(shù),這樣有利于提高文件傳輸?shù)男?,是否開(kāi)啟零拷貝技術(shù)的配置如下:

http?{
...
????sendfile?on
...
}

sendfile 配置的具體意思:?

  • 設(shè)置為 on 表示,使用零拷貝技術(shù)來(lái)傳輸文件:sendfile ,這樣只需要 2 次上下文切換,和 2 次數(shù)據(jù)拷貝。

  • 設(shè)置為 off 表示,使用傳統(tǒng)的文件傳輸技術(shù):read + write,這時(shí)就需要 4 次上下文切換,和 4 次數(shù)據(jù)拷貝。

當(dāng)然,要使用 sendfile,Linux 內(nèi)核版本必須要 2.1 以上的版本。


PageCache 有什么作用?

回顧前面說(shuō)道文件傳輸過(guò)程,其中第一步都是先需要先把磁盤文件數(shù)據(jù)拷貝「內(nèi)核緩沖區(qū)」里,這個(gè)「內(nèi)核緩沖區(qū)」實(shí)際上是磁盤高速緩存(PageCache。

由于零拷貝使用了 PageCache 技術(shù),可以使得零拷貝進(jìn)一步提升了性能,我們接下來(lái)看看 PageCache 是如何做到這一點(diǎn)的。

讀寫磁盤相比讀寫內(nèi)存的速度慢太多了,所以我們應(yīng)該想辦法把「讀寫磁盤」替換成「讀寫內(nèi)存」。于是,我們會(huì)通過(guò) DMA 把磁盤里的數(shù)據(jù)搬運(yùn)到內(nèi)存里,這樣就可以用讀內(nèi)存替換讀磁盤。

但是,內(nèi)存空間遠(yuǎn)比磁盤要小,內(nèi)存注定只能拷貝磁盤里的一小部分?jǐn)?shù)據(jù)。

那問(wèn)題來(lái)了,選擇哪些磁盤數(shù)據(jù)拷貝到內(nèi)存呢?

我們都知道程序運(yùn)行的時(shí)候,具有「局部性」,所以通常,剛被訪問(wèn)的數(shù)據(jù)在短時(shí)間內(nèi)再次被訪問(wèn)的概率很高,于是我們可以用?PageCache 來(lái)緩存最近被訪問(wèn)的數(shù)據(jù),當(dāng)空間不足時(shí)淘汰最久未被訪問(wèn)的緩存。

所以,讀磁盤數(shù)據(jù)的時(shí)候,優(yōu)先在 PageCache 找,如果數(shù)據(jù)存在則可以直接返回;如果沒(méi)有,則從磁盤中讀取,然后緩存 PageCache 中。

還有一點(diǎn),讀取磁盤數(shù)據(jù)的時(shí)候,需要找到數(shù)據(jù)所在的位置,但是對(duì)于機(jī)械磁盤來(lái)說(shuō),就是通過(guò)磁頭旋轉(zhuǎn)到數(shù)據(jù)所在的扇區(qū),再開(kāi)始「順序」讀取數(shù)據(jù),但是旋轉(zhuǎn)磁頭這個(gè)物理動(dòng)作是非常耗時(shí)的,為了降低它的影響,PageCache 使用了「預(yù)讀功能」。

比如,假設(shè) read 方法每次只會(huì)讀?32 KB?的字節(jié),雖然 read 剛開(kāi)始只會(huì)讀 0 ~ 32 KB 的字節(jié),但內(nèi)核會(huì)把其后面的 32~64 KB 也讀取到 PageCache,這樣后面讀取 32~64 KB 的成本就很低,如果在 32~64 KB 淘汰出 PageCache 前,進(jìn)程讀取到它了,收益就非常大。

所以,PageCache 的優(yōu)點(diǎn)主要是兩個(gè):

  • 緩存最近被訪問(wèn)的數(shù)據(jù);

  • 預(yù)讀功能;

這兩個(gè)做法,將大大提高讀寫磁盤的性能。

但是,在傳輸大文件(GB 級(jí)別的文件)的時(shí)候,PageCache 會(huì)不起作用,那就白白浪費(fèi) DMA 多做的一次數(shù)據(jù)拷貝,造成性能的降低,即使使用了 PageCache 的零拷貝也會(huì)損失性能

這是因?yàn)槿绻阌泻芏?GB 級(jí)別文件需要傳輸,每當(dāng)用戶訪問(wèn)這些大文件的時(shí)候,內(nèi)核就會(huì)把它們載入 PageCache 中,于是 PageCache 空間很快被這些大文件占滿。

另外,由于文件太大,可能某些部分的文件數(shù)據(jù)被再次訪問(wèn)的概率比較低,這樣就會(huì)帶來(lái) 2 個(gè)問(wèn)題:

  • PageCache 由于長(zhǎng)時(shí)間被大文件占據(jù),其他「熱點(diǎn)」的小文件可能就無(wú)法充分使用到 PageCache,于是這樣磁盤讀寫的性能就會(huì)下降了;

  • PageCache 中的大文件數(shù)據(jù),由于沒(méi)有享受到緩存帶來(lái)的好處,但卻耗費(fèi) DMA 多拷貝到 PageCache 一次;

所以,針對(duì)大文件的傳輸,不應(yīng)該使用 PageCache,也就是說(shuō)不應(yīng)該使用零拷貝技術(shù),因?yàn)榭赡苡捎?PageCache 被大文件占據(jù),而導(dǎo)致「熱點(diǎn)」小文件無(wú)法利用到 PageCache,這樣在高并發(fā)的環(huán)境下,會(huì)帶來(lái)嚴(yán)重的性能問(wèn)題。


大文件傳輸用什么方式實(shí)現(xiàn)?

那針對(duì)大文件的傳輸,我們應(yīng)該使用什么方式呢?

我們先來(lái)看看最初的例子,當(dāng)調(diào)用 read 方法讀取文件時(shí),進(jìn)程實(shí)際上會(huì)阻塞在 read 方法調(diào)用,因?yàn)橐却疟P數(shù)據(jù)的返回,如下圖:

具體過(guò)程:

  • 當(dāng)調(diào)用 read 方法時(shí),會(huì)阻塞著,此時(shí)內(nèi)核會(huì)向磁盤發(fā)起 I/O 請(qǐng)求,磁盤收到請(qǐng)求后,便會(huì)尋址,當(dāng)磁盤數(shù)據(jù)準(zhǔn)備好后,就會(huì)向內(nèi)核發(fā)起 I/O 中斷,告知內(nèi)核磁盤數(shù)據(jù)已經(jīng)準(zhǔn)備好;

  • 內(nèi)核收到 I/O 中斷后,就將數(shù)據(jù)從磁盤控制器緩沖區(qū)拷貝到 PageCache 里;

  • 最后,內(nèi)核再把 PageCache 中的數(shù)據(jù)拷貝到用戶緩沖區(qū),于是 read 調(diào)用就正常返回了。

對(duì)于阻塞的問(wèn)題,可以用異步 I/O 來(lái)解決,它工作方式如下圖:

它把讀操作分為兩部分:

  • 前半部分,內(nèi)核向磁盤發(fā)起讀請(qǐng)求,但是可以不等待數(shù)據(jù)就位就可以返回,于是進(jìn)程此時(shí)可以處理其他任務(wù);

  • 后半部分,當(dāng)內(nèi)核將磁盤中的數(shù)據(jù)拷貝到進(jìn)程緩沖區(qū)后,進(jìn)程將接收到內(nèi)核的通知,再去處理數(shù)據(jù);

而且,我們可以發(fā)現(xiàn),異步 I/O 并沒(méi)有涉及到 PageCache,所以使用異步 I/O 就意味著要繞開(kāi) PageCache。

繞開(kāi) PageCache 的 I/O 叫直接 I/O,使用 PageCache 的 I/O 則叫緩存 I/O。通常,對(duì)于磁盤,異步 I/O 只支持直接 I/O。

前面也提到,大文件的傳輸不應(yīng)該使用 PageCache,因?yàn)榭赡苡捎?PageCache 被大文件占據(jù),而導(dǎo)致「熱點(diǎn)」小文件無(wú)法利用到 PageCache。

于是,在高并發(fā)的場(chǎng)景下,針對(duì)大文件的傳輸?shù)姆绞?,?yīng)該使用「異步 I/O + 直接 I/O」來(lái)替代零拷貝技術(shù)。

直接 I/O 應(yīng)用場(chǎng)景常見(jiàn)的兩種:

  • 應(yīng)用程序已經(jīng)實(shí)現(xiàn)了磁盤數(shù)據(jù)的緩存,那么可以不需要 PageCache 再次緩存,減少額外的性能損耗。在 MySQL 數(shù)據(jù)庫(kù)中,可以通過(guò)參數(shù)設(shè)置開(kāi)啟直接 I/O,默認(rèn)是不開(kāi)啟;

  • 傳輸大文件的時(shí)候,由于大文件難以命中 PageCache 緩存,而且會(huì)占滿 PageCache 導(dǎo)致「熱點(diǎn)」文件無(wú)法充分利用緩存,從而增大了性能開(kāi)銷,因此,這時(shí)應(yīng)該使用直接 I/O。

另外,由于直接 I/O 繞過(guò)了 PageCache,就無(wú)法享受內(nèi)核的這兩點(diǎn)的優(yōu)化:

  • 內(nèi)核的 I/O 調(diào)度算法會(huì)緩存盡可能多的 I/O 請(qǐng)求在 PageCache 中,最后「合并」成一個(gè)更大的 I/O 請(qǐng)求再發(fā)給磁盤,這樣做是為了減少磁盤的尋址操作;

  • 內(nèi)核也會(huì)「預(yù)讀」后續(xù)的 I/O 請(qǐng)求放在 PageCache 中,一樣是為了減少對(duì)磁盤的操作;

于是,傳輸大文件的時(shí)候,使用「異步 I/O + 直接 I/O」了,就可以無(wú)阻塞地讀取文件了。

所以,傳輸文件的時(shí)候,我們要根據(jù)文件的大小來(lái)使用不同的方式:

  • 傳輸大文件的時(shí)候,使用「異步 I/O + 直接 I/O」;

  • 傳輸小文件的時(shí)候,則使用「零拷貝技術(shù)」;

在 Nginx 中,我們可以用如下配置,來(lái)根據(jù)文件的大小來(lái)使用不同的方式:

location?/video/?{?
????sendfile?on;?
????aio?on;?
????directio?1024m;?
}

當(dāng)文件大小大于?directio?值后,使用「異步 I/O + 直接 I/O」,否則使用「零拷貝技術(shù)」。


總結(jié)

早期 I/O 操作,內(nèi)存與磁盤的數(shù)據(jù)傳輸?shù)墓ぷ鞫际怯?CPU 完成的,而此時(shí) CPU 不能執(zhí)行其他任務(wù),會(huì)特別浪費(fèi) CPU 資源。

于是,為了解決這一問(wèn)題,DMA 技術(shù)就出現(xiàn)了,每個(gè) I/O 設(shè)備都有自己的 DMA 控制器,通過(guò)這個(gè) DMA 控制器,CPU 只需要告訴 DMA 控制器,我們要傳輸什么數(shù)據(jù),從哪里來(lái),到哪里去,就可以放心離開(kāi)了。后續(xù)的實(shí)際數(shù)據(jù)傳輸工作,都會(huì)由 DMA 控制器來(lái)完成,CPU 不需要參與數(shù)據(jù)傳輸?shù)墓ぷ鳌?/p>

傳統(tǒng) IO 的工作方式,從硬盤讀取數(shù)據(jù),然后再通過(guò)網(wǎng)卡向外發(fā)送,我們需要進(jìn)行 4 上下文切換,和 4 次數(shù)據(jù)拷貝,其中 2 次數(shù)據(jù)拷貝發(fā)生在內(nèi)存里的緩沖區(qū)和對(duì)應(yīng)的硬件設(shè)備之間,這個(gè)是由 DMA 完成,另外 2 次則發(fā)生在內(nèi)核態(tài)和用戶態(tài)之間,這個(gè)數(shù)據(jù)搬移工作是由 CPU 完成的。

為了提高文件傳輸?shù)男阅?,于是就出現(xiàn)了零拷貝技術(shù),它通過(guò)一次系統(tǒng)調(diào)用(sendfile?方法)合并了磁盤讀取與網(wǎng)絡(luò)發(fā)送兩個(gè)操作,降低了上下文切換次數(shù)。另外,拷貝數(shù)據(jù)都是發(fā)生在內(nèi)核中的,天然就降低了數(shù)據(jù)拷貝的次數(shù)。

Kafka 和 Nginx 都有實(shí)現(xiàn)零拷貝技術(shù),這將大大提高文件傳輸?shù)男阅堋?/p>

零拷貝技術(shù)是基于 PageCache 的,PageCache 會(huì)緩存最近訪問(wèn)的數(shù)據(jù),提升了訪問(wèn)緩存數(shù)據(jù)的性能,同時(shí),為了解決機(jī)械硬盤尋址慢的問(wèn)題,它還協(xié)助 I/O 調(diào)度算法實(shí)現(xiàn)了 IO 合并與預(yù)讀,這也是順序讀比隨機(jī)讀性能好的原因。這些優(yōu)勢(shì),進(jìn)一步提升了零拷貝的性能。

需要注意的是,零拷貝技術(shù)是不允許進(jìn)程對(duì)文件內(nèi)容作進(jìn)一步的加工的,比如壓縮數(shù)據(jù)再發(fā)送。

另外,當(dāng)傳輸大文件時(shí),不能使用零拷貝,因?yàn)榭赡苡捎?PageCache 被大文件占據(jù),而導(dǎo)致「熱點(diǎn)」小文件無(wú)法利用到 PageCache,并且大文件的緩存命中率不高,這時(shí)就需要使用「異步 IO + 直接 IO 」的方式。

在 Nginx 里,可以通過(guò)配置,設(shè)定一個(gè)文件大小閾值,針對(duì)大文件使用異步 IO 和直接 IO,而對(duì)小文件使用零拷貝。


絮叨

小林創(chuàng)了「技術(shù)交流群」一段時(shí)間了,群里氛圍很好,有不少小伙伴會(huì)分享秋招經(jīng)驗(yàn),也有眾多的優(yōu)質(zhì)技術(shù)文章。更重要的是,群里時(shí)不時(shí)有「紅包」等福利,當(dāng)然群里不會(huì)有任何廣告。


歡迎有興趣的小伙伴加入,加群方式只需要掃小林的私人微信二維碼,備注「加群」即可。


大家好,我是小林,一個(gè)專為大家圖解的工具人,如果覺(jué)得文章對(duì)你有幫助,歡迎分享給你的朋友,也給小林點(diǎn)個(gè)「在看」,這對(duì)小林非常重要,謝謝你們,我們下次見(jiàn)!



推薦閱讀

一口氣搞懂「文件系統(tǒng)」,就靠這 25 張圖了

鍵盤敲入 A 字母時(shí),操作系統(tǒng)期間發(fā)生了什么…

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國(guó)汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開(kāi)發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來(lái)越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來(lái)越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場(chǎng)的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開(kāi)幕式在貴陽(yáng)舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語(yǔ)權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營(yíng)業(yè)績(jī)穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤(rùn)率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長(zhǎng) 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競(jìng)爭(zhēng)力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競(jìng)爭(zhēng)優(yōu)勢(shì)...

關(guān)鍵字: 通信 BSP 電信運(yùn)營(yíng)商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國(guó)電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場(chǎng) NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長(zhǎng)三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡(jiǎn)稱"軟通動(dòng)力")與長(zhǎng)三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉