[[155493]]

本文的大部分內(nèi)容來自 IBM Redbook - Linux Performance and Tuning Guidelines 。

FileSystem

　　VFS(Virtual FileSystem) 虛擬文件系統(tǒng)

　　文件系統(tǒng)是內(nèi)核的功能，是一種工作在內(nèi)核空間的軟件，訪問一個文件必須需要文件系統(tǒng)的存在才可以。Linux 可以支持多達數(shù)十種不同的文件系統(tǒng)，它們的實現(xiàn)各不相同，因此 Linux 內(nèi)核向用戶空間提供了虛擬文件系統(tǒng)這個統(tǒng)一的接口用來對文件系統(tǒng)進行操作。

　　虛擬文件系統(tǒng)是位于用戶空間進程和內(nèi)核空間中多種不同的底層文件系統(tǒng)的實現(xiàn)之間的一個抽象的接口層，它提供了常見的文件系統(tǒng)對象模型(如 i-node，file object，page cache，directory entry，etc.)和訪問這些對象的方法(如 open, close, delete, write, read, create, fstat, etc.)，并將它們統(tǒng)一輸出，類似于庫的作用。從而向用戶進程隱藏了各種不同的文件系統(tǒng)的具體實現(xiàn)，這樣上層軟件只需要和 VFS 進行交互而不必關(guān)系底層的文件系統(tǒng)，簡化了軟件的開發(fā)，也使得 linux 可以支持多種不同的文件系統(tǒng)。

　　Journaling

　　非日志型文件系統(tǒng)

　　在非日志型文件系統(tǒng)中，對文件系統(tǒng)實施一個寫操作，內(nèi)核會首先修改對應(yīng)的元數(shù)據(jù)，然后修改數(shù)據(jù)塊。如果在寫入元數(shù)據(jù)時，文件系統(tǒng)發(fā)生崩潰或某種故障，那么數(shù)據(jù)的一致性將會遭到破壞。fsck 命令可以在下次重啟時檢查所有的元數(shù)據(jù)并修復數(shù)據(jù)一致性，但是如果文件系統(tǒng)非常大，或者系統(tǒng)運行關(guān)鍵業(yè)務(wù)不允許停機，使用非日志型文件系統(tǒng)的風險會非常高。

　　日志型文件系統(tǒng)

　　日志型文件系統(tǒng)的區(qū)別在于，在進行對文件系統(tǒng)寫數(shù)據(jù)之前，寫將數(shù)據(jù)寫到“日志區(qū)”，然后再寫入文件系統(tǒng)，在寫入文件系統(tǒng)之后刪除日志。日志區(qū)可以在文件系統(tǒng)內(nèi)部也可以在文件系統(tǒng)外部。日志區(qū)的數(shù)據(jù)稱作文件系統(tǒng)日志，這些數(shù)據(jù)包含了修改了的元數(shù)據(jù)，也可能包含將要修改的數(shù)據(jù)。寫日志也會帶來一定的額外開銷。

　　EXT2

　　ext2 文件系統(tǒng)組成不再贅述，需要注意的是 ext2 文件系統(tǒng)沒有日志功能。

　　EXT3

　　ext3 是帶有日志功能文件系統(tǒng)，它基于ext2文件系統(tǒng)實現(xiàn)。

　　以一致性的方式寫入數(shù)據(jù)，即使斷電或文件系統(tǒng)崩潰，恢復的時間會大大減少。

　　◆數(shù)據(jù)完整性：在掛載時指定選項 data=journal 則可以使日志記錄下元數(shù)據(jù)和文件數(shù)據(jù)。

　　◆速度：指定掛載選項 data=writeback 使用回寫的方式寫數(shù)據(jù)。

　　◆靈活性：可以從 ext2 系統(tǒng)升級，而不需要重新格式化文件系統(tǒng)，也可以以非日志模式掛載，就如同 ext2 一樣。

　　ext3的日志模式

　　◆journal，提供***數(shù)據(jù)完整性，日志會記錄元數(shù)據(jù)和文件數(shù)據(jù)。

　　◆ordered，日志只記錄元數(shù)據(jù)。但是會保證文件數(shù)據(jù)先被寫入，這是默認選項。

　　◆writeback，使用回寫的方式寫數(shù)據(jù)，只保證記錄元數(shù)據(jù)至日志。

　　其他文件系統(tǒng)

