/ PageCache 有什么作用? /
在我們前面講解零拷貝的內(nèi)容時,我們了解到一個重要的概念,即內(nèi)核緩沖區(qū)。那么,你可能會好奇內(nèi)核緩沖區(qū)到底是什么?這個專有名詞就是 PageCache,也被稱為磁盤高速緩存。也可以看下 windows 下的緩存區(qū):如圖所示:
圖片
零拷貝進一步提升性能的原因在于 PageCache 技術(shù)的使用。接下來,我們將詳細探討 PageCache 技術(shù)是如何實現(xiàn)這一目標(biāo)的。
讀寫磁盤相比讀寫內(nèi)存的速度慢太多了,但我們可以采取一種方法來改善這個問題,即將磁盤數(shù)據(jù)部分緩存到內(nèi)核中,也就是將其存儲在 PageCache 緩存區(qū)中。這個過程實際上是通過 DMA(直接內(nèi)存訪問)控制器將磁盤數(shù)據(jù)拷貝到內(nèi)核緩沖區(qū)中。
然而,需要注意的是,由于內(nèi)存空間較磁盤空間有限,因此存在一系列算法來確保 pageCache 占用的內(nèi)存空間不過大。我們在程序運行時都知道存在一種「局部性」,即剛剛被訪問的數(shù)據(jù)在短時間內(nèi)很可能再次被訪問到,概率很高。因此,pageCache 被用作緩存最近訪問的數(shù)據(jù)。可以將 pageCache 看作是 redis,而磁盤則類似于 MySQL。此外,pageCache 還使用了內(nèi)存淘汰機制,在內(nèi)存空間不足時,會淘汰最近最久未被訪問的緩存。
當(dāng)在項目中使用 Redis 時,你一定知道如何使用它。和 Redis 類似, PageCache 的工作原理也是一樣的。在進程需要訪問數(shù)據(jù)時,它會首先檢查 PageCache 是否已經(jīng)存儲了所需的數(shù)據(jù)。如果數(shù)據(jù)已經(jīng)存在于 PageCache 中,內(nèi)核會直接返回數(shù)據(jù);如果數(shù)據(jù)未被緩存,則會從磁盤讀取并將數(shù)據(jù)緩存到 PageCache 中,以備下次查詢時使用。這種方式可以有效提高訪問效率。
然而,pageCache 還具有另一個優(yōu)點,即預(yù)讀功能。當(dāng)訪問并讀取磁盤數(shù)據(jù)時,實際上需要定位磁盤中的位置。對于機械硬盤而言,這意味著磁頭必須旋轉(zhuǎn)到數(shù)據(jù)所在的扇區(qū)位置,然后開始順序讀取數(shù)據(jù)。然而,旋轉(zhuǎn)磁頭這種物理操作對計算機而言非常耗時。為了降低其影響,就出現(xiàn)了預(yù)讀功能。通過預(yù)讀功能,可以提前預(yù)讀下一扇區(qū)的數(shù)據(jù),減少等待磁頭旋轉(zhuǎn)的時間。
比如 read 方法需要讀取 32KB 的字節(jié)的數(shù)據(jù),使其在讀取 32KB 字節(jié)數(shù)據(jù)后,繼續(xù)讀取后面的 32-64KB,并將這一塊數(shù)據(jù)一起緩存到 pageCache 緩沖區(qū)。這樣做的好處在于,如果后續(xù)讀取需要的數(shù)據(jù)在這塊緩存中命中,那么讀取成本會大幅降低。可以類比于 redis 中提前緩存一部分分布式唯一 id 用于插入數(shù)據(jù)庫時的分配操作,這樣就無需每次插入前都去獲取一遍 id。然而,一般情況下,為了避免可能出現(xiàn)的"毛刺"現(xiàn)象,我們通常會使用雙緩存機制來處理。這個雙緩存機制可以進一步優(yōu)化讀取操作的效果。
因此,PageCache 的優(yōu)點主要包括兩個方面:首先,它能夠?qū)?shù)據(jù)緩存到 PageCache 中;其次,它還利用了數(shù)據(jù)的預(yù)讀功能。這兩個操作極大地增強了讀寫磁盤時的性能。
但是,你可以想象一下如果你在傳輸大文件時比如好幾個 G 的文件,如果還是使用零拷貝技術(shù),內(nèi)核還是會把他們放入 pageCache 緩存區(qū),那這樣不就產(chǎn)生問題了嗎?你也可以想一下如果你往 redis 緩存中放了一個還幾個 G 大小的 value,而且還知道緩存了也沒用,那不就相當(dāng)于 redis 形同虛設(shè)了嗎?把其他熱點數(shù)據(jù)也弄沒了,所以 pageCache 也有這樣的一個問題,一是大文件搶占了 pageCache 的內(nèi)存大小,這樣做會導(dǎo)致其他熱點數(shù)據(jù)無法存儲在 pageCache 緩沖區(qū)中,從而降低磁盤的讀寫性能。此外,由于 pageCache 無法享受到緩存的好處,還會產(chǎn)生一個 DMA 數(shù)據(jù)拷貝的過程。
因此,最佳的優(yōu)化方法是針對大文件傳輸時不使用 pageCache,也就是不使用零拷貝技術(shù)。這是因為零拷貝技術(shù)會占用大量的內(nèi)存空間,影響其他熱點數(shù)據(jù)的訪問優(yōu)化。在高并發(fā)環(huán)境下,這幾乎肯定會導(dǎo)致嚴(yán)重的性能問題。
/ 大文件傳輸用什么方式實現(xiàn)? /
那針對大文件的傳輸,我們應(yīng)該使用什么方式呢?
讓我們首先來觀察最初的示例。當(dāng)調(diào)用 read 方法讀取文件時,進程實際上會被阻塞在 read 方法的調(diào)用處,因為它需要等待磁盤數(shù)據(jù)的返回。如下圖所示:
圖片
在沒有使用零拷貝技術(shù)的情況下,我們的用戶進程使用同步 IO 的方式,它會一直阻塞等待系統(tǒng)調(diào)用返回數(shù)據(jù)。讓我們回顧一下之前的具體流程:
- 應(yīng)用程序發(fā)起 read 系統(tǒng)調(diào)用,用戶進程開始進行阻塞等待結(jié)果返回。
- 此時內(nèi)核會向磁盤發(fā)起 I/O 請求,磁盤收到請求后,開始尋址。當(dāng)磁盤數(shù)據(jù)準(zhǔn)備好后,就會向內(nèi)核發(fā)起 I/O 中斷,告知內(nèi)核磁盤數(shù)據(jù)已經(jīng)準(zhǔn)備好。
- 內(nèi)核收到中斷信號后,將數(shù)據(jù)從磁盤控制器緩存區(qū)拷貝到 pageCache 緩沖區(qū)。
- 最后,內(nèi)核會將 pageCache 中的數(shù)據(jù)再次拷貝到用戶緩沖區(qū),也就是用戶態(tài)的內(nèi)存中,然后 read 調(diào)用返回。
我們知道,既然有同步 IO,就一定有異步 IO 來解決阻塞的問題。異步 IO 的工作方式如下圖所示:
圖片
它將讀操作分為兩個部分:
- 第一部分是用戶進程發(fā)起 IO 請求給內(nèi)核,然后進程就不再關(guān)心該 IO 操作,而是繼續(xù)處理其他任務(wù)。
- 第二部分是當(dāng)內(nèi)核接收到中斷信號后,將數(shù)據(jù)直接拷貝到用戶緩沖區(qū),并通知用戶進程操作成功。然后用戶進程開始處理數(shù)據(jù)。
我們發(fā)現(xiàn)在這個過程中,并沒有涉及到將數(shù)據(jù)拷貝到 pageCache 中,因此使用異步方式繞開了 pageCache。直接 IO 是指繞過 pageCache 的 IO 請求,而緩存 IO 是指使用 pageCache 的 IO 請求。通常,對于磁盤而言,異步 IO 只支持直接 IO。
正如前面所提到的,對于大文件的傳輸,不應(yīng)該使用 PageCache,因為這可能會導(dǎo)致 PageCache 被大文件占據(jù),從而使得"熱點"小文件無法充分利用 PageCache 的優(yōu)勢。
因此,在高并發(fā)的場景下,對于大文件傳輸,我們應(yīng)該采用"異步 I/O + 直接 I/O"的方式來代替零拷貝技術(shù)。
直接 I/O 有兩種常見的應(yīng)用場景:
- 首先,如果應(yīng)用程序已經(jīng)實現(xiàn)了磁盤數(shù)據(jù)的緩存,就不需要再次使用 PageCache 進行緩存,這樣可以減少額外的性能損耗。例如,在 MySQL 數(shù)據(jù)庫中,可以通過參數(shù)設(shè)置來開啟直接 I/O,避免重復(fù)的緩存操作,默認(rèn)情況下是不開啟的。
- 其次,在傳輸大文件時,由于大文件很難命中 PageCache 的緩存,而且會占滿 PageCache 導(dǎo)致"熱點"文件無法充分利用緩存,增加了性能開銷。因此,在這種情況下,應(yīng)該使用直接 I/O 來繞過 PageCache 的緩存,以提高性能。
需要注意的是,直接 I/O 繞過了 PageCache,因此無法享受內(nèi)核的兩項優(yōu)化。
- 首先,內(nèi)核的 I/O 調(diào)度算法會在 PageCache 中緩存盡可能多的 I/O 請求,然后將它們合并成一個更大的 I/O 請求發(fā)送給磁盤,以減少磁盤的尋址操作。
- 其次,內(nèi)核會預(yù)讀后續(xù)的 I/O 請求并將其放入 PageCache 中,同樣是為了減少對磁盤的操作。這些優(yōu)化在直接 I/O 中無法享受到。
于是,當(dāng)我們需要傳輸大文件時,我們可以利用異步 I/O 和直接 I/O 的組合來實現(xiàn)無阻塞的文件讀取。這種方式可以有效避免 PageCache 的影響,提高文件傳輸?shù)男省?/p>
因此,在文件傳輸過程中,我們可以根據(jù)文件的大小來選擇不同的優(yōu)化方式,以提高傳輸效率。對于大文件,使用異步 I/O 和直接 I/O 可以避免 PageCache 的影響;而對于小文件,則可以使用零拷貝技術(shù)來減少數(shù)據(jù)拷貝次數(shù),提高傳輸速度。
在 Nginx 中,我們可以通過以下配置來根據(jù)文件的大小選擇不同的優(yōu)化方式:
location /video/ {
sendfile on;
AIo on;
directio 1024m;
}
在這個配置中,我們開啟了 sendfile 選項,這允許 Nginx 使用零拷貝技術(shù)來傳輸文件。同時,我們也啟用了 aio 選項,這使得 Nginx 可以使用異步 I/O 來提高文件傳輸?shù)男省?/p>
而通過設(shè)置 directio 參數(shù)為 1024m,我們告訴 Nginx 當(dāng)文件大小超過 1024MB 時,使用直接 I/O 來進行文件傳輸。這意味著在傳輸大文件時,Nginx 將使用異步 I/O 和直接 I/O 的組合來實現(xiàn)無阻塞的文件讀取,避免了 PageCache 的影響。而對于小文件,Nginx 將繼續(xù)使用零拷貝技術(shù),以減少數(shù)據(jù)拷貝次數(shù),提高傳輸速度。
/ 總結(jié) /
至此,我們的計算機基礎(chǔ)專欄就結(jié)束了,不知道大家有沒有發(fā)現(xiàn),操作系統(tǒng)底層提供了豐富的解決方案來支持應(yīng)用程序的復(fù)雜性和可擴展性。對于任何工作中遇到的問題,我們都可以從操作系統(tǒng)的角度尋找解決方法。
今天這一篇其實就是來打破零拷貝的方案神話的,沒有一種技術(shù)是最好的,只有最合適的方法。我們需要根據(jù)具體的需求和情況來選擇適合的解決方案,以提高應(yīng)用程序的性能和可擴展性。謝謝大家的閱讀和關(guān)注,希望這個專欄能對大家有所啟發(fā)和幫助!