磁盤可以說是計算機系統最慢的硬體之一,讀寫速度相差記憶體 10 倍以上,所以針對優化磁盤的技術非常的多,比如零拷貝、直接 I/O、異步 I/O 等等,這些優化的目的就是為了提高系統的吞吐量,另外作業系統內核中的磁盤高速快取區,可以有效的減少磁盤的訪問次數,本文會分析 I/O 作業方式,以及如何優化傳輸檔案的性能,參考博客如下:
內容提綱
本會從以下幾個方面介紹磁盤的IO技術:
- DMA之前的IO方式
- 直接記憶體訪問——DMA技術,
- DMA檔案傳輸存在的問題,
- 如何提高檔案傳輸的性能,
- 零拷貝實作原理分析,
- PageCache有什么用,
- 大檔案傳輸用什么方式實作,
DMA之前的IO
在沒有DMA技術之前,作業系統的從磁盤讀取資料的IO程序如下所示(以read()介面為例):
read(file, tmp_buf, len);
- 用戶程式需要讀取資料,呼叫read方法,把讀取資料的指令交給CPU執行,執行緒進入阻塞狀態,
- CPU發出指令給磁盤控制器,告訴磁盤控制器需要讀取哪些資料,然后回傳;
- 磁盤控制器接收到指令后,把指定的資料放入磁盤內部的快取區,然后用中斷的方式通知CPU;
- CPU收到中斷信號之后,開始一個位元組一個位元組的把資料讀取到PageCache快取區;
- CPU再一個位元組一個位元組把資料從PageCache快取區讀取到用戶快取區;
- 用戶程式從記憶體中讀取到資料,可以繼續執行后續邏輯,

可以看到,整個資料的傳輸程序,都要需要CPU親自參與搬運資料的程序,而且這個程序,CPU是不能做其他事情的,簡單的搬運幾個字符資料那沒問題,但是如果我們用千兆網卡或者硬碟傳輸大量資料的時候,都用CPU來搬運的話,肯定忙不過來,計算機科學家們發現了事情的嚴重性后,于是就發明了 DMA 技術,也就是直接記憶體訪問(Direct Memory Access) 技術,
直接記憶體訪問——DMA技術
什么是 DMA 技術?簡單理解就是,在進行 I/O 設備和記憶體的資料傳輸的時候,資料搬運的作業全部交給 DMA 控制器,而 CPU 不再參與任何與資料搬運相關的事情,這樣 CPU 就可以去處理別的事務,
那使用 DMA 控制器進行資料傳輸的程序究竟是什么樣的呢?下面我們來具體看看,
read(file, tmp_buf, len);
- 用戶程式需要讀取資料,呼叫read方法,把讀取資料的指令交給CPU執行,
- CPU發出指令給DMA,告訴DMA需要讀取磁盤的哪些資料,然后回傳,執行緒進入阻塞狀態
- DMA向磁盤控制器發出IO請求,告訴磁盤控制器需要讀取哪些資料,然后回傳;
- 磁盤控制器收到IO請求之后,把資料讀取到磁盤快取區,當磁盤快取讀取完成之后,中斷DMA;
- DMA收到磁盤的中斷信號,將磁盤快取區的資料讀取到PageCache快取區,然后中斷CPU;
- CPU回應DMA中斷信號,知道資料讀取完成,然后將PageCache快取區中的資料讀取到用戶快取中;
- 用戶程式從記憶體中讀取到資料,可以繼續執行后續邏輯,