　　◆ReiserFS，ReiserFS是一個快速的日志型文件系統(tǒng)，有著良好的磁盤空間使用和快速的崩潰恢復。屬于 Novell 公司，在 SUSE Linux 中使用。

　　◆JFS (Journal File System)， JFS 是一個完全 64 位文件系統(tǒng)，可以支持非常大的文件和分區(qū)，早先由 IBM 公司為 AIX 操作系統(tǒng)開發(fā)，現(xiàn)已使用 GPL 協(xié)議開源。JFS適用于非常大的分區(qū)和文件如 HPC 或者數(shù)據(jù)庫業(yè)務(wù)。

　　◆XFS (eXtended File System)， 一個高性能的日志型文件系統(tǒng)，和 JFS 比較相似。

#p#

　　I/O子系統(tǒng)架構(gòu)

　　上圖概括了一次磁盤 write 操作的過程，假設(shè)文件已經(jīng)被從磁盤中讀入了 page cache 中。

　　1.一個用戶進程通過 write() 系統(tǒng)調(diào)用發(fā)起寫請求。

　　2.內(nèi)核更新對應(yīng)的 page cache。

　　3.pdflush 內(nèi)核線程將 page cache 寫入至磁盤中。

　　4.文件系統(tǒng)層將每一個 block buffer 存放為一個 bio 結(jié)構(gòu)體，并向塊設(shè)備層提交一個寫請求。

　　5.塊設(shè)備層從上層接受到請求，執(zhí)行 IO 調(diào)度操作，并將請求放入IO 請求隊列中。

　　6.設(shè)備驅(qū)動(如 SCSI 或其他設(shè)備驅(qū)動)完成寫操作。

　　7.磁盤設(shè)備固件執(zhí)行對應(yīng)的硬件操作，如磁盤的旋轉(zhuǎn)，尋道等，數(shù)據(jù)被寫入到磁盤扇區(qū)中。

　　Block Layer

　　Block layer 處理所有和塊設(shè)備相關(guān)的操作。block layer 最關(guān)鍵是數(shù)據(jù)結(jié)構(gòu)是 bio 結(jié)構(gòu)體。bio 結(jié)構(gòu)體是 file system layer 到 block layer 的接口。 當執(zhí)行一個寫操作時，文件系統(tǒng)層將數(shù)據(jù)寫入 page cache(由 block buffer 組成)，將連續(xù)的塊放到一起，組成 bio 結(jié)構(gòu)體，然后將 bio 送至 block layer。

　　block layer 處理 bio 請求，并將這些請求鏈接成一個隊列，稱作 IO 請求隊列，這個連接的操作就稱作 IO 調(diào)度(也叫 IO elevator 即電梯算法)。

　　IO scheduler

　　IO 調(diào)度器的總體目標是減少磁盤的尋道時間(因此調(diào)度器都是針對機械硬盤進行優(yōu)化的)，IO 調(diào)度器通過兩種方式來減少磁盤尋道：合并和排序。

　　合并即當兩個或多個 IO 請求的是相鄰的磁盤扇區(qū)，那么就將這些請求合并為一個請求。通過合并請求，多個 IO 請求只需要向磁盤發(fā)送一個請求指令，減少了磁盤的開銷。

　　排序就是將不能合并的 IO 請求，根據(jù)請求磁盤扇區(qū)的順序，在請求隊列中進行排序，使得磁頭可以按照磁盤的旋轉(zhuǎn)順序的完成 IO 操作，可以減小磁盤的尋道次數(shù)。

　　調(diào)度器的算法和電梯運行的策略相似，因此 IO 調(diào)度器也被稱作 IO 電梯( IO Elevator )。由于對請求進行了重排，一部分的請求可能會被延遲，以提升整體的性能。

　　Linux 2.4 只使用了一種通用的 IO 算法。到 Linux 2.6 實現(xiàn)了 4 種 IO 調(diào)度模型，其中 anticipatory在 2.6.33 中被移除。

　　Linus Elevator

　　早先的 IO 調(diào)度器就叫做 Linus Elevator，當一個請求被加入到請求隊列中，它首先檢查隊列中是否存在相鄰的請求以合并兩個請求，這可能包含前合并和后合并。如果不能合并，則尋找是否能夠?qū)⑿抡埱蟀瓷葏^(qū)順序插入到請求隊列，如果沒有找到適合插入的位置，那么就將這個請求插入到隊列的末尾。另外，如果請求隊列中的某個請求超過的預(yù)先定義的過期閾值，新請求即使可以進行排序，也被插入到隊列的末尾。這樣可以防止磁盤上某個區(qū)域產(chǎn)生大量請求，而其他區(qū)域的請求被餓死。然而，這種過期策略并不十分高效。

