深入理解零拷貝技術

hi，大家好，內存拷貝是比較耗時操作，零拷貝是常用優化手段，今天分享的文章就是 Linux 系統零拷貝技術，Kafka 和 MySQL 開源組件都用到這個核心技術，希望大家可以掌握。

DMA 與零拷貝技術

注意事項：除了 Direct I/O，與磁盤相關的文件讀寫操作都有使用到 page cache 技術。

作者：Spongecaptain

原文：https://spongecaptain.cool/SimpleClearFileIO/

  1. 數據的四次拷貝與四次上下文切換

很多應用程序在面臨客戶端請求時，可以等價爲進行如下的系統調用：

  1. File.read(file, buf, len);

  2. Socket.send(socket, buf, len);

例如消息中間件 Kafka 就是這個應用場景，從磁盤中讀取一批消息後原封不動地寫入網卡（NIC，Network interface controller）進行發送。

在沒有任何優化技術使用的背景下，操作系統爲此會進行 4 次數據拷貝，以及 4 次上下文切換，如下圖所示：

如果沒有優化，讀取磁盤數據，再通過網卡傳輸的場景性能比較差：

4 次 copy：

  1. CPU 負責將數據從磁盤搬運到內核空間的 Page Cache 中；

  2. CPU 負責將數據從內核空間的 Socket 緩衝區搬運到的網絡中；

  3. CPU 負責將數據從內核空間的 Page Cache 搬運到用戶空間的緩衝區；

  4. CPU 負責將數據從用戶空間的緩衝區搬運到內核空間的 Socket 緩衝區中；

4 次上下文切換：

  1. read 系統調用時：用戶態切換到內核態；

  2. read 系統調用完畢：內核態切換回用戶態；

  3. write 系統調用時：用戶態切換到內核態；

  4. write 系統調用完畢：內核態切換回用戶態；

我們不免發出抱怨：

  1. CPU 全程負責內存內的數據拷貝還可以接受，因爲效率還算可以接受，但是如果要全程負責內存與磁盤、網絡的數據拷貝，這將難以接受，因爲磁盤、網卡的速度遠小於內存，內存又遠遠小於 CPU；

  2. 4 次 copy 太多了，4 次上下文切換也太頻繁了；

  3. DMA 參與下的數據四次拷貝

DMA 技術很容易理解，本質上，DMA 技術就是我們在主板上放一塊獨立的芯片。在進行內存和 I/O 設備的數據傳輸的時候，我們不再通過 CPU 來控制數據傳輸，而直接通過 DMA 控制器（DMA Controller，簡稱 DMAC）。這塊芯片，我們可以認爲它其實就是一個協處理器（Co-Processor）。

DMAC 最有價值的地方體現在，當我們要傳輸的數據特別大、速度特別快，或者傳輸的數據特別小、速度特別慢的時候。

比如說，我們用千兆網卡或者硬盤傳輸大量數據的時候，如果都用 CPU 來搬運的話，肯定忙不過來，所以可以選擇 DMAC。而當數據傳輸很慢的時候，DMAC 可以等數據到齊了，再發送信號，給到 CPU 去處理，而不是讓 CPU 在那裏忙等待。

注意，這裏面的 “協” 字。DMAC 是在“協助”CPU，完成對應的數據傳輸工作。在 DMAC 控制數據傳輸的過程中，我們還是需要 CPU 的進行控制，但是具體數據的拷貝不再由 CPU 來完成。

原本，計算機所有組件之間的數據拷貝（流動）必須經過 CPU，如下圖所示：

現在，DMA 代替了 CPU 負責內存與磁盤以及內存與網卡之間的數據搬運，CPU 作爲 DMA 的控制者，如下圖所示：

但是 DMA 有其侷限性，DMA 僅僅能用於設備之間交換數據時進行數據拷貝，但是設備內部的數據拷貝還需要 CPU 進行，例如 CPU 需要負責內核空間數據與用戶空間數據之間的拷貝（內存內部的拷貝），如下圖所示：

上圖中的 read buffer 也就是 page cache，socket buffer 也就是 Socket 緩衝區。

  1. 零拷貝技術

3.1 什麼是零拷貝技術？

零拷貝技術是一個思想 [3]，指的是指計算機執行操作時，CPU 不需要先將數據從某處內存複製到另一個特定區域。

