使用異步I/O大大提升應用程序的性能

轉自：https://www.ibm.com/developerworks/cn/linux/l-async/

AIO簡介

Linux中最多見的輸入輸出（I/O）模型是同步I/O。在這個模型中，當請求發出以後，應用程序就會阻塞，直到請求知足爲止。這是很好的一種解決方案，由於調用應用程序在等待I/O請求完成時不須要使用任何中央處理單元（CPU）。可是在某些狀況中，I/O請求可能須要與其餘進程產生交疊。可移植操做系統接口（POSIX）異步I/O（AIO）應用程序接口（API）就提供了這種功能。在本文中，咱們將對這個API概要進行介紹。並來了解如何使用它。

LINUX異步I/O是linux內核中提供的一個至關新的加強。它是2.6版本內核的一個標準特性，可是咱們在2.4版本內核的補丁中也能夠找到它。AIO背後的基本思想是容許進程發起多個I/O操做，而不用阻塞或等待任何操做完成。稍微或在接收到I/O操做完成的通知時，進程就能夠檢索I/O操做的結果。

I/O模型

在深刻介紹AIO API以前，讓咱們先來探索一下linux上可使用的不一樣I/O模型。這並非一個詳盡的介紹，可是咱們將試圖介紹最多見的一些模型來解釋它們與異步I/O之間的區別。圖一給出了同步和異步模型，以及阻塞和非阻塞的模型。

每一個I/O模型都有本身的使用模式，它們對於特定的應用程序都有本身的優勢。本節將簡要對其意一一進行介紹。

同步阻塞I/O

最經常使用的一個模型是同步組賽I/O模型。在這個模型中，用戶空間的應用程序執行一個系統調用，這會致使應用程序阻塞。這意味着應用程序會一直阻塞，指導系統調用完成爲止（數據傳輸完成或發生錯誤）。調用應用程序處於一種再也不消費CPU而只是簡單等待響應的狀態，所以從處理的角度來看，這是很是有效的。

圖2給出了傳統的阻塞I/O模型，這也是目前應用程序中最爲經常使用的一種模型。其行爲很是容易理解，其用法對於典型的應用程序來講都很是有效。在調用read系統調用時，應用程序會阻塞並對內核進行上下文切換。而後會觸發讀操做，當響應返回時（從咱們正在從中讀取的設備中返回），數據就被移動到用戶空間的緩衝區中，而後應用程序就會解除阻塞（read調用返回）。

從應用程序的角度來講，read調用會延續很長時間。實際上，在內核執行讀操做和其其餘工做時，應用程序的確會被阻塞。

注：I/O密集型與CPU密集型進程的比較

I/O密集型進程所執行的I/O操做比執行的處理操做更多，

CPU密集型的進程所執行的處理操做比I/O操做更多。

LINUX2.6的調度器實際上更加偏心I/O密集型的進程，由於它們一般會發起一個I/O操做，而後進行阻塞，這就意味着其餘工做均可以在二者之間有效地交錯進行。

同步非阻塞I/O

同步阻塞I/O的一種效率稍低的變種是同步非阻塞I/O。在這個模型中，設備是以非阻塞的方式打開。這意味着I/O操做不會當即完成，read操做可能會返回一個錯誤代碼，說明這個命令不能當即知足（EAGAIN或EWOULDELOCK）,如圖3所示。

非阻塞的實現是I/O命令可能並不會當即知足，須要應用程序調用許屢次來等待操做完成。這可能效率不高，由於在不少狀況下，當內核執行這個命令時，應用程序必需要進行忙碌等待，直到數據可用爲止，或者試圖試行其餘工做。正如圖3所示的同樣，這個方法能夠引入I/O操做的延時，由於數據在內核中變爲可用到用戶調用read返回數據之間存在必定的間隔，這會致使總體數據吞吐量的下降。

異步阻塞I/O

另一個阻塞解決方案是帶有阻塞通知的非阻塞I/O。在這種模型中，配置是非阻塞I/O，而後使用select系統調用來肯定一個I/O描述符什麼時候有操做，使select調用很是有趣的是它能夠用來爲多個描述符提供通知，而不只僅爲了一個描述符提供通知。對於每一個描述符來講，咱們能夠請求這個描述符能夠寫數據、有讀數據可用以及是否發生錯誤的通知。

select調用的主要問題是它的效率不是很是高。儘管這是異步通知使用的一種方便模型，可是對於高性能的I/O操做來講不建議使用。

異步非阻塞I/O（AIO）