可以看到, 整個資料傳輸的程序,CPU不再參與磁盤資料搬運的作業,而是全程由DMA完成,但是CPU在這個程序中也是必不可少的,因為傳輸什么資料,從哪里傳輸到哪里,都需要CPU來告訴DMA控制器,
早期DMA只存在在主板上,如今由于I/O設備越來越多,資料傳輸的需求也不盡相同,所以每個I/O設備里面都有自己的DMA控制器,
DMA檔案傳輸存在的問題
如果服務端要提供檔案傳輸的功能,我們能想到的最簡單的方式是:將磁盤上的檔案讀取出來,然后通過網路協議發送給客戶端,
傳統 I/O 的作業方式是,資料讀取和寫入是從用戶空間到內核空間來回復制,而內核空間的資料是通過作業系統層面的 I/O 介面從磁盤讀取或寫入,
代碼通常如下,一般會需要以下兩個系統呼叫,代碼很簡單,雖然就兩行代碼,但是這里面發生了不少的事情,
read(file, tmp_buf, len);
write(socket, tmp_buf, len);
- 用戶程式需要讀取資料,呼叫read方法,把讀取資料的指令交給CPU執行,執行緒進入阻塞狀態,
- CPU發出指令給磁盤DMA,告訴磁盤DMA需要讀取磁盤的哪些資料,然后回傳;
- 磁盤DMA向磁盤控制器發出IO請求,告訴磁盤控制器需要讀取哪些資料,然后回傳;
- 磁盤控制器收到IO請求之后,把資料讀取到磁盤快取區,當磁盤快取讀取完成之后,中斷DMA;
- DMA收到磁盤的中斷信號,將磁盤快取區的資料讀取到PageCache快取區,然后中斷CPU;
- CPU回應DMA中斷信號,知道資料讀取完成,然后將PageCache快取區中的資料讀取到用戶快取中;
- 用戶程式從記憶體中讀取到資料,可以繼續執行后續寫網卡資料操作;
- 用戶需要向網卡設備寫入資料,呼叫write方法,把寫資料指令交給CPU執行,執行緒進入阻塞;
- CPU將用戶快取區的資料寫入PageCache快取區,然后通知網卡DMA寫資料;
- 網卡DMA將資料從PageCache快取區復制到網卡,交給網卡處理資料,
- 網卡開始處理資料,網卡處理完成資料之后中斷網卡DMA;
- 網卡DMA處理中斷,知道資料處理完成,向CPU發出中斷;
- CPU回應DMA中斷信號,知道資料處理完成,喚醒用戶執行緒;
- 用戶程式執行后續邏輯,
這個程序比較復雜,其中主要存在以下問題:
- 發生了4次用戶態與內核態的背景關系切換,因為發生了兩次系統呼叫,一次是read() ,一次是write(),每次系統呼叫都得先從用戶態切換到內核態,等內核完成任務后,再從內核態切換回用戶態,背景關系切換到成本并不小,一次切換需要耗時幾十納秒到幾微秒,雖然時間看上去很短,但是在高并發的場景下,這類時間容易被累積和放大,從而影響系統的性能,
- 發生了4次資料拷貝,其中兩次是 DMA 的拷貝,另外兩次則是通過 CPU 拷貝的,下面說一下這個程序:第一次拷貝,把磁盤上的資料拷貝到作業系統內核的緩沖區里,這個拷貝的程序是通過 DMA 搬運的,第二次拷貝,把內核緩沖區的資料拷貝到用戶的緩沖區里,于是我們應用程式就可以使用這部分資料了,這個拷貝到程序是由 CPU 完成的,第三次拷貝,把剛才拷貝到用戶的緩沖區里的資料,再拷貝到內核的 socket 的緩沖區里,這個程序依然還是由 CPU 搬運的,第四次拷貝,把內核的 socket 緩沖區里的資料,拷貝到網卡的緩沖區里,這個程序又是由 DMA 搬運的,
我們回過頭看這個檔案傳輸的程序,我們只是搬運一份資料,結果卻搬運了 4 次,過多的資料拷貝無疑會消耗 CPU 資源,大大降低了系統性能,
這種簡單又傳統的檔案傳輸方式,存在冗余的上文切換和資料拷貝,在高并發系統里是非常糟糕的,多了很多不必要的開銷,會嚴重影響系統性能,
所以,要想提高檔案傳輸的性能,就需要減少「用戶態與內核態的背景關系切換」和「記憶體拷貝」的次數,
如何提高檔案傳輸的性能
減少用戶態與內核態的背景關系切換的次數
讀取磁盤資料的時候,之所以要發生背景關系切換,這是因為用戶空間沒有權限操作磁盤或網卡,內核的權限最高,這些操作設備的程序都需要交由作業系統內核來完成,所以一般要通過內核去完成某些任務的時候,就需要使用作業系統提供的系統呼叫函式,
而一次系統呼叫必然會發生 2 次背景關系切換:首先從用戶態切換到內核態,當內核執行完任務后,再切換回用戶態交由行程代碼執行,
所以,要想減少背景關系切換到次數,就要減少系統呼叫的次數,
減少資料拷貝的次數
在前面我們知道了,傳統的檔案傳輸方式會歷經 4 次資料拷貝,而且這里面,「從內核的讀緩沖區拷貝到用戶的緩沖區里,再從用戶的緩沖區里拷貝到 socket 的緩沖區里」,這個程序是沒有必要的,
因為檔案傳輸的應用場景中,在用戶空間我們并不會對資料「再加工」,所以資料實際上可以不用搬運到用戶空間,因此用戶的緩沖區是沒有必要存在的,
零拷貝實作原理分析
零拷貝技術實作的方式通常有 2 種:
- mmap + write
- sendfile
下面就談一談,它們是如何減少「背景關系切換」和「資料拷貝」的次數,
mmap + write
在前面我們知道,read()系統呼叫的程序中會把內核緩沖區的資料拷貝到用戶的緩沖區里,于是為了減少這一步開銷,我們可以用 mmap()替換read()系統呼叫函式,
buf = mmap(file, len);
write(sockfd, buf, len);
mmap() 系統呼叫函式會直接把內核緩沖區里的資料「映射」到用戶空間,這樣,作業系統內核與用戶空間就不需要再進行任何的資料拷貝操作,