　　這種算法可能導致請求餓死的情況，它是 Linux 2.4 的唯一調(diào)度器。

　　當一個請求加入到請求隊列時，IO 調(diào)度器所完成的操作如下：

　　1.如果隊列中存在對相鄰扇區(qū)的請求，則合并兩個請求為一個。

　　2.如果隊列中存在超過過期時間的請求，那么新請求被插入到隊列的末尾，以防止餓死老的請求。

　　3.如果隊列中存在可以按扇區(qū)地址排序的合適位置，那么將請求插入到這個位置。

　　4.如果隊列中沒有合適的可插入位置，請求被插入到隊列末尾。

　　Deadline - latency-oriented

　　Deadline 調(diào)度器是設(shè)計用來解決 Linus Elevator 導致的 I/O 餓死的問題。對磁盤上某個區(qū)域的大量請求，會***期的餓死 (starvation) 對磁盤其他區(qū)域上的請求。

　　請求餓死的一個特例是寫請求餓死讀請求 (writes starving reads)，對于進程來說，當需要進行寫操作時，由于需要寫的數(shù)據(jù)在內(nèi)存的 page cache 中，進程是需要修改對應(yīng)的內(nèi)存，向內(nèi)核發(fā)送寫請求即可，之后進程可以去進行其他操作，由內(nèi)核負責將數(shù)據(jù)同步至磁盤中即可。對于進程來說，寫請求是異步操作。而讀操作是完全不同的，當進程需要讀取數(shù)據(jù)時，需要向內(nèi)核發(fā)送讀請求，內(nèi)核將數(shù)據(jù)載入到內(nèi)存中，由于進程往往需要處理讀取的數(shù)據(jù)，因此進程將處于阻塞狀態(tài)，直到請求被處理完成。對于進程來說，讀請求是同步的操作。寫請求延遲對系統(tǒng)的性能影響不大，而讀請求延遲對系統(tǒng)性能影響是非常大的，因此兩種 IO 請求需要區(qū)別對待。

　　Dealine 調(diào)度器專門針對讀請求延遲進行了優(yōu)化，在 deadline 算法中，每一個請求都有一個過期時間。默認情況下，讀請求的過期時間是 500ms，寫請求的過期時間是 5s。Dealine 調(diào)度器也會對請求隊列進行合并和排序操作，這個隊列稱作排序隊列(sorted queue)。當新請求被提交，Deadline將其加入到排序隊列中進行合并和排序。同時 Deadline 將這個請求加入到第二種類型的隊列中，讀請求被加入至讀FIFO隊列 (Read FIFO queue)，寫請求被加入到寫FIFO隊列 (Write FIFO queue)，這兩個隊列中，請求完全按照 FIFO 順序排列，即新請求永遠被放入到隊列的末尾。

　　這樣一來 Dealine 就維護三個隊列，正常情況下，Deadline 將排序隊列中的請求放入到調(diào)度隊列 (dispatch queue，即將寫入磁盤的隊列)中，調(diào)度隊列把請求發(fā)送至磁盤驅(qū)動。如果寫 FIFO 隊列或讀 FIFO 隊列中的請求發(fā)生了超時，Deadline 調(diào)度器就不再使用排序隊列，而是開始將發(fā)生超時的 FIFO 隊列的請求放入調(diào)度隊列，直至隊列中沒有超時的請求，Deadline 通過這樣的方式保證所有的請求都不會長時間超時。

　　Deadling 防止了請求餓死的出現(xiàn)，由于讀請求的超時時間遠小于寫請求，它同時也避免了出現(xiàn)寫請求餓死讀請求。

　　Deadline 比較適合于MySQL數(shù)據(jù)庫。

　　Anticipatory(AS)

　　AS 調(diào)度器是基于 Deadline 調(diào)度器，加上了一個啟發(fā)式的“預(yù)測”，假設(shè)系統(tǒng)中有大量的寫請求，這時如果夾雜幾個讀請求，由于讀請求的過期時間短，讀請求立即在多個寫請求的中間產(chǎn)生，這樣會導致磁盤的來回尋道，AS 試圖減少大量寫請求夾雜少量讀請求產(chǎn)生的尋道風暴(seek storm)。當一個讀請求完成后，AS不會立即返回處理隊列中的剩余請求，而是等待一個預(yù)測時間(默認為 6ms)，如果等待的時間內(nèi)發(fā)生了相鄰位置的讀請求，那么立即處理這個相鄰位置的讀請求，再返回處理隊列中的請求，這樣可以優(yōu)化多余的尋道時間。