最後，異步非阻塞I/O模型是一種處理與I/O重疊進行的模型。讀請求會當即返回，說明read請求已經成功發起了。在後臺完成讀操做時，應用程序而後會執行其餘處理操做。當read的響應到達時，就會產生一個信號或執行一個基於線程的回調函數來完成此次I/O處理過程。

在一個進程張總爲了執行多個I/O請求而對計算操做和I/O處理進行重疊處理的能力利用了處理速度之間的差別。當一個或多個I/O請求掛起時，CPU能夠執行其餘任務；或者更爲常見是，在發起其餘I/O的同時對已經完成的I/O進行操做。

下節將深刻介紹這種模型，探索這個模型使用的API，而後展現幾個命令。

 

 異步I/O的動機

從前面的I/O模型的分類中，咱們能夠看出AIO的動機。這種阻塞模型須要在I/O操做開始時阻塞應用程序。這意味着不可能同時重疊進行處理和I/O操做。同步非阻塞模型容許處理和I/O操做重疊進行，可是這須要應用程序根據重現的規則來檢查I/O操做的狀態。這樣剩下異步非阻塞I/O了，它容許處理和I/O操做重疊進行，包括I/O操做完成的通知。

除了須要阻塞以外，select函數所提供的功能（異步阻塞I/O）與AIO相似。不過，它是對通知事件進行阻塞，而不是對I/O調用進行阻塞。

LINUX上的AIO簡介

本節探索LINUX的異步I/O模型，從而幫助咱們理解如何在應用程序中使用這種技術。

在傳統的I/O模型中，有一個使用惟一句柄標識的I/O通道。在UNIX中，這些句柄是文件描述符（這對等同與文件、管道、套接字等等）。

在阻塞I/O中，咱們發起了一次傳輸操做，當傳輸操做完成或發生錯誤時，系統調用就會返回。

在異步非阻塞I/O中，咱們能夠同時發起多個傳輸操做。這須要每一個傳輸操做都有惟一的上下文，這樣咱們才能在它們完成時區分究竟是哪一個傳輸操做完成了。在AIO中，這是一個aiocb（AIO I/O Control Block）結構。這個結構包含了有關傳輸的全部信息，包括爲數據準備的用戶緩衝區。在產生I/O（稱爲完成）通知時，aiocb結構就被用來唯一標識所完成的I/O操做。這個API的展現顯示瞭如何使用它。

注：Linux 上的 AIO   AIO 在 2.5 版本的內核中首次出現，如今已是 2.6 版本的產品內核的一個標準特性了。

AIO API

AIO 接口的 API 很是簡單，可是它爲數據傳輸提供了必需的功能，並給出了兩個不一樣的通知模型。表 1 給出了 AIO 的接口函數，本節稍後會更詳細進行介紹。

每一個API函數都使用aiocb結構開始或檢查。這個結構有不少元素，可是清單1僅僅給出了須要（或能夠）使用的元素。

sigevent結構告訴AIO在I/O操做完成時應該執行什麼操做。咱們將在AIO的展現中對結構進行探索。如今咱們展現各個AIO的API函數是如何工做的，以及咱們應該如何使用它們。

aio_read函數請求對一個有效的文件描述進行異步讀操做。這個文件描述能夠表示一個文件、管道、套接字。aio_read函數原型以下：

int aio_read(struct aiocb *aiocbp);

aio_read函數在請求進行排隊以後會當即返回。若是執行成功，返回值就爲0；若是出現錯誤，返回值就爲-1，並設置errno的值。

要執行讀操做，應用程序必須對aiocb結構初始化。下面這個簡短的例子就展示瞭如何填充aiocb請求結構，並使用aio_read來執行異步讀請求（如今暫時忽略通知）操做。它還展現了aio_error的用法，不過咱們將稍後再做解釋。

在清單 2 中，在打開要從中讀取數據的文件以後，咱們就清空了 aiocb 結構，而後分配一個數據緩衝區。並將對這個數據緩衝區的引用放到 aio_buf 中。而後，咱們將 aio_nbytes 初始化成緩衝區的大小。並將 aio_offset 設置成 0（該文件中的第一個偏移量）。咱們將 aio_fildes 設置爲從中讀取數據的文件描述符。在設置這些域以後，就調用 aio_read 請求進行讀操做。咱們而後能夠調用 aio_error 來肯定 aio_read 的狀態。只要狀態是 EINPROGRESS，就一直忙碌等待，直到狀態發生變化爲止。如今，請求可能成功，也可能失敗。