具體程序如下:
- 應用行程呼叫了mmap()后,DMA會把磁盤的資料拷貝到內核的緩沖區里,接著,應用行程跟作業系統內核「共享」這個緩沖區;
- 應用行程再呼叫write(),作業系統直接將內核緩沖區的資料拷貝到socket緩沖區中,這一切都發生在內核態,由CPU來搬運資料;
- 最后,把內核的socket緩沖區里的資料,拷貝到網卡的緩沖區里,這個程序是由DMA搬運的,
我們可以得知,通過使用mmap()來代替read(), 可以減少一次資料拷貝的程序,
但這還不是最理想的零拷貝,因為仍然需要通過CPU把內核緩沖區的資料拷貝到socket緩沖區里,而且仍然需要4次背景關系切換,因為系統呼叫還是2次,
sendfile
在 Linux 內核版本 2.1 中,提供了一個專門發送檔案的系統呼叫函式 sendfile(),函式形式如下:
#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);
它的前兩個引數分別是目的端和源端的檔案描述符,后面兩個引數是源端的偏移量和復制資料的長度,回傳值是實際復制資料的長度,
首先,它可以替代前面的 read() 和 write() 這兩個系統呼叫,這樣就可以減少一次系統呼叫,也就減少了 2 次背景關系切換的開銷,
其次,該系統呼叫,可以直接把內核緩沖區里的資料拷貝到 socket 緩沖區里,不再拷貝到用戶態,這樣就只有 2 次背景關系切換,和 3 次資料拷貝,如下圖:

但是這還不是真正的零拷貝技術,如果網卡支持 SG-DMA(The Scatter-Gather Direct Memory Access)技術(和普通的 DMA 有所不同),我們可以進一步減少通過 CPU 把內核緩沖區里的資料拷貝到 socket 緩沖區的程序,
你可以在你的 Linux 系統通過下面這個命令,查看網卡是否支持 scatter-gather 特性:
$ ethtool -k eth0 | grep scatter-gather
scatter-gather: on
于是,從 Linux 內核 2.4 版本開始起,對于支持網卡支持 SG-DMA 技術的情況下, sendfile() 系統呼叫的程序發生了點變化,具體程序如下:
- 通過 DMA 將磁盤上的資料拷貝到內核緩沖區里;
- 緩沖區描述符和資料長度傳到 socket 緩沖區,這樣網卡的 SG-DMA 控制器就可以直接將內核快取中的資料拷貝到網卡的緩沖區里,此程序不需要將資料從作業系統內核緩沖區拷貝到 socket 緩沖區中,這樣就減少了一次資料拷貝;
所以,這個程序之中,只進行了 2 次資料拷貝,如下圖:

這就是所謂的零拷貝(Zero-copy)技術,因為我們沒有在記憶體層面去拷貝資料,也就是說全程沒有通過 CPU 來搬運資料,所有的資料都是通過 DMA 來進行傳輸的,,
零拷貝技術的檔案傳輸方式相比傳統檔案傳輸的方式,減少了 2 次背景關系切換和資料拷貝次數,只需要 2 次背景關系切換和資料拷貝次數,就可以完成檔案的傳輸,而且 2 次的資料拷貝程序,都不需要通過 CPU,2 次都是由 DMA 來搬運,
所以,總體來看,零拷貝技術可以把檔案傳輸的性能提高至少一倍以上,
使用零拷貝技術的專案
事實上,Kafka這個開源專案,就利用了「零拷貝」技術,從而大幅提升了I/O的吞吐率,這也是Kafka在處理海量資料為什么這么快的原因之一,
如果你追溯Kafka檔案傳輸的代碼,你會發現,最終它呼叫了Java NIO庫里的transferTo方法:
@Override
public long transferFrom(FileChannel fileChannel, long position, long count) throws IOException {
return fileChannel.transferTo(position, count, socketChannel);
}
如果Linux系統支持sendfile()系統呼叫,那么transferTo()實際上最后就會使用到sendfile()系統呼叫函式,
曾經有大佬專門寫程序式測驗過,在同樣的硬體條件下,傳統檔案傳輸和零拷拷貝檔案傳輸的性能差異,你可以看到下面這張測驗資料圖,使用了零拷貝能夠縮短 65% 的時間,大幅度提升了機器傳輸資料的吞吐量,