　　它可以為連續(xù) IO 請求(如順序讀)進行了一定的優(yōu)化，但是對于隨機讀的場景 AS 會產(chǎn)生較大的延遲，對于數(shù)據(jù)庫應(yīng)用很糟糕，而對于 Web Server 可能會表現(xiàn)的不錯。這個算法也可以簡單理解為面向低速磁盤的，對于使用了 TCG(Tagged Command Queueing)高性能的磁盤和 RAID，使用 AS 會降低性能。

　　在 Linux 2.6 - 2.6.18 AS 是內(nèi)核默認調(diào)度器，然而大多數(shù)的企業(yè)發(fā)行版選擇的是 CFQ 調(diào)度器。

　　到Linux 2.6.33 版本，AS 被從內(nèi)核中移除，因為可以通過調(diào)整其他調(diào)度器(如 CFQ)來實現(xiàn)與其相似的功能。

#p#

　　Complete Fair Queuing(CFQ)- fairness-oriented

　　CFQ 為每個進程分配一個 I/O 請求隊列，在每個隊列的內(nèi)部，進行合并和排序的優(yōu)化。CFQ 以輪詢的方式處理這些隊列，每次從一個隊列中處理特定數(shù)量的請求(默認為 4 個)。它試圖將 I/O 帶寬均勻的分配至每個進程。CFQ 原本針對的是多媒體或桌面應(yīng)用場景，然而，CFQ 其實在許多場景中內(nèi)表現(xiàn)的很好。CFQ 對每一個 IO 請求都是公平的。這使得 CFQ 很適合離散讀的應(yīng)用 (eg: OLTP DB)

　　多數(shù)企業(yè)發(fā)型版選擇 CFQ 作為默認的 I/O 調(diào)度器。

　　NOOP(No Operation)

　　該算法實現(xiàn)了最簡單的 FIFO 隊列，所有 IO 請求按照大致的先后順序進行操作。之所以說“大致”，原因是 NOOP 在 FIFO 的基礎(chǔ)上還做了相鄰 IO 請求的合并，但其不會進行排序操作。

　　NOOP 適用于底層硬件自身就具有很強調(diào)度控制器的塊設(shè)備(如某些SAN設(shè)備)，或者完全隨機訪問的塊設(shè)備(如SSD)。

　　各個調(diào)度器在數(shù)據(jù)庫應(yīng)用下的性能，可以看出CFQ的性能是比較均衡的。

       IO 參數(shù)調(diào)整

　　隊列長度

　　查看隊列長度：

/sys/block/<dev>/queue/nr_requests 

　　下圖展示了各種隊列長度時，Deadline 和 CFQ 調(diào)度器的性能。

　　由 ext3 的表現(xiàn)可以看出，對于大量的小文件寫操作，隊列長度更長，性能會有所提升，在 16KB 左右，性能提升最為明顯，在 64KB 時，64 至 8192 的隊列長度有著差不多的性能。隨著文件大小的增大，小隊列長度反而有著更好的性能。 RHEL 操作系統(tǒng)中，每個設(shè)備有一個隊列長度。對于類似數(shù)據(jù)庫日志的存放分區(qū)，大部分寫操作屬于小文件 IO，可以將隊列長度調(diào)小。

　　對于大量的連續(xù)讀取，可以考慮增加讀取首部的窗口大小。

/sys/block/<dev>/queue/read_ahead_kb 

　　IO調(diào)度器

　　選擇設(shè)備的IO調(diào)度器。

　　或者在 grub.conf 中加入內(nèi)核參數(shù) elevator=SCHEDULER。

　　Deadline參數(shù)

/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參數(shù)

/sys/block/<device>/queue/iosched/antic_expire 

　　預(yù)測等待時長，默認為 6ms

/sys/block/<device>/queue/iosched/{write_expire,read_expire}  

　　讀寫請求的超時時長

/sys/block/<device>/queue/iosched/{write_batch_expire,read_batch_expire}  

　　讀寫的批量處理時長

#p#

　　CFQ參數(shù)

/sys/block/<device>/queue/iosched/slice_idle 