注意使用這個 API 與標準的庫函數從文件中讀取內容是很是類似的。除了 aio_read 的一些異步特性以外，另一個區別是讀操做偏移量的設置。在傳統的 read 調用中，偏移量是在文件描述符上下文中進行維護的。對於每一個讀操做來講，偏移量都須要進行更新，這樣後續的讀操做才能對下一塊數據進行尋址。對於異步 I/O 操做來講這是不可能的，由於咱們能夠同時執行不少讀請求，所以必須爲每一個特定的讀請求都指定偏移量。

注：使用 AIO 接口來編譯程序

咱們能夠在 aio.h 頭文件中找到函數原型和其餘須要的符號。在編譯使用這種接口的程序時，咱們必須使用 POSIX 實時擴展庫（librt）。

aio_error

aio_error 函數被用來肯定請求的狀態。其原型以下：

int aio_error(struct aiocb *aiocbp);

這個函數能夠返回如下內容：

• EINPROGRESS，說明請求還沒有完成
• ECANCELLED，說明請求被應用程序取消了
• -1，說明發生了錯誤，具體錯誤緣由能夠查閱 errn

aio_return

異步 I/O 和標準塊 I/O 之間的另一個區別是咱們不能當即訪問這個函數的返回狀態，由於咱們並無阻塞在 read 調用上。在標準的 read 調用中，返回狀態是在該函數返回時提供的。可是在異步 I/O 中，咱們要使用 aio_return 函數。這個函數的原型以下：

ssize_t aio_return(struct aiocb *aiocbp);

只有在aio_error調用肯定請求已經完成（可能成功，也可能發送了錯誤）以後，纔會調用這個函數。aio_return的返回值就等價於同步狀況中read或wirte系統調用的返回值（所傳輸的字節數，若是發生錯誤，返回值就爲-1）。

aio_write

aio_write函數用來請求一個異步寫操做。其函數原型以下：

int aio_write(struct aiocb *aiocbp);

aio_write 函數會當即返回，說明請求已經進行排隊（成功時返回值爲 0，失敗時返回值爲 -1，並相應地設置 errno）。

這與 read 系統調用相似，可是有一點不同的行爲須要注意。回想一下對於 read 調用來講，要使用的偏移量是很是重要的。然而，對於 write 來講，這個偏移量只有在沒有設置 O_APPEND 選項的文件上下文中才會很是重要。若是設置了 O_APPEND，那麼這個偏移量就會被忽略，數據都會被附加到文件的末尾。不然，aio_offset 域就肯定了數據在要寫入的文件中的偏移量。

aio_suspend

咱們可使用 aio_suspend 函數來掛起（或阻塞）調用進程，直到異步請求完成爲止，此時會產生一個信號，或者發生其餘超時操做。調用者提供了一個 aiocb 引用列表，其中任何一個完成都會致使 aio_suspend 返回。 aio_suspend 的函數原型以下：

int aio_suspend(const struct aiocb *const cblist[], int n, const struct timespec *timeout);

aio_suspend的使用很是簡單。咱們要提供一個aiocb引用列表。結果任何一個完成了，這個調用就會返回0，不然就會返回 -1，說明發生了錯誤。請參看清單 3。

注意，aio_suspend 的第二個參數是 cblist 中元素的個數，而不是 aiocb 引用的個數。cblist 中任何 NULL 元素都會被 aio_suspend 忽略。

若是爲 aio_suspend 提供了超時，而超時狀況的確發生了，那麼它就會返回 -1，errno 中會包含 EAGAIN。

aio_cancel

aio_cancel 函數容許咱們取消對某個文件描述符執行的一個或全部 I/O 請求。其原型以下：

int aio_cancel(int fd, struct aiocb *aiocb);

要取消一個請求，咱們須要提供文件描述符和 aiocb 引用。若是這個請求被成功取消了，那麼這個函數就會返回 AIO_CANCELED。若是請求完成了，這個函數就會返回 AIO_NOTCANCELED。

要取消對某個給定文件描述符的全部請求，咱們須要提供這個文件的描述符，以及一個對 aiocbp 的 NULL 引用。若是全部的請求都取消了，這個函數就會返回 AIO_CANCELED；若是至少有一個請求沒有被取消，那麼這個函數就會返回 AIO_NOT_CANCELED；若是沒有一個請求能夠被取消，那麼這個函數就會返回 AIO_ALLDONE。咱們而後可使用 aio_error 來驗證每一個 AIO 請求。若是這個請求已經被取消了，那麼 aio_error 就會返回 -1，而且 errno 會被設置爲 ECANCELED。