可見，零拷貝的特點是 CPU 不全程負責內存中的數據寫入其他組件，CPU 僅僅起到管理的作用。但注意，零拷貝不是不進行拷貝，而是 CPU 不再全程負責數據拷貝時的搬運工作。如果數據本身不在內存中，那麼必須先通過某種方式拷貝到內存中（這個過程 CPU 可以不參與），因爲數據只有在內存中，才能被轉移，才能被 CPU 直接讀取計算。

零拷貝技術的具體實現方式有很多，例如：

不同的零拷貝技術適用於不同的應用場景，下面依次進行 sendfile、mmap、Direct I/O 的分析。

不過出於總結性的目的，我們在這裏先對下面的技術做一個前瞻性的總結。

3.2 sendfile

snedfile 的應用場景是：用戶從磁盤讀取一些文件數據後不需要經過任何計算與處理就通過網絡傳輸出去。此場景的典型應用是消息隊列。

在傳統 I/O 下，正如第一節所示，上述應用場景的一次數據傳輸需要四次 CPU 全權負責的拷貝與四次上下文切換，正如本文第一節所述。

sendfile 主要使用到了兩個技術：

  1. DMA 技術；

  2. 傳遞文件描述符代替數據拷貝；

下面依次講解這兩個技術的作用。

1. 利用 DMA 技術

sendfile 依賴於 DMA 技術，將四次 CPU 全程負責的拷貝與四次上下文切換減少到兩次，如下圖所示：

利用 DMA 技術減少 2 次 CPU 全程參與的拷貝

DMA 負責磁盤到內核空間中的 Page cache（read buffer）的數據拷貝以及從內核空間中的 socket buffer 到網卡的數據拷貝。

2. 傳遞文件描述符代替數據拷貝

傳遞文件描述可以代替數據拷貝，這是由於兩個原因：

利用傳遞文件描述符代替內核中的數據拷貝

注意事項：只有網卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技術纔可以通過傳遞文件描述符的方式避免內核空間內的一次 CPU 拷貝。這意味着此優化取決於 Linux 系統的物理網卡是否支持（Linux 在內核 2.4 版本里引入了 DMA 的 scatter/gather – 分散 / 收集功能，只要確保 Linux 版本高於 2.4 即可）。

3. 一次系統調用代替兩次系統調用

由於 sendfile 僅僅對應一次系統調用，而傳統文件操作則需要使用 read 以及 write 兩個系統調用。

正因爲如此，sendfile 能夠將用戶態與內核態之間的上下文切換從 4 次講到 2 次。

sendfile 系統調用僅僅需要兩次上下文切換

另一方面，我們需要注意 sendfile 系統調用的侷限性。如果應用程序需要對從磁盤讀取的數據進行寫操作，例如解密或加密，那麼 sendfile 系統調用就完全沒法用。這是因爲用戶線程根本就不能夠通過 sendfile 系統調用得到傳輸的數據。

3.3 mmap

mmap 技術在 [4] 中單獨展開，請移步閱讀。

3.4 Direct I/O

Direct I/O 即直接 I/O。其名字中的” 直接” 二字用於區分使用 page cache 機制的緩存 I/O。

“直接” 在這裏還有另一層語義：其他所有技術中，數據至少需要在內核空間存儲一份，但是在 Direct I/O 技術中，數據直接存儲在用戶空間中，繞過了內核。

Direct I/O 模式如下圖所示：

Direct I/O 示意圖

此時用戶空間直接通過 DMA 的方式與磁盤以及網卡進行數據拷貝。

Direct I/O 的讀寫非常有特點：

事實上，即使 Direct I/O 還是可能需要使用操作系統的 fsync 系統調用。爲什麼？

這是因爲雖然文件的數據本身沒有使用任何緩存，但是文件的元數據仍然需要緩存，包括 VFS 中的 inode cache 和 dentry cache 等。

在部分操作系統中，在 Direct I/O 模式下進行 write 系統調用能夠確保文件數據落盤，但是文件元數據不一定落盤。如果在此類操作系統上，那麼還需要執行一次 fsync 系統調用確保文件元數據也落盤。否則，可能會導致文件異常、元數據確實等情況。MySQL 的 O_DIRECT 與 O_DIRECT_NO_FSYNC 配置是一個具體案例 [9]。

Direct I/O 的優缺點：