　　當一個進程的隊列被分配到時間片卻沒有 IO 請求時，調(diào)度器在輪詢至下一個隊列之前的等待時間，以提升 IO 的局部性，對于 SSD 設(shè)備，可以將這個值設(shè)為 0。

/sys/block/<device>/queue/iosched/quantum 

　　一個進程的隊列每次被處理 IO 請求的***數(shù)量，默認為 4，RHEL6 為 8，增大這個值可以提升并行處理 IO 的性能，但可能會造成某些 IO 延遲問題。

/sys/block/<device>/queue/iosched/slice_async_rq  

　　一次處理寫請求的***數(shù)：

/sys/block/<device>/queue/iosched/low_latency  

　　如果IO延遲的問題很嚴重，將這個值設(shè)為 1。

調(diào)整CFQ調(diào)度器的進程IO優(yōu)先級

$ ionice [[-c class] [-n classdata] [-t]] -p PID [PID]...  
$ ionice [-c class] [-n classdata] [-t] COMMAND [ARG]... 

　　CFQ 的進程 IO 優(yōu)先級和進程 CPU 優(yōu)先級是獨立的。使用 ionice 調(diào)整進程優(yōu)先級，有三種調(diào)度類型可以選擇。

　　◆idle

　　只有在沒有更高優(yōu)先級的進程產(chǎn)生 IO 時，idle 才可以使用磁盤 IO，適用于哪些不重要的程序(如 updatedb)，讓它們在磁盤空閑時再產(chǎn)生 IO。

　　◆Best-effort

　　這個類型共有 8 個優(yōu)先級，分別為 0-7，數(shù)字越低，優(yōu)先級越高，相同級別的優(yōu)先級使用輪詢的方式處理。適用于普通的進程。

　　在2.6.26之前，沒有指定調(diào)度類型的進程使用"none" 調(diào)度類型，IO調(diào)度器將其視作Best-effort進行處理，這個類別中進程優(yōu)先級由CPU優(yōu)先級計算得來：io_priority = (cpu_nice + 20) / 5

　　2.6.26之后，沒有指定調(diào)度類型的進程將從CPU調(diào)度類型繼承而來，這個類別的優(yōu)先級仍按照CPU優(yōu)先級計算而來: io_priority = (cpu_nice + 20) / 5

　　◆Real time

　　這個調(diào)度級別的進程產(chǎn)生的IO被優(yōu)先處理，這個調(diào)度類型應(yīng)小心使用，防止餓死其他進程IO, 它也有8個優(yōu)先級，數(shù)字越大分的的IO時間片越長。

　　文件系統(tǒng)

　　一般來說 ReiserFS 更適合于小文件 IO，而 XFS 和 JFS 適合大文件 IO，ext4 則處于兩種之間。

　　JFS 和 XFS 適用于大型的數(shù)據(jù)倉庫，科學計算，大型 SMP 服務(wù)器，多媒體流服務(wù)等。ReiserFS 和 Ext4 適合于文件服務(wù)器，Web 服務(wù)器或郵件服務(wù)器。

　　noatime

　　atime 用于記錄文件***一次被讀取的時間。默認情況下，文件每次被讀取或修改(也需要先讀取)，系統(tǒng)將更新 atime 并寫入至文件元數(shù)據(jù)中。由于寫操作是很昂貴的，減少不必要的寫操作可以提升磁盤性能。然后，大多數(shù)時候，關(guān)閉文件的 atime 也只能獲得非常小的性能提升(這個說法來自于IBM Redbook，表示懷疑)。 

　　使用 noatime 掛載文件系統(tǒng)，將不對文件的 atime 進行更新，此時 atime就相當于 mtime。磁盤性能可以得到0-10%的提升。

　　使用 noatime掛載方法：

/dev/sdb1 /mountlocation ext3 defaults,noatime 1 2 

　　nobarrier

　　barrier 是保證日志文件系統(tǒng)的 WAL (write ahead logging) 一種手段，數(shù)據(jù)寫入磁盤時，理應(yīng)先寫入 journal 區(qū)，再寫入數(shù)據(jù)在磁盤的實際對應(yīng)位置，磁盤廠商為了加快磁盤寫入速度，磁盤都內(nèi)置 cache，數(shù)據(jù)一般都先寫入磁盤的 cache。