lio_listio

最後，AIO 提供了一種方法使用 lio_listio API 函數同時發起多個傳輸。這個函數很是重要，由於這意味着咱們能夠在一個系統調用（一次內核上下文切換）中啓動大量的 I/O 操做。從性能的角度來看，這很是重要，所以值得咱們花點時間探索一下。lio_listio API 函數的原型以下：

int lio_listio(int mode, struct aiocb *list[], int nent, struct sigevent *sig);

mode 參數能夠是 LIO_WAIT 或 LIO_NOWAIT。LIO_WAIT 會阻塞這個調用，直到全部的 I/O 都完成爲止。在操做進行排隊以後，LIO_NOWAIT就會返回。list 是一個 aiocb 引用的列表，最大元素的個數是由 nent 定義的。注意 list 的元素能夠爲 NULL，lio_listio 會將其忽略。sigevent 引用定義了在全部 I/O 操做都完成時產生信號的方法。

對於 lio_listio 的請求與傳統的 read 或 write 請求在必須指定的操做方面稍有不一樣，如清單 4 所示

對於讀操做來講，aio_lio_opcode 域的值爲 LIO_READ。對於寫操做來講，咱們要使用 LIO_WRITE，不過 LIO_NOP 對於不執行操做來講也是有效的。

AIO 通知

如今咱們已經看過了可用的 AIO 函數，本節將深刻介紹對異步通知可使用的方法。咱們將經過信號和函數回調來探索異步函數的通知機制。

使用信號進行異步通知

使用信號進行進程間通訊（IPC）是 UNIX 中的一種傳統機制，AIO 也能夠支持這種機制。在這種範例中，應用程序須要定義信號處理程序，在產生指定的信號時就會調用這個處理程序。應用程序而後配置一個異步請求將在請求完成時產生一個信號。做爲信號上下文的一部分，特定的 aiocb 請求被提供用來記錄多個可能會出現的請求。清單 5 展現了這種通知方法。

清單 5. 使用信號做爲 AIO 請求的通知

在清單 5 中，咱們在 aio_completion_handler 函數中設置信號處理程序來捕獲 SIGIO 信號。而後初始化 aio_sigevent 結構產生 SIGIO信號來進行通知（這是經過 sigev_notify 中的 SIGEV_SIGNAL 定義來指定的）。當讀操做完成時，信號處理程序就從該信號的 si_value 結構中提取出 aiocb，並檢查錯誤狀態和返回狀態來肯定 I/O 操做是否完成。

對於性能來講，這個處理程序也是經過請求下一次異步傳輸而繼續進行 I/O 操做的理想地方。採用這種方式，在一次數據傳輸完成時，咱們就能夠當即開始下一次數據傳輸操做。

使用回調函數進行異步通知

另一種通知方式是系統回調函數。這種機制不會爲通知而產生一個信號，而是會調用用戶空間的一個函數來實現通知功能。咱們在 sigevent結構中設置了對 aiocb 的引用，從而能夠唯一標識正在完成的特定請求。請參看清單 6。

在清單 6 中，在建立本身的 aiocb 請求以後，咱們使用 SIGEV_THREAD 請求了一個線程回調函數來做爲通知方法。而後咱們將指定特定的通知處理程序，並將要傳輸的上下文加載處處理程序中（在這種狀況中，是個對 aiocb 請求本身的引用）。在這個處理程序中，咱們簡單地引用到達的 sigval 指針並使用 AIO 函數來驗證請求已經完成。

對 AIO 進行系統優化

proc 文件系統包含了兩個虛擬文件，它們能夠用來對異步 I/O 的性能進行優化：

• /proc/sys/fs/aio-nr 文件提供了系統範圍異步 I/O 請求如今的數目。
• /proc/sys/fs/aio-max-nr 文件是所容許的併發請求的最大個數。最大個數一般是 64KB，這對於大部分應用程序來講都已經足夠了。

結束語

使用異步 I/O 能夠幫助咱們構建 I/O 速度更快、效率更高的應用程序。若是咱們的應用程序能夠對處理和 I/O 操做重疊進行，那麼 AIO 就能夠幫助咱們構建能夠更高效地使用可用 CPU 資源的應用程序。儘管這種 I/O 模型與在大部分 Linux 應用程序中使用的傳統阻塞模式都不一樣，可是異步通知模型在概念上來講卻很是簡單，能夠簡化咱們的設計。