（1）優點

  1. Linux 中的直接 I/O 技術省略掉緩存 I/O 技術中操作系統內核緩衝區的使用，數據直接在應用程序地址空間和磁盤之間進行傳輸，從而使得自緩存應用程序可以省略掉複雜的系統級別的緩存結構，而執行程序自己定義的數據讀寫管理，從而降低系統級別的管理對應用程序訪問數據的影響。

  2. 與其他零拷貝技術一樣，避免了內核空間到用戶空間的數據拷貝，如果要傳輸的數據量很大，使用直接 I/O 的方式進行數據傳輸，而不需要操作系統內核地址空間拷貝數據操作的參與，這將會大大提高性能。

（2）缺點

  1. 由於設備之間的數據傳輸是通過 DMA 完成的，因此用戶空間的數據緩衝區內存頁必須進行 page pinning（頁鎖定），這是爲了防止其物理頁框地址被交換到磁盤或者被移動到新的地址而導致 DMA 去拷貝數據的時候在指定的地址找不到內存頁從而引發缺頁錯誤，而頁鎖定的開銷並不比 CPU 拷貝小，所以爲了避免頻繁的頁鎖定系統調用，應用程序必須分配和註冊一個持久的內存池，用於數據緩衝。

  2. 如果訪問的數據不在應用程序緩存中，那麼每次數據都會直接從磁盤進行加載，這種直接加載會非常緩慢。

  3. 在應用層引入直接 I/O 需要應用層自己管理，這帶來了額外的系統複雜性；

誰會使用 Direct I/O？

IBM[5] 的一篇文章指出，自緩存應用程序（ self-caching applications）可以選擇使用 Direct I/O。

自緩存應用程序

對於某些應用程序來說，它會有它自己的數據緩存機制，比如，它會將數據緩存在應用程序地址空間，這類應用程序完全不需要使用操作系統內核中的高速緩衝存儲器，這類應用程序就被稱作是自緩存應用程序（ self-caching applications ）。

例如，應用內部維護一個緩存空間，當有讀操作時，首先讀取應用層的緩存數據，如果沒有，那麼就通過 Direct I/O 直接通過磁盤 I/O 來讀取數據。緩存仍然在應用，只不過應用覺得自己實現一個緩存比操作系統的緩存更高效。

數據庫管理系統是這類應用程序的一個代表。自緩存應用程序傾向於使用數據的邏輯表達方式，而非物理表達方式；當系統內存較低的時候，自緩存應用程序會讓這種數據的邏輯緩存被換出，而並非是磁盤上實際的數據被換出。自緩存應用程序對要操作的數據的語義瞭如指掌，所以它可以採用更加高效的緩存替換算法。自緩存應用程序有可能會在多臺主機之間共享一塊內存，那麼自緩存應用程序就需要提供一種能夠有效地將用戶地址空間的緩存數據置爲無效的機制，從而確保應用程序地址空間緩存數據的一致性。

另一方面，目前 Linux 上的異步 IO 庫，其依賴於文件使用 O_DIRECT 模式打開，它們通常一起配合使用。

如何使用 Direct I/O？

用戶應用需要實現用戶空間內的緩存區，讀 / 寫操作應當儘量通過此緩存區提供。如果有性能上的考慮，那麼儘量避免頻繁地基於 Direct I/O 進行讀 / 寫操作。

  1. 典型案例

4.1 Kakfa

Kafka 作爲一個消息隊列，涉及到磁盤 I/O 主要有兩個操作：

Kakfa 服務端接收 Provider 的消息並持久化的場景下使用 mmap 機制 [6]，能夠基於順序磁盤 I/O 提供高效的持久化能力，使用的 Java 類爲 java.nio.MappedByteBuffer。

Kakfa 服務端向 Consumer 發送消息的場景下使用 sendfile 機制 [7]，這種機制主要兩個好處：

使用 mmap 來對接收到的數據進行持久化，使用 sendfile 從持久化介質中讀取數據然後對外發送是一對常用的組合。但是注意，你無法利用 sendfile 來持久化數據，利用 mmap 來實現 CPU 全程不參與數據搬運的數據拷貝。

4.2 MySQL

MySQL 的具體實現比 Kakfa 複雜很多，這是因爲支持 SQL 查詢的數據庫本身比消息隊列對複雜很多。

MySQL 的零拷貝技術使用方式請移步我的另一篇文章 [8]。

  1. 總結

DMA 技術的推出使得內存與其他組件，例如磁盤、網卡進行數據拷貝時，CPU 僅僅需要發出控制信號，而拷貝數據的過程則由 DMA 負責完成。

Linux 的零拷貝技術有多種實現策略，但根據策略可以分爲如下幾種類型：

REFERENCE

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/_ZNrdsYAXWs8nBv1cfF1pA

猜你喜歡