　　cache 能加快寫入速度，但磁盤一般會對 cache 內(nèi)緩存數(shù)據(jù)排序使之***刷新到磁盤，這樣就可能導致要刷新的實際數(shù)據(jù)和 journal 順序錯亂。一旦系統(tǒng)崩潰，下次開機時磁盤要參考 journal 區(qū)來恢復，但此時 journal 記錄順序與數(shù)據(jù)實際刷新順序不同就會導致數(shù)據(jù)反而“恢復”到不一致了。而barrier 如其名——“柵欄”，先加一個“柵欄”，保證 journal 總是先寫入記錄，然后對應(yīng)數(shù)據(jù)才刷新到磁盤，這種方式保證了系統(tǒng)崩潰后磁盤恢復的正確性，但對寫入性能有影響。

　　數(shù)據(jù)庫服務(wù)器底層存儲設(shè)備要么采用 RAID 卡，RAID 卡本身的電池可以掉電保護；要么采用 Flash 卡，它也有自我保護機制，保證數(shù)據(jù)不會丟失。所以我們可以安全的使用 nobarrier 掛載文件系統(tǒng)。設(shè)置方法如下： 對于 ext3，ext4 和 reiserfs 文件系統(tǒng)可以在 mount 時指定 barrier=0;對于 xfs 可以指定 nobarrier 選項。

　　read-ahead 預(yù)讀

　　Linux 把讀模式分為隨機讀和順序讀兩大類，并只對順序讀進行預(yù)讀。這一原則相對保守，但是可以保證很高的預(yù)讀***率。

　　為了保證預(yù)讀***率，Linux只對順序讀 (sequential read) 進行預(yù)讀。內(nèi)核通過驗證如下兩個條件來判定一個 read() 是否順序讀：

　　1.這是文件被打開后的***次讀，并且讀的是文件首部；當前的讀請求與前一(記錄的)讀請求在文件內(nèi)的位置是連續(xù)的。

　　2.如果不滿足上述順序性條件，就判定為隨機讀。任何一個隨機讀都將終止當前的順序序列，從而終止預(yù)讀行為(而不是縮減預(yù)讀大小)。

　　預(yù)讀窗口

　　Linux采用了一個快速的窗口擴張過程

　　◆***預(yù)讀： readahead_size = read_size * 2 // or *4

　　預(yù)讀窗口的初始值是讀大小的二到四倍。這意味著在您的程序中使用較大的讀粒度(比如32KB)可以稍稍提升I/O效率。

　　◆后續(xù)預(yù)讀：readahead_size *= 2

　　后續(xù)的預(yù)讀窗口將逐次倍增，直到達到系統(tǒng)設(shè)定的***預(yù)讀大小，其缺省值是 256KB。 

　　查看和修改預(yù)讀窗口：

$ blockdev -getra device  
$ blockdev -setra N device 

　　日志模式

　　大多數(shù)文件系統(tǒng)可以設(shè)置三種日志模式，對于 ext4 文件系統(tǒng)，日志模式對磁盤的性能有較大的影響。

　　◆data=journal

　　數(shù)據(jù)和元數(shù)據(jù)都寫入日志，提供了***的數(shù)據(jù)一致性。

　　◆data=ordered (默認)

　　只記錄元數(shù)據(jù)，然后它會保證先將數(shù)據(jù)寫入磁盤。

　　◆data=writeback

　　采用回寫的方式，犧牲數(shù)據(jù)一致性，獲得更好的性能。仍然會將元數(shù)據(jù)記錄到日志中，此模式對小文件 IO 性能提升最為明顯，但可能造成數(shù)據(jù)丟失。

　　將日志放在單獨的設(shè)備中

　　1.卸載文件系統(tǒng)

　　2.查看文件系統(tǒng)塊大小和日志參數(shù)$ dumpe2fs /dev/sdb1

　　3.移除文件系統(tǒng)內(nèi)部的日志區(qū)$ tune2fs -O ^has_journal /dev/sdb1

　　4.創(chuàng)建外部的日志設(shè)備$ mke2fs –O journal_dev -b block-size /dev/sdc1

　　5.更新原文件系統(tǒng)的超級塊$ tune2fs -j -J device=/dev/sdc1 /dev/sdb1

　　commit

　　設(shè)置多少秒從日志中進行一個同步，默認是5。

　　優(yōu)化Ext4

　　1.格式大文件系統(tǒng)化時延遲 inode 的寫入。

　　對于超大文件系統(tǒng)，mkfs.ext4 進程要花很長時間初始化文件系統(tǒng)中到所有內(nèi)節(jié)點表。

