本文介紹了對 Linux IO 子系統性能進行優化時需要考慮的因素，以及一些 IO 性能檢測工具。
本文的大部分内容來自 IBM Redbook - Linux Performance and Tuning Guidelines
FileSystem
VFS(Virtual FileSystem) 虛拟檔案系統
檔案系統是核心的功能，是一種工作在核心空間的軟體，通路一個檔案必須要需要檔案系統的存在才可以。Linux 可以支援多達數十種不同的檔案系統，它們的實作各不相同，是以 Linux 核心向使用者空間提供了虛拟檔案系統這個統一的接口用來對檔案系統進行操作。
虛拟檔案系統是位于使用者空間程序和核心空間中多種不同的底層檔案系統的實作之間的一個抽象的接口層，它提供了常見的檔案系統對象模型（如 i-node, file object, page cache, directory entry, etc.）和通路這些對象的方法（如 open, close, delete, write, read, create, fstat, etc.），并将它們統一輸出，類似于庫的作用。進而向使用者程序隐藏了各種不同的檔案系統的具體實作，這樣上層軟體隻需要和 VFS 進行互動而不必關系底層的檔案系統，簡化了軟體的開發，也使得 linux 可以支援多種不同的檔案系統。
Journaling
非日志型檔案系統
在非日志型檔案系統中，對檔案系統實施一個寫操作，核心會首先修改對應的中繼資料，然後修改資料塊。如果在寫入中繼資料時，檔案系統發生崩潰或某種故障，那麼資料的一緻性将會遭到破壞。fsck 指令可以在下次重新開機時檢查所有的中繼資料并修複資料一緻性，但是如果檔案系統非常大，或者系統運作關鍵業務不允許停機，使用非日志型檔案系統的風險會非常高。
日志型檔案系統
日志型檔案系統的差別在于，在進行對檔案系統寫資料之前，寫将資料寫到「日志區」，然後再寫入檔案系統，在寫入檔案系統之後删除日志。日志區可以在檔案系統内部也可以在檔案系統外部。日志區的資料稱作檔案系統日志，這些資料包含了修改了的中繼資料，也可能包含将要修改的資料。寫日志也會帶來一定的額外開銷。
EXT2
ext2 檔案系統組成不再贅述，需要注意的是 ext2 檔案系統沒有日志功能。
EXT3
ext3 是帶有日志功能檔案系統，它基于ext2檔案系統實作。
- 以一緻性的方式寫入資料，即使斷電或檔案系統崩潰，恢複的時間會大大減少
- 資料完整性：在挂載時指定選項
data=journal
- 速度：指定挂載選項
data=writeback
- 靈活性：可以從 ext2 系統更新，而不需要重新格式化檔案系統，也可以以非日志模式挂載，就如同 ext2 一樣
ext3的日志模式
- journal，提供最大資料完整性，日志會記錄中繼資料和檔案資料
- ordered，日志隻記錄中繼資料。但是會保證檔案資料先被寫入，這是預設選項。
- writeback，使用回寫的方式寫資料，隻保證記錄中繼資料至日志。
其他檔案系統
- ReiserFS，ReiserFS是一個快速的日志型檔案系統，有着良好的磁盤空間使用和快速的崩潰恢複。屬于 Novell 公司，在 SUSE Linux 中使用。
- JFS (Journal File System)， JFS 是一個完全 64 位檔案系統，可以支援非常大的檔案和分區，早先由 IBM 公司為 AIX 作業系統開發，現已使用 GPL 協定開源。JFS适用于非常大的分區和檔案如 HPC 或者資料庫業務。
- XFS (eXtended File System)， 一個高性能的日志型檔案系統，和 JFS 比較相似。
I/O子系統架構
上圖概括了一次磁盤 write 操作的過程，假設檔案已經被從磁盤中讀入了 page cache 中
- 一個使用者程序通過 write() 系統調用發起寫請求
- 核心更新對應的 page cache
- pdflush 核心線程将 page cache 寫入至磁盤中
- 檔案系統層将每一個 block buffer 存放為一個 bio 結構體，并向塊裝置層送出一個寫請求
- 塊裝置層從上層接受到請求，執行 IO 排程操作，并将請求放入IO 請求隊列中
- 裝置驅動（如 SCSI 或其他裝置驅動）完成寫操作
- 磁盤裝置固件執行對應的硬體操作，如磁盤的旋轉，尋道等，資料被寫入到磁盤扇區中
Block Layer
Block layer 處理所有和塊裝置相關的操作。block layer 最關鍵是資料結構是 bio 結構體。bio 結構體是 file system layer 到 block layer 的接口。 當執行一個寫操作時，檔案系統層将資料寫入 page cache（由 block buffer 組成），将連續的塊放到一起，組成 bio 結構體，然後将 bio 送至 block layer。
block layer 處理 bio 請求，并将這些請求連結成一個隊列，稱作 IO 請求隊列，這個連接配接的操作就稱作 IO 排程（也叫 IO elevator 即電梯算法）.
IO scheduler
IO 排程器的總體目标是減少磁盤的尋道時間（是以排程器都是針對機械硬碟進行優化的），IO 排程器通過兩種方式來減少磁盤尋道：合并和排序。
合并即當兩個或多個 IO 請求的是相鄰的磁盤扇區，那麼就将這些請求合并為一個請求。通過合并請求，多個 IO 請求隻需要向磁盤發送一個請求指令，減少了磁盤的開銷。
排序就是将不能合并的 IO 請求，根據請求磁盤扇區的順序，在請求隊列中進行排序，使得磁頭可以按照磁盤的旋轉順序的完成 IO 操作，可以減小磁盤的尋道次數。
排程器的算法和電梯運作的政策相似，是以 IO 排程器也被稱作 IO 電梯( IO Elevator )。由于對請求進行了重排，一部分的請求可能會被延遲，以提升整體的性能。
Linux 2.4 隻使用了一種通用的 IO 算法。到 Linux 2.6 實作了 4 種 IO 排程模型，其中 anticipatory 在 2.6.33 中被移除。
Linus Elevator
早先的 IO 排程器就叫做 Linus Elevator，當一個請求被加入到請求隊列中，它首先檢查隊列中是否存在相鄰的請求以合并兩個請求，這可能包含前合并和後合并。如果不能合并，則尋找是否能夠将新請求按扇區順序插入到請求隊列，如果沒有找到适合插入的位置，那麼就将這個請求插入到隊列的末尾。另外，如果請求隊列中的某個請求超過的預先定義的過期門檻值，新請求即使可以進行排序，也被插入到隊列的末尾。這樣可以防止磁盤上某個區域産生大量請求，而其他區域的請求被餓死。然而，這種過期政策并不十分高效。
這種算法可能導緻請求餓死的情況，它是 Linux 2.4 的唯一排程器。
當一個請求加入到請求隊列時，IO 排程器所完成的操作如下
- 如果隊列中存在對相鄰扇區的請求，則合并兩個請求為一個
- 如果隊列中存在超過過期時間的請求，那麼新請求被插入到隊列的末尾，以防止餓死老的請求
- 如果隊列中存在可以按扇區位址排序的合适位置，那麼将請求插入到這個位置
- 如果隊列中沒有合适的可插入位置，請求被插入到隊列末尾
Deadline - latency-oriented
Deadline 排程器是設計用來解決 Linus Elevator 導緻的 I/O 餓死的問題。對磁盤上某個區域的大量請求，會無限期的餓死 (starvation) 對磁盤其他區域上的請求。
請求餓死的一個特例是 寫請求餓死讀請求 (writes starving reads)，對于程序來說，當需要進行寫操作時，由于需要寫的資料在記憶體的 page cache 中，程序是需要修改對應的記憶體，向核心發送寫請求即可，之後程序可以去進行其他操作，由核心負責将資料同步至磁盤中即可。對于程序來說，寫請求是異步操作。而讀操作是完全不同的，當程序需要讀取資料時，需要向核心發送讀請求，核心将資料載入到記憶體中，由于程序往往需要處理讀取的資料，是以程序将處于阻塞狀态，直到請求被處理完成。對于程序來說，讀請求是同步的操作。寫請求延遲對系統的性能影響不大，而讀請求延遲對系統性能影響是非常大的，是以兩種 IO 請求需要差別對待。
Dealine 排程器專門針對讀請求延遲進行了優化，在 deadline 算法中，每一個請求都有一個過期時間。預設情況下，讀請求的過期時間是 500ms，寫請求的過期時間是 5s。Dealine 排程器也會對請求隊列進行合并和排序操作，這個隊列稱作排序隊列（sorted queue）。當新請求被送出，Deadline将其加入到排序隊列中進行合并和排序。同時 Deadline 将這個請求加入到第二種類型的隊列中，讀請求被加入至讀FIFO隊列 (Read FIFO queue)，寫請求被加入到寫FIFO隊列 (Write FIFO queue)，這兩個隊列中，請求完全按照 FIFO 順序排列，即新請求永遠被放入到隊列的末尾。
這樣一來 Dealine 就維護三個隊列，正常情況下，Deadline 将排序隊列中的請求放入到排程隊列 (dispatch queue，即将寫入磁盤的隊列)中，排程隊列把請求發送至磁盤驅動。如果寫 FIFO 隊列或讀 FIFO 隊列中的請求發生了逾時，Deadline 排程器就不再使用排序隊列，而是開始将發生逾時的 FIFO 隊列的請求放入排程隊列，直至隊列中沒有逾時的請求，Deadline 通過這樣的方式保證所有的請求都不會長時間逾時。
Deadling 防止了請求餓死的出現，由于讀請求的逾時時間遠小于寫請求，它同時也避免了出現寫請求餓死讀請求。
Deadline 比較适合于MySQL資料庫。
Anticipatory(AS)
AS 排程器是基于 Deadline 排程器，加上了一個啟發式的「預測」，假設系統中有大量的寫請求，這時如果夾雜幾個讀請求，由于讀請求的過期時間短，讀請求立即在多個寫請求的中間産生，這樣會導緻磁盤的來回尋道，AS 試圖減少大量寫請求夾雜少量讀請求産生的尋道風暴（seek storm）。當一個讀請求完成後，AS不會立即傳回處理隊列中的剩餘請求，而是等待一個預測時間（預設為 6ms），如果等待的時間内發生了相鄰位置的讀請求，那麼立即處理這個相鄰位置的讀請求，再傳回處理隊列中的請求，這樣可以優化多餘的尋道時間。
它可以為連續 IO 請求（如順序讀）進行了一定的優化，但是對于随機讀的場景 AS 會産生較大的延遲，對于資料庫應用很糟糕，而對于 Web Server 可能會表現的不錯。這個算法也可以簡單了解為面向低速磁盤的，對于使用了 TCG（Tagged Command Queueing）高性能的磁盤和 RAID，使用 AS 會降低性能。
在 Linux 2.6 - 2.6.18 AS 是核心預設排程器，然而大多數的企業發行版選擇的是 CFQ 排程器。
到Linux 2.6.33 版本，AS 被從核心中移除，因為可以通過調整其他排程器（如 CFQ）來實作與其相似的功能。
Complete Fair Queuing（CFQ）- fairness-oriented
CFQ 為每個程序配置設定一個 I/O 請求隊列，在每個隊列的内部，進行合并和排序的優化。CFQ 以輪詢的方式處理這些隊列，每次從一個隊列中處理特定數量的請求（預設為 4 個）。它試圖将 I/O 帶寬均勻的配置設定至每個程序。CFQ 原本針對的是多媒體或桌面應用場景，然而，CFQ 其實在許多場景中内表現的很好。CFQ 對每一個 IO 請求都是公平的。這使得 CFQ 很适合離散讀的應用 (eg: OLTP DB)
多數企業發型版選擇 CFQ 作為預設的 I/O 排程器。
NOOP(No Operation)
該算法實作了最簡單的 FIFO 隊列，所有 IO 請求按照大緻的先後順序進行操作。之是以說「大緻」，原因是 NOOP 在 FIFO 的基礎上還做了相鄰 IO 請求的合并，但其不會進行排序操作。
NOOP 适用于底層硬體自身就具有很強排程控制器的塊裝置（如某些SAN裝置），或者完全随機通路的塊裝置（如SSD）。
各個排程器在資料庫應用下的性能，可以看出CFQ的性能是比較均衡的
IO 參數調整
隊列長度
檢視隊列長度
/sys/block/<dev>/queue/nr_requests
下圖展示了各種隊列長度時，Deadline 和 CFQ 排程器的性能
由 ext3 的表現可以看出，對于大量的小檔案寫操作，隊列長度更長，性能會有所提升，在 16KB 左右，性能提升最為明顯，在 64KB 時，64 至 8192 的隊列長度有着差不多的性能。随着檔案大小的增大，小隊列長度反而有着更好的性能。 RHEL 作業系統中，每個裝置有一個隊列長度。對于類似資料庫日志的存放分區，大部分寫操作屬于小檔案 IO，可以将隊列長度調小。
對于大量的連續讀取，可以考慮增加讀取首部的視窗大小
/sys/block/<dev>/queue/read_ahead_kb
IO排程器
選擇裝置的IO排程器
/sys/block/<dev>/queue/scheduler
或者在 grub.conf 中加入核心參數
elevator=SCHEDULER
Deadline參數
/sys/block/<device>/queue/iosched/writes_starved
進行一個寫操作之前，允許進行多少次讀操作
/sys/block/<device>/queue/iosched/read_expire
讀請求的過期時間
/sys/block/<device>/queue/iosched/read_expire
寫請求的過期時間，預設為 500ms
/sys/block/sda/queue/iosched/front_merges
是否進行前合并
Anticipatory參數
/sys/block/<device>/queue/iosched/antic_expire
預測等待時長，預設為 6ms
/sys/block/<device>/queue/iosched/{write_expire,read_expire}
讀寫請求的逾時時長
/sys/block/<device>/queue/iosched/{write_batch_expire,read_batch_expire}
讀寫的批量處理時長
CFQ參數
/sys/block/<device>/queue/iosched/slice_idle
當一個程序的隊列被配置設定到時間片卻沒有 IO 請求時，排程器在輪詢至下一個隊列之前的等待時間，以提升 IO 的局部性，對于 SSD 裝置，可以将這個值設為 0。
/sys/block/<device>/queue/iosched/quantum
一個程序的隊列每次被處理 IO 請求的最大數量，預設為 4，RHEL6 為 8，增大這個值可以提升并行處理 IO 的性能，但可能會造成某些 IO 延遲問題。
/sys/block/<device>/queue/iosched/slice_async_rq
一次處理寫請求的最大數
/sys/block/<device>/queue/iosched/low_latency
如果IO延遲的問題很嚴重，将這個值設為 1
調整CFQ排程器的程序IO優先級
$ ionice [[-c class] [-n classdata] [-t]] -p PID [PID]...
$ ionice [-c class] [-n classdata] [-t] COMMAND [ARG]...
CFQ 的程序 IO 優先級和程序 CPU 優先級是獨立的。使用 ionice 調整程序優先級，有三種排程類型可以選擇
-
idle
隻有在沒有更高優先級的程序産生 IO 時，idle 才可以使用磁盤 IO，适用于哪些不重要的程式（如 updatedb），讓它們在磁盤空閑時再産生 IO
-
Best-effort
這個類型共有 8 個優先級，分别為 0-7，數字越低，優先級越高，相同級别的優先級使用輪詢的方式處理。适用于普通的程序。
在2.6.26之前，沒有指定排程類型的程序使用"none" 排程類型，IO排程器将其視作Best-effort進行處理，這個類别中程序優先級由CPU優先級計算得來: io_priority = (cpu_nice + 20) / 5
2.6.26之後，沒有指定排程類型的程序将從CPU排程類型繼承而來，這個類别的優先級仍按照CPU優先級計算而來: io_priority = (cpu_nice + 20) / 5
-
Real time
這個排程級别的程序産生的IO被優先處理，這個排程類型應小心使用，防止餓死其他程序IO, 它也有8個優先級，數字越大分的的IO時間片越長
檔案系統
一般來說 ReiserFS 更适合于小檔案 IO，而 XFS 和 JFS 适合大檔案 IO，ext4 則處于兩種之間。
JFS 和 XFS 适用于大型的資料倉庫，科學計算，大型 SMP 伺服器，多媒體流服務等。ReiserFS 和 Ext4 适合于檔案伺服器，Web 伺服器或郵件伺服器。
noatime
atime 用于記錄檔案最後一次被讀取的時間。預設情況下，檔案每次被讀取或修改（也需要先讀取），系統将更新 atime 并寫入至檔案中繼資料中。由于寫操作是很昂貴的，減少不必要的寫操作可以提升磁盤性能。然後，大多數時候，關閉檔案的 atime 也隻能獲得非常小的性能提升（這個說法來自于IBM Redbook，表示懷疑）。
使用 noatime 挂載檔案系統，将不對檔案的 atime 進行更新，此時 atime就相當于 mtime。磁盤性能可以得到0-10%的提升。
使用 noatime挂載方法
/dev/sdb1 /mountlocation ext3 defaults,noatime 1 2
nobarrier
barrier 是保證日志檔案系統的 WAL (write ahead logging) 一種手段，資料寫入磁盤時，理應先寫入 journal 區，再寫入資料在磁盤的實際對應位置，磁盤廠商為了加快磁盤寫入速度，磁盤都内置 cache，資料一般都先寫入磁盤的 cache。
cache 能加快寫入速度，但磁盤一般會對 cache 内緩存資料排序使之最優重新整理到磁盤，這樣就可能導緻要重新整理的實際資料和 journal 順序錯亂。一旦系統崩潰，下次開機時磁盤要參考 journal 區來恢複，但此時 journal 記錄順序與資料實際重新整理順序不同就會導緻資料反而「恢複」到不一緻了。而barrier 如其名——「栅欄」，先加一個「栅欄」，保證 journal 總是先寫入記錄，然後對應資料才重新整理到磁盤，這種方式保證了系統崩潰後磁盤恢複的正确性，但對寫入性能有影響。
資料庫伺服器底層儲存設備要麼采用 RAID 卡，RAID 卡本身的電池可以掉電保護；要麼采用 Flash 卡，它也有自我保護機制，保證資料不會丢失。是以我們可以安全的使用 nobarrier 挂載檔案系統。設定方法如下： 對于 ext3，ext4 和 reiserfs 檔案系統可以在 mount 時指定 barrier=0；對于 xfs 可以指定 nobarrier 選項。
read-ahead 預讀
Linux 把讀模式分為随機讀和順序讀兩大類，并隻對順序讀進行預讀。這一原則相對保守，但是可以保證很高的預讀命中率。
為了保證預讀命中率，Linux隻對順序讀 (sequential read) 進行預讀。核心通過驗證如下兩個條件來判定一個 read() 是否順序讀：
- 這是檔案被打開後的第一次讀，并且讀的是檔案首部；
- 目前的讀請求與前一（記錄的）讀請求在檔案内的位置是連續的。
如果不滿足上述順序性條件，就判定為随機讀。任何一個随機讀都将終止目前的順序序列，進而終止預讀行為（而不是縮減預讀大小）。
預讀視窗
Linux采用了一個快速的視窗擴張過程
- 首次預讀：
readahead_size = read_size * 2 // or *4
- 後續預讀：
readahead_size *= 2
檢視和修改預讀視窗
$ blockdev -getra device
$ blockdev -setra N device
日志模式
大多數檔案系統可以設定三種日志模式，對于 ext4 檔案系統，日志模式對磁盤的性能有較大的影響。
-
data=journal
-
data=ordered
(預設)
隻記錄中繼資料，然後它會保證先将資料寫入磁盤
-
data=writeback
将日志放在單獨的裝置中
- 解除安裝檔案系統
- 檢視檔案系統塊大小和日志參數
$ dumpe2fs /dev/sdb1
- 移除檔案系統内部的日志區
$ tune2fs -O ^has_journal /dev/sdb1
- 建立外部的日志裝置
$ mke2fs –O journal_dev -b block-size /dev/sdc1
- 更新原檔案系統的超級塊
$ tune2fs -j -J device=/dev/sdc1 /dev/sdb1
commit
設定多少秒從日志中進行一個同步，預設是5
優化Ext4
-
格式大檔案系統化時延遲 inode 的寫入
對于超大檔案系統，mkfs.ext4 程序要花很長時間初始化檔案系統中到所有内節點表。
可使用
-E lazy_itable_init=1
$ mkfs.ext4 -E lazy_itable_init=1 /dev/sda5
- 關閉Ext4的自動 fsync() 調用
-o noauto_da_alloc
mount -o noauto_da_alloc
- 降低日志IO的優先級至與資料IO相同
-o journal_ioprio=n
檢視檔案系統鎖
$ cat /proc/locks
Benchmark 基準測試
iozone
使用iozone對檔案系統進行基準測試
-
$ iozone -a
-
$ iozone -Ra
iozone -Rab output.xls
-
$ iozone -Ra -g 2g
$ iozone -Ra -g 2g -i 0 -i 1
如果隻關心檔案磁盤的read/write性能，而不必花費時間在其他模式上測試，則我們需要指定測試模式
$ iozone -Rac
如果測試NFS，将使用-c，這通知iozone在測試過程中執行close()函數。使用close()将減少NFS用戶端緩存的影響。但是如果測試檔案比記憶體大，就沒有必要使用參數-c
一個例子
dd
$ dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync
使用這個參數，dd指令執行到最後會真正執行一次同步(sync)操作
$ dd bs=1M count=128 if=/dev/zero of=test oflag=direct
使用直接IO（繞過緩存）
bonnie++
-d 生成測試檔案的路徑
-s 生成測試檔案的大小，以M為機關（如果不使用-r參數，則要求檔案大小至少是系統實體記憶體的2倍） -m 機器名，實際上我們可以認為是本次測試的方案名，可以随便定義。預設是本機的hostname。 -r 記憶體大小，指定記憶體大小，這樣可以通過-s參數建立r*2大小的檔案，通常用于縮短測試時間，但是需要注意這樣由于記憶體的cache可能導緻測試結果的不準确 -x 測試的次數 -u 測試檔案的屬主群組，預設是執行bonnie++的目前使用者和目前組 -g 測試檔案的組，預設是執行bonnie++的目前用組 -b 在每次寫檔案時調用fsync()函數，對于測試郵件伺服器或者資料庫伺服器這種通常需要同步操作的情況比較适合，而不使用該參數則比較适合測試copy檔案或者編譯等操作的效率。
可以簡單地運作如下指令進行磁盤性能測試：
$ bonnie++ -d /global/oradata –m sun3510
這樣将會在指定的目錄下（通常我們會指定一個盤陣上卷的挂載點），生成相當于主機實體記憶體兩倍的檔案，如果總量大于1G，則生成多個大小為1G的檔案。假設主機記憶體為4G，那麼在測試中就會生成8個1G的檔案，到測試結束，這些檔案會被自動删除。
如果我們的主機記憶體是4G，但是我們想縮短測試的時間，比如說隻寫2G的檔案，就應該執行下面的指令：
$ bonnie++ -d /global/oradata –m sun3510 –s 2048 –r 1024
blktrace & blkparse
blktrace 是一個針對 Linux 核心中塊裝置 IO 層的跟蹤工具，用來收集磁盤IO 資訊中當 IO 進行到塊裝置層（block層，是以叫blk trace）時的詳細資訊（如 IO 請求送出，入隊，合并，完成等等一些列的資訊），blktrace 需要借助核心經由 debugfs 檔案系統（debugf s檔案系統在記憶體中）來輸出資訊，是以用 blktrace 工具之前需要先挂載 debugfs 檔案系統，blktrace需要結合 blkparse 來使用，由 blkparse 來解析 blktrace 産生的特定格式的二進制資料。
blktrace文法：
檔案輸出
$ blktrace –d /dev/sda –o trace
解析結果
$ blkparse -i trace -o /root/trace.txt
FIO
FIO 是測試 IOPS 的非常好的工具，用來對硬體進行壓力測試和驗證，支援 13 種不同的 IO 引擎，包括：sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等。
随機讀
說明
順序讀
随機寫
順序寫
混合随機讀寫
stress
它可以給我們的系統施加 CPU，記憶體，IO 和磁盤的壓力，在模拟極端場景給應用系統造成的壓力方面很有幫助。
示例
$ stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10d
參考：
-
- Linux Performance and Tuning Guidelines
- Red Hat Enterprise Linux 6 Performance Tuning Guide
- Choosing an I/O Scheduler for Red Hat® Enterprise Linux® 4 and the 2.6 Kernel
- RHEL 的 I/O 排程器(Scheduler)與 Database 的關系 I/O Schedulers
轉載于:https://www.cnblogs.com/bodhitree/p/5753208.html