另外,Nginx 也支持零拷貝技術,一般默認是開啟零拷貝技術,這樣有利于提高檔案傳輸的效率,是否開啟零拷貝技術的配置如下:
http {
...
sendfile on
...
}
sendfile 配置的具體意思:
- 設定為 on 表示,使用零拷貝技術來傳輸檔案:sendfile ,這樣只需要 2 次背景關系切換,和 2 次資料拷貝,
- 設定為 off 表示,使用傳統的檔案傳輸技術:read + write,這時就需要 4 次背景關系切換,和 4 次資料拷貝,
當然,要使用 sendfile,Linux 內核版本必須要 2.1 以上的版本,
PageCache 有什么作用?
回顧前面說道檔案傳輸程序,其中第一步都是先需要先把磁盤檔案資料拷貝「內核緩沖區」里,這個「內核緩沖區」實際上是磁盤高速快取(PageCache),
由于零拷貝使用了 PageCache 技術,可以使得零拷貝進一步提升了性能,我們接下來看看 PageCache 是如何做到這一點的,
讀寫磁盤相比讀寫記憶體的速度慢太多了,所以我們應該想辦法把「讀寫磁盤」替換成「讀寫記憶體」,于是,我們會通過 DMA 把磁盤里的資料搬運到記憶體里,這樣就可以用讀記憶體替換讀磁盤,
但是,記憶體空間遠比磁盤要小,記憶體注定只能拷貝磁盤里的一小部分資料,
那問題來了,選擇哪些磁盤資料拷貝到記憶體呢?
我們都知道程式運行的時候,具有「區域性」,所以通常,剛被訪問的資料在短時間內再次被訪問的概率很高,于是我們可以用 PageCache 來快取最近被訪問的資料,當空間不足時淘汰最久未被訪問的快取,
所以,讀磁盤資料的時候,優先在 PageCache 找,如果資料存在則可以直接回傳;如果沒有,則從磁盤中讀取,然后快取 PageCache 中,
還有一點,讀取磁盤資料的時候,需要找到資料所在的位置,但是對于機械磁盤來說,就是通過磁頭旋轉到資料所在的扇區,再開始「順序」讀取資料,但是旋轉磁頭這個物理動作是非常耗時的,為了降低它的影響,PageCache 使用了「預讀功能」,
比如,假設 read 方法每次只會讀 32 KB 的位元組,雖然 read 剛開始只會讀 0 ~ 32 KB 的位元組,但內核會把其后面的 32~64 KB 也讀取到 PageCache,這樣后面讀取 32~64 KB 的成本就很低,如果在 32~64 KB 淘汰出 PageCache 前,行程讀取到它了,收益就非常大,
所以,PageCache 的優點主要是兩個:
- 快取最近被訪問的資料;
- 預讀功能;
這兩個做法,將大大提高讀寫磁盤的性能,
但是,在傳輸大檔案(GB 級別的檔案)的時候,PageCache 會不起作用,那就白白浪費 DMA 多做的一次資料拷貝,造成性能的降低,即使使用了 PageCache 的零拷貝也會損失性能
這是因為如果你有很多 GB 級別檔案需要傳輸,每當用戶訪問這些大檔案的時候,內核就會把它們載入 PageCache 中,于是 PageCache 空間很快被這些大檔案占滿,
另外,由于檔案太大,可能某些部分的檔案資料被再次訪問的概率比較低,這樣就會帶來 2 個問題:
- PageCache 由于長時間被大檔案占據,其他「熱點」的小檔案可能就無法充分使用到 PageCache,于是這樣磁盤讀寫的性能就會下降了;
- PageCache 中的大檔案資料,由于沒有享受到快取帶來的好處,但卻耗費DMA多拷貝到PageCache一次;
所以,針對大檔案的傳輸,不應該使用PageCache,也就是說不應該使用零拷貝技術,因為可能由于PageCache被大檔案占據,而導致「熱點」小檔案無法利用到PageCache,這樣在高并發的環境下,會帶來嚴重的性能問題,
大檔案傳輸用什么方式實作
繞開 PageCache 的 I/O 叫直接 I/O,使用 PageCache 的 I/O 則叫快取 I/O,通常,對于磁盤,異步 I/O 只支持直接 I/O,
前面也提到,大檔案的傳輸不應該使用 PageCache,因為可能由于 PageCache 被大檔案占據,而導致「熱點」小檔案無法利用到 PageCache,
于是,在高并發的場景下,針對大檔案的傳輸的方式,應該使用「異步 I/O + 直接 I/O」來替代零拷貝技術,
直接 I/O 應用場景常見的兩種:
應用程式已經實作了磁盤資料的快取,那么可以不需要 PageCache 再次快取,減少額外的性能損耗,在 MySQL 資料庫中,可以通過引數設定開啟直接 I/O,默認是不開啟;
傳輸大檔案的時候,由于大檔案難以命中 PageCache 快取,而且會占滿 PageCache 導致「熱點」檔案無法充分利用快取,從而增大了性能開銷,因此,這時應該使用直接 I/O,
另外,由于直接 I/O 繞過了 PageCache,就無法享受內核的這兩點的優化:
內核的 I/O 調度演算法會快取盡可能多的 I/O 請求在 PageCache 中,最后「合并」成一個更大的 I/O 請求再發給磁盤,這樣做是為了減少磁盤的尋址操作;
內核也會「預讀」后續的 I/O 請求放在 PageCache 中,一樣是為了減少對磁盤的操作;
于是,傳輸大檔案的時候,使用「異步 I/O + 直接 I/O」了,就可以無阻塞地讀取檔案了,
所以,傳輸檔案的時候,我們要根據檔案的大小來使用不同的方式:
傳輸大檔案的時候,使用「異步 I/O + 直接 I/O」;
傳輸小檔案的時候,則使用「零拷貝技術」;
在 nginx 中,我們可以用如下配置,來根據檔案的大小來使用不同的方式:
location /video/ {
sendfile on;
aio on;
directio 1024m;
}
當檔案大小大于directio值后,使用「異步I/O+直接I/O」,否則使用「零拷貝技術」,
總結
早期 I/O 操作,記憶體與磁盤的資料傳輸的作業都是由 CPU 完成的,而此時 CPU 不能執行其他任務,會特別浪費 CPU 資源,
于是,為了解決這一問題,DMA 技術就出現了,每個 I/O 設備都有自己的 DMA 控制器,通過這個 DMA 控制器,CPU 只需要告訴 DMA 控制器,我們要傳輸什么資料,從哪里來,到哪里去,就可以放心離開了,后續的實際資料傳輸作業,都會由 DMA 控制器來完成,CPU 不需要參與資料傳輸的作業,
傳統 IO 的作業方式,從硬碟讀取資料,然后再通過網卡向外發送,我們需要進行 4 背景關系切換,和 4 次資料拷貝,其中 2 次資料拷貝發生在記憶體里的緩沖區和對應的硬體設備之間,這個是由 DMA 完成,另外 2 次則發生在內核態和用戶態之間,這個資料搬移作業是由 CPU 完成的,
為了提高檔案傳輸的性能,于是就出現了零拷貝技術,它通過一次系統呼叫(sendfile 方法)合并了磁盤讀取與網路發送兩個操作,降低了背景關系切換次數,另外,拷貝資料都是發生在內核中的,天然就降低了資料拷貝的次數,
Kafka 和 Nginx 都有實作零拷貝技術,這將大大提高檔案傳輸的性能,
零拷貝技術是基于 PageCache 的,PageCache 會快取最近訪問的資料,提升了訪問快取資料的性能,同時,為了解決機械硬碟尋址慢的問題,它還協助 I/O 調度演算法實作了 IO 合并與預讀,這也是順序讀比隨機讀性能好的原因,這些優勢,進一步提升了零拷貝的性能,
需要注意的是,零拷貝技術是不允許行程對檔案內容作進一步的加工的,比如壓縮資料再發送,
另外,當傳輸大檔案時,不能使用零拷貝,因為可能由于 PageCache 被大檔案占據,而導致「熱點」小檔案無法利用到 PageCache,并且大檔案的快取命中率不高,這時就需要使用「異步 IO + 直接 IO 」的方式,
在 Nginx 里,可以通過配置,設定一個檔案大小閾值,針對大檔案使用異步 IO 和直接 IO,而對小檔案使用零拷貝,
歡迎關注御狐神的微信公眾號

參考檔案
原來 8 張圖,就可以搞懂「零拷貝」了
linux dma拷貝資料到用戶態,圖解:零拷貝Zero-Copy技術大揭秘
內核態與用戶態、系統呼叫與庫函式、檔案IO與標準IO、緩沖區等概念介紹
本文最先發布至微信公眾號,著作權所有,禁止轉載!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/298494.html
標籤:Java
上一篇:并發編程之:深入決議執行緒池