　　可使用 -E lazy_itable_init=1 選項延遲這個進程。如果使用這個選項，內(nèi)核進程將在掛載文件系統(tǒng)后繼續(xù)初始化該文件它?！　?/p>

$ mkfs.ext4 -E lazy_itable_init=1 /dev/sda5 

　　2.關(guān)閉Ext4的自動 fsync() 調(diào)用 -o noauto_da_alloc 或 mount -o noauto_da_alloc。

　　3.降低日志IO的優(yōu)先級至與數(shù)據(jù)IO相同 -o journal_ioprio=n n的用效取值范圍為0-7，默認為3。

#p#

　　查看文件系統(tǒng)鎖

$ cat /proc/locks 

　　Benchmark 基準測試

　　iozone

　　使用iozone對文件系統(tǒng)進行基準測試。

　　1.$ iozone -a iozone將在所有模式下進行測試，使用記錄塊從4k到16M，測試文件大小從64k到512M。

　　2.$ iozone -Ra 或 iozone -Rab output.xls iozone將測試結(jié)果放在Excel中。 

　　3.$ iozone -Ra -g 2g 如果內(nèi)存大于512MB，則測試文件需要更大;***測試文件是內(nèi)存的兩倍。例如內(nèi)存為1G，將測試文件設(shè)置***為2G

$ iozone -Ra -g 2g -i 0 -i 1 

　　如果只關(guān)心文件磁盤的read/write性能，而不必花費時間在其他模式上測試，則我們需要指定測試模式。

$ iozone -Rac 

　　如果測試NFS，將使用-c，這通知iozone在測試過程中執(zhí)行close()函數(shù)。使用close()將減少NFS客戶端緩存的影響。但是如果測試文件比內(nèi)存大，就沒有必要使用參數(shù)-c。　　

-a 在所有模式下進行測試，使用記錄塊從4k到16M，測試文件大小從64k到512M
-b 生成excel文件
-R 生成excel輸入
-f 指定臨時文件名
-g 自動模式的***文件大小
-n 自動模式的最小文件大小
-s 指定文件大小，默認單位是KB, 也可以使用m 和 g
-y 自動模式的最小記錄大小，默認單位是KB
-q 自動模式的***記錄大小，默認單位是KB
-r 指定記錄大小，單位是KB
-i 選擇測試模式

0=write/rewrite
1=read/re-read
2=random-read/write
3=Read-backwards
4=Re-write-record
5=stride-read
6=fwrite/re-fwrite
7=fread/Re-fread,
8=random mix
9=pwrite/Re-pwrite
10=pread/Re-pread
11=pwritev/Re-pwritev
12=preadv/Repreadv

　　一個例子

$ iozone -a -s 128M -y 512 -q 16384 -i 0 -i 1 -i 2 -f /test/a.out -Rb /root/ext3_writeback.out 

　　dd

$ dd bs=1M count=128 if=/dev/zero of=test conv=fdatasync  

　　使用這個參數(shù)，dd命令執(zhí)行到***會真正執(zhí)行一次同步(sync)操作?！　?/p>

$ dd bs=1M count=128 if=/dev/zero of=test oflag=direct 使用直接IO（繞過緩存） 

　　bonnie++

usage: bonnie++ [-d scratch-dir] [-s size(Mb)[:chunk-size(b)]]
[-n number-to-stat[:max-size[:min-size][:num-directories]]]
[-m machine-name]
[-r ram-size-in-Mb]
[-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use]
[-q] [-f] [-b] [-p processes | -y]

-d 生成測試文件的路徑
-s 生成測試文件的大小，以M為單位（如果不使用-r參數(shù)，則要求文件大小至少是系統(tǒng)物理內(nèi)存的2倍）
-m 機器名，實際上我們可以認為是本次測試的方案名，可以隨便定義。默認是本機的hostname。
-r 內(nèi)存大小，指定內(nèi)存大小，這樣可以通過-s參數(shù)創(chuàng)建r*2大小的文件，通常用于縮短測試時間，但是需要注意這樣由于內(nèi)存的cache可能導致測試結(jié)果的不準確
-x 測試的次數(shù)
-u 測試文件的屬主和組，默認是執(zhí)行bonnie++的當前用戶和當前組
-g 測試文件的組，默認是執(zhí)行bonnie++的當前用組
-b 在每次寫文件時調(diào)用fsync()函數(shù)，對于測試郵件服務(wù)器或者數(shù)據(jù)庫服務(wù)器這種通常需要同步操作的情況比較適合，而不使用該參數(shù)則比較適合測試copy文件或者編譯等操作的效率。

　　可以簡單地運行如下命令進行磁盤性能測試：

$ bonnie++ -d /global/oradata –m sun3510  

　　這樣將會在指定的目錄下(通常我們會指定一個盤陣上卷的掛載點)，生成相當于主機物理內(nèi)存兩倍的文件，如果總量大于1G，則生成多個大小為1G的文件。假設(shè)主機內(nèi)存為4G，那么在測試中就會生成8個1G的文件，到測試結(jié)束，這些文件會被自動刪除。 

　　如果我們的主機內(nèi)存是4G，但是我們想縮短測試的時間，比如說只寫2G的文件，就應(yīng)該執(zhí)行下面的命令：

$ bonnie++ -d /global/oradata –m sun3510 –s 2048 –r 1024 

　　blktrace & blkparse

　　blktrace 是一個針對 Linux 內(nèi)核中塊設(shè)備 IO 層的跟蹤工具，用來收集磁盤IO 信息中當 IO 進行到塊設(shè)備層(block層，所以叫blk trace)時的詳細信息(如 IO 請求提交，入隊，合并，完成等等一些列的信息)，blktrace 需要借助內(nèi)核經(jīng)由 debugfs 文件系統(tǒng)(debugf s文件系統(tǒng)在內(nèi)存中)來輸出信息，所以用 blktrace 工具之前需要先掛載 debugfs 文件系統(tǒng)，blktrace需要結(jié)合 blkparse 來使用，由 blkparse 來解析 blktrace 產(chǎn)生的特定格式的二進制數(shù)據(jù)。

　　blktrace語法：

blktrace -d dev [ -r debugfs_path ] [ -o output ] [-k ] [ -w time ] [ -a action ] [ -A action_mask ] [ -v ]

blktrace選項：
-A hex-mask #設(shè)置過濾信息mask成十六進制mask
-a mask #添加mask到當前的過濾器
-b size #指定緩存大小for提取的結(jié)果，默認為512KB
-d dev #添加一個設(shè)備追蹤
-I file #Adds the devices found in file as devices to trace
-k #殺掉正在運行的追蹤
-n num-sub #指定緩沖池大小，默認為4個子緩沖區(qū)
-o file #指定輸出文件的名字
-r rel-path #指定的debugfs掛載點
-V #版本號
-w seconds #設(shè)置運行的時間

　　文件輸出

$ blktrace –d /dev/sda –o trace 

　　解析結(jié)果 $ blkparse -i trace -o /root/trace.txt

　　FIO

　　FIO 是測試 IOPS 的非常好的工具，用來對硬件進行壓力測試和驗證，支持 13 種不同的 IO 引擎，包括：sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等。

　　隨機讀

$ fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest 

　　說明

filename=/dev/sdb1 測試文件名稱，通常選擇需要測試的盤的data目錄。
direct=1 測試過程繞過機器自帶的buffer。使測試結(jié)果更真實。
rw=randwrite 測試隨機寫的I/O
rw=randrw 測試隨機寫和讀的I/O
bs=16k 單次io的塊文件大小為16k
bsrange=512-2048 同上，提定數(shù)據(jù)塊的大小范圍
size=5g 本次的測試文件大小為5g，以每次4k的io進行測試。
numjobs=30 本次的測試線程為30.
runtime=1000 測試時間為1000秒，如果不寫則一直將5g文件分4k每次寫完為止。
ioengine=psync io引擎使用pync方式
rwmixwrite=30 在混合讀寫的模式下，寫占30%
group_reporting 關(guān)于顯示結(jié)果的，匯總每個進程的信息。
此外
lockmem=1g 只使用1g內(nèi)存進行測試。
zero_buffers 用0初始化系統(tǒng)buffer。
nrfiles=8 每個進程生成文件的數(shù)量。

　　順序讀

$ fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest 

　　隨機寫

$ fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest 

　　順序?qū)?/p>

$ fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=1000 -group_reporting -name=mytest 

　　混合隨機讀寫

$ fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=100 -group_reporting -name=mytest -ioscheduler=noop 

　　stress

　　它可以給我們的系統(tǒng)施加 CPU，內(nèi)存，IO 和磁盤的壓力，在模擬極端場景給應(yīng)用系統(tǒng)造成的壓力方面很有幫助。

　　示例

$ stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10d 

　　 【責任編輯：武曉燕 TEL：（010）68476606】