背景

隨著企業(yè)SDK在多條產(chǎn)品線的廣泛使用，隨著SDK開發(fā)人員的增長，每日往SDK提交的補(bǔ)丁量與日俱增，自動化提交代碼檢查的壓力已經(jīng)明顯超過了通用服務(wù)器的負(fù)載。于是向公司申請了一臺專用服務(wù)器，用于SDK構(gòu)建檢查。

$ cat /proc/cpuinfo | grep ^proccessor | wc -l48$ free -h total used free shared buffers cachedMem: 47G 45G 1.6G 20M 7.7G 25G-/+ buffers/cache: 12G 35GSwap: 0B 0B 0B$ df文件系統(tǒng) 容量 已用 可用 已用% 掛載點(diǎn)....../dev/sda1 98G 14G 81G 15% //dev/vda1 2.9T 1.8T 986G 65% /home

這是KVM虛擬的服務(wù)器，提供了CPU 48線程，實(shí)際可用47G內(nèi)存，磁盤空間約達(dá)到3TB。

由于獨(dú)享服務(wù)器所有資源，設(shè)置了十來個worker并行編譯，從提交補(bǔ)丁到發(fā)送編譯結(jié)果的速度杠杠的。但是在補(bǔ)丁提交非常多的時候，速度瞬間就慢了下去，一次提交觸發(fā)的編譯甚至要1個多小時。通過top看到CPU負(fù)載并不高，難道是IO瓶頸？找IT要到了root權(quán)限，干起來！

由于認(rèn)知的局限性，如有考慮不周的地方，希望一起交流學(xué)習(xí)

整體認(rèn)識IO棧

如果有完整的IO棧的認(rèn)識，無疑有助于更細(xì)膩的優(yōu)化IO。循著IO棧從上往下的順序，我們逐層分析可優(yōu)化的地方。

在網(wǎng)上有Linux完整的IO棧結(jié)構(gòu)圖，但太過完整反而不容易理解。按我的認(rèn)識，簡化過后的IO棧應(yīng)該是下圖的模樣。

用戶空間：除了用戶自己的APP之外，也隱含了所有的庫，例如常見的C庫。我們常用的IO函數(shù)，例如open()/read()/write()是系統(tǒng)調(diào)用，由內(nèi)核直接提供功能實(shí)現(xiàn)，而fopen()/fread()/fwrite()則是C庫實(shí)現(xiàn)的函數(shù)，通過封裝系統(tǒng)調(diào)用實(shí)現(xiàn)更高級的功能。

虛擬文件系統(tǒng)：屏蔽具體文件系統(tǒng)的差異，向用戶空間提供統(tǒng)一的入口。具體的文件系統(tǒng)通過register_filesystem()向虛擬文件系統(tǒng)注冊掛載鉤子，在用戶掛載具體的文件系統(tǒng)時，通過回調(diào)掛載鉤子實(shí)現(xiàn)文件系統(tǒng)的初始化。虛擬文件系統(tǒng)提供了inode來記錄文件的元數(shù)據(jù)，dentry記錄了目錄項。對用戶空間，虛擬文件系統(tǒng)注冊了系統(tǒng)調(diào)用，例如SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode)注冊了open()的系統(tǒng)調(diào)用。

具體的文件系統(tǒng)：文件系統(tǒng)要實(shí)現(xiàn)存儲空間的管理，換句話說，其規(guī)劃了哪些空間存儲了哪些文件的數(shù)據(jù)，就像一個個收納盒，A文件保存在這個塊，B文件則放在哪個塊。不同的管理策略以及其提供的不同功能，造就了各式各樣的文件系統(tǒng)。除了類似于vfat、ext4、btrfs等常見的塊設(shè)備文件系統(tǒng)之外，還有sysfs、procfs、pstorefs、tempfs等構(gòu)建在內(nèi)存上的文件系統(tǒng)，也有yaffs，ubifs等構(gòu)建在Flash上的文件系統(tǒng)。

頁緩存：可以簡單理解為一片存儲著磁盤數(shù)據(jù)的內(nèi)存，不過其內(nèi)部是以頁為管理單元，常見的頁大小是4K。這片內(nèi)存的大小不是固定的，每有一筆新的數(shù)據(jù)，則申請一個新的內(nèi)存頁。由于內(nèi)存的性能遠(yuǎn)大于磁盤，為了提高IO性能，我們就可以把IO數(shù)據(jù)緩存在內(nèi)存，這樣就可以在內(nèi)存中獲取要的數(shù)據(jù)，不需要經(jīng)過磁盤讀寫的漫長的等待。申請內(nèi)存來緩存數(shù)據(jù)簡單，如何管理所有的頁緩存以及如何及時回收緩存頁才是精髓。

通用塊層：通用塊層也可以細(xì)分為bio層和request層。頁緩存以頁為管理單位，而bio則記錄了磁盤塊與頁之間的關(guān)系，一個磁盤塊可以關(guān)聯(lián)到多個不同的內(nèi)存頁中，通過submit_bio()提交bio到request層。一個request可以理解為多個bio的集合，把多個地址連續(xù)的bio合并成一個request。多個request經(jīng)過IO調(diào)度算法的合并和排序，有序地往下層提交IO請求。

設(shè)備驅(qū)動與塊設(shè)備：不同塊設(shè)備有不同的使用協(xié)議，而特定的設(shè)備驅(qū)動則是實(shí)現(xiàn)了特定設(shè)備需要的協(xié)議以正常驅(qū)使設(shè)備。對塊設(shè)備而言，塊設(shè)備驅(qū)動需要把request解析成一個個設(shè)備操作指令，在協(xié)議的規(guī)范下與塊設(shè)備通信來交換數(shù)據(jù)。

形象點(diǎn)來說，發(fā)起一次IO讀請求的過程是怎么樣的呢？

用戶空間通過虛擬文件系統(tǒng)提供的統(tǒng)一的IO系統(tǒng)調(diào)用，從用戶態(tài)切到內(nèi)核態(tài)。虛擬文件系統(tǒng)通過調(diào)用具體文件系統(tǒng)注冊的回調(diào)，把需求傳遞到具體的文件系統(tǒng)中。緊接著具體的文件系統(tǒng)根據(jù)自己的管理邏輯，換算到具體的磁盤塊地址，從頁緩存尋找塊設(shè)備的緩存數(shù)據(jù)。讀操作一般是同步的，如果在頁緩存沒有緩存數(shù)據(jù)，則向通用塊層發(fā)起一次磁盤讀。通用塊層合并和排序所有進(jìn)程產(chǎn)生的的IO請求，經(jīng)過設(shè)備驅(qū)動從塊設(shè)備讀取真正的數(shù)據(jù)。最后是逐層返回。讀取的數(shù)據(jù)既拷貝到用戶空間的buffer中，也會在頁緩存中保留一份副本，以便下次快速訪問。

如果頁緩存沒命中，同步讀會一路通到塊設(shè)備，而對于 異步寫，則是把數(shù)據(jù)放到頁緩存后返回，由內(nèi)核回刷進(jìn)程在合適時候回刷到塊設(shè)備。

根據(jù)這個流程，考慮到我沒要到KVM host的權(quán)限，我只能著手從Guest端的IO棧做優(yōu)化，具體包括以下幾個方面：

交換分區(qū)（swap）

文件系統(tǒng)（ext4）

頁緩存（Page Cache）

Request層（IO調(diào)度算法）

由于源碼以及編譯的臨時文件都不大但數(shù)量極其多，對隨機(jī)IO的要求非常高。要提高隨機(jī)IO的性能，在不改變硬件的情況下，需要緩存更多數(shù)據(jù)，以實(shí)現(xiàn)合并更多的IO請求。

咨詢ITer得知，服務(wù)器都有備用電源，能確保不會掉電停機(jī)。出于這樣的情況，我們可以盡可能優(yōu)化速度，而不用擔(dān)心掉電導(dǎo)致數(shù)據(jù)丟失問題。

總的來說，優(yōu)化的核心思路是盡可能多的使用內(nèi)存緩存數(shù)據(jù)，盡可能減小不必要的開銷，例如文件系統(tǒng)為了保證數(shù)據(jù)一致性使用日志造成的開銷。

交換分區(qū)

交換分區(qū)的存在，可以讓內(nèi)核在內(nèi)存壓力大時，把內(nèi)核認(rèn)為一些不常用的內(nèi)存置換到交換分區(qū)，以此騰出更多的內(nèi)存給系統(tǒng)。在物理內(nèi)存容量不足且運(yùn)行吃內(nèi)存的應(yīng)用時，交換分區(qū)的作用效果是非常明顯的。

然而本次優(yōu)化的服務(wù)器反而不應(yīng)該使用交換分區(qū)。為什么呢？服務(wù)器總內(nèi)存達(dá)到47G，且服務(wù)器除了Jenkins slave進(jìn)程外沒有大量吃內(nèi)存的進(jìn)程。從內(nèi)存的使用情況來看，絕大部分內(nèi)存都是被cache/buffer占用，是可丟棄的文件緩存，因此內(nèi)存是充足的，不需要通過交換分區(qū)擴(kuò)大虛擬內(nèi)存。

# free -h total used free shared buffers cached Mem: 47G 45G 1.6G 21M 18G 16G -/+ buffers/cache: 10G 36G

交換分區(qū)也是磁盤的空間，從交換分區(qū)置入置出數(shù)據(jù)可也是要占用IO資源的，與本次IO優(yōu)化目的相悖，因此在此服務(wù)器中，需要取消swap分區(qū)。

查看系統(tǒng)狀態(tài)發(fā)現(xiàn)，此服務(wù)器并沒使能swap。

# cat /proc/swapsFilename Type Size Used Priority#

文件系統(tǒng)

用戶發(fā)起一次讀寫，經(jīng)過了虛擬文件系統(tǒng)(VFS)后，交給了實(shí)際的文件系統(tǒng)。

首先查詢分區(qū)掛載情況：

# mount.../dev/sda1 on on / type ext4 (rw)/dev/vda1 on /home type ext4 (rw)...

此服務(wù)器主要有兩個塊設(shè)備，分別是sda和vda。sda是常見的 SCSI/IDE 設(shè)備，我們個人PC上如果使用的機(jī)械硬盤，往往就會是sda設(shè)備節(jié)點(diǎn)。vda是virtio磁盤設(shè)備。由于本服務(wù)器是 KVM 提供的虛擬機(jī)，不管是sda還是vda，其實(shí)都是虛擬設(shè)備，差別在于前者是完全虛擬化的塊設(shè)備，后者是半虛擬化的塊設(shè)備。從網(wǎng)上找到的資料來看，使用半虛擬化的設(shè)備，可以實(shí)現(xiàn)Host與Guest更高效的協(xié)作，從而實(shí)現(xiàn)更高的性能。在此例子中，sda作為根文件系統(tǒng)使用，vda則是用于存儲用戶數(shù)據(jù)，在編譯時，主要看得是vda分區(qū)的IO情況。

vda使用ext4文件系統(tǒng)。ext4是目前常見的Linux上使用的穩(wěn)定的文件系統(tǒng)，查看其超級塊信息：

# dumpe2fs /dev/vda1...Filesystem features: has_journal dir_index ......Inode count: 196608000Block count: 786431991Free inodes: 145220571Block size: 4096...

我猜測ITer使用的默認(rèn)參數(shù)格式化的分區(qū)，為其分配了塊大小為4K，inode數(shù)量達(dá)到19660萬個且使能了日志。

塊大小設(shè)為4K無可厚非，適用于當(dāng)前源文件偏小的情況，也沒必要為了更緊湊的空間降低塊大小?？臻e inode 達(dá)到 14522萬，空閑占比達(dá)到 73.86%。當(dāng)前 74% 的空間使用率，inode只使用了26.14%。一個inode占256B，那么10000萬個inode占用23.84G。inode 實(shí)在太多了，造成大量的空間浪費(fèi)?？上?，inode數(shù)量在格式化時指定，后期無法修改，當(dāng)前也不能簡單粗暴地重新格式化。

我們能做什么呢？我們可以從日志和掛載參數(shù)著手優(yōu)化

日志是為了保證掉電時文件系統(tǒng)的一致性，(ordered日志模式下)通過把元數(shù)據(jù)寫入到日志塊，在寫入數(shù)據(jù)后再修改元數(shù)據(jù)。如果此時掉電，通過日志記錄可以回滾文件系統(tǒng)到上一個一致性的狀態(tài)，即保證元數(shù)據(jù)與數(shù)據(jù)是匹配的。然而上文有說，此服務(wù)器有備用電源，不需要擔(dān)心掉電，因此完全可以把日志取消掉。

# tune2fs -O ^has_journal /dev/vda1tune2fs 1.42.9 (4-Feb-2014)The has_journal feature may only be cleared when the filesystem isunmounted or mounted read-only.

可惜失敗了。由于時刻有任務(wù)在執(zhí)行，不太好直接umount或者-o remount,ro，無法在掛載時取消日志。既然取消不了，咱們就讓日志最少損耗，就需要修改掛載參數(shù)了。

ext4掛載參數(shù): data

ext4有3種日志模式，分別是ordered，writeback，journal。他們的差別網(wǎng)上有很多資料，我簡單介紹下：

jorunal：把元數(shù)據(jù)與數(shù)據(jù)一并寫入到日志塊。性能差不多折半，因?yàn)閿?shù)據(jù)寫了兩次，但最安全

writeback: 把元數(shù)據(jù)寫入日志塊，數(shù)據(jù)不寫入日志塊，但不保證數(shù)據(jù)先落盤。性能最高，但由于不保證元數(shù)據(jù)與數(shù)據(jù)的順序，也是掉電最不安全的

ordered：與writeback相似，但會保證數(shù)據(jù)先落盤，再是元數(shù)據(jù)。折中性能以保證足夠的安全，這是大多數(shù)PC上推薦的默認(rèn)的模式

在不需要擔(dān)心掉電的服務(wù)器環(huán)境，我們完全可以使用writeback的日志模式，以獲取最高的性能。

# mount -o remount,rw,data=writeback /homemount: /home not mounted or bad option# dmesg[235737.532630] EXT4-fs (vda1): Cannot change data mode on remount

沮喪，又是不能動態(tài)改，干脆寫入到/etc/config，只能寄希望于下次重啟了。

# cat /etc/fstabUUID=... /home ext4 defaults,rw,data=writeback...

ext4掛載參數(shù)：noatime

Linux上對每個文件都記錄了3個時間戳

我們編譯執(zhí)行的Make可以根據(jù)修改時間來判斷是否要重新編譯，而atime記錄的訪問時間其實(shí)在很多場景下都是多余的。所以，noatime應(yīng)運(yùn)而生。不記錄atime可以大量減少讀造成的元數(shù)據(jù)寫入量，而元數(shù)據(jù)的寫入往往產(chǎn)生大量的隨機(jī)IO。

# mount -o ...noatime... /home

ext4掛載參數(shù)：nobarrier

這主要是決定在日志代碼中是否使用寫屏障(write barrier)，對日志提交進(jìn)行正確的磁盤排序，使易失性磁盤寫緩存可以安全使用，但會帶來一些性能損失。從功能來看，跟writeback和ordered日志模式非常相似。沒研究過這方面的源碼，說不定就是一回事。不管怎么樣，禁用寫屏障毫無疑問能提高寫性能。

# mount -o ...nobarrier... /home

ext4掛載參數(shù)：delalloc

delalloc是delayed allocation的縮寫，如果使能，則ext4會延緩申請數(shù)據(jù)塊直至超時。為什么要延緩申請呢？在inode中采用多級索引的方式記錄了文件數(shù)據(jù)所在的數(shù)據(jù)塊編號，如果出現(xiàn)大文件，則會采用extent區(qū)段的形式，分配一片連續(xù)的塊，inode中只需要記錄開始塊號與長度即可，不需要索引記錄所有的塊。這除了減輕inode的壓力之外，連續(xù)的塊可以把隨機(jī)寫改為順序?qū)?，加快寫性能。連續(xù)的塊也符合局部性原理，在預(yù)讀時可以加大命中概率，進(jìn)而加快讀性能。

# mount -o ...delalloc... /home

ext4掛載參數(shù)：inode_readahead_blks

ext4從inode表中預(yù)讀的indoe block最大數(shù)量。訪問文件必須經(jīng)過inode獲取文件信息、數(shù)據(jù)塊地址。如果需要訪問的inode都在內(nèi)存中命中，就不需要從磁盤中讀取，毫無疑問能提高讀性能。其默認(rèn)值是32，表示最大預(yù)讀32 × block_size即 64K 的inode數(shù)據(jù)，在內(nèi)存充足的情況下，我們毫無疑問可以進(jìn)一步擴(kuò)大，讓其預(yù)讀更多。

# mount -o ...inode_readahead_blks=4096... /home

ext4掛載參數(shù)：journal_async_commit

commit塊可以不等待descriptor塊，直接往磁盤寫。這會加快日志的速度。

# mount -o ...journal_async_commit... /home

ext4掛載參數(shù)：commit

ext4一次緩存多少秒的數(shù)據(jù)。默認(rèn)值是5，表示如果此時掉電，你最多丟失5s的數(shù)據(jù)量。設(shè)置更大的數(shù)據(jù)，就可以緩存更多的數(shù)據(jù)，相對的掉電也有可能丟失更多的數(shù)據(jù)。在此服務(wù)器不怕掉電的情況，把數(shù)值加大可以提高性能。

# mount -o ...commit=1000... /home

ext4掛載參數(shù)匯總

最終在不能umount情況下，我執(zhí)行的調(diào)整掛載參數(shù)的命令為：

mount-oremount,rw,noatime,nobarrier,delalloc,inode_readahead_blks=4096,journal_async_commit,commit=1800/home此外，在/etc/fstab中也對應(yīng)修改過來，避免重啟后優(yōu)化丟失

# cat /etc/fstabUUID=... /home ext4 defaults,rw,noatime,nobarrier,delalloc,inode_readahead_blks=4096,journal_async_commit,commit=1800,data=writeback 0 0...

頁緩存

頁緩存在FS與通用塊層之間，其實(shí)也可以歸到通用塊層中。為了提高IO性能，減少真實(shí)的從磁盤讀寫的次數(shù)，Linux內(nèi)核設(shè)計了一層內(nèi)存緩存，把磁盤數(shù)據(jù)緩存到內(nèi)存中。由于內(nèi)存以4K大小的頁為單位管理，磁盤數(shù)據(jù)也以頁為單位緩存，因此也稱為頁緩存。在每個緩存頁中，都包含了部分磁盤信息的副本。

如果因?yàn)橹白x寫過或者被預(yù)讀加載進(jìn)來，要讀取數(shù)據(jù)剛好在緩存中命中，就可以直接從緩存中讀取，不需要深入到磁盤。不管是同步寫還是異步寫，都會把數(shù)據(jù)copy到緩存，差別在于異步寫只是copy且把頁標(biāo)識臟后直接返回，而同步寫還會調(diào)用類似fsync()的操作等待回寫，詳細(xì)可以看內(nèi)核函數(shù)generic_file_write_iter()。異步寫產(chǎn)生的臟數(shù)據(jù)會在“合適”的時候被內(nèi)核工作隊列writeback進(jìn)程回刷。

那么，什么時候是合適的時候呢？最多能緩存多少數(shù)據(jù)呢？對此次優(yōu)化的服務(wù)器而言，毫無疑問延遲回刷可以在頻繁的刪改文件中減少寫磁盤次數(shù)，緩存更多的數(shù)據(jù)可以更容易合并隨機(jī)IO請求，有助于提升性能。

在/proc/sys/vm中有以下文件與回刷臟數(shù)據(jù)密切相關(guān)：

對上述的配置文件，有幾點(diǎn)要補(bǔ)充的：

XXX_ratio 和 XXX_bytes 是同一個配置屬性的不同計算方法，優(yōu)先級 XXX_bytes > XXX_ratio

可用內(nèi)存并不是系統(tǒng)所有內(nèi)存，而是free pages + reclaimable pages

臟數(shù)據(jù)超時表示內(nèi)存中數(shù)據(jù)標(biāo)識臟一定時間后，下次回刷進(jìn)程工作時就必須回刷

回刷進(jìn)程既會定時喚醒，也會在臟數(shù)據(jù)過多時被動喚醒。

dirty_background_XXX與dirty_XXX的差別在于前者只是喚醒回刷進(jìn)程，此時應(yīng)用依然可以異步寫數(shù)據(jù)到Cache，當(dāng)臟數(shù)據(jù)比例繼續(xù)增加，觸發(fā)dirty_XXX的條件，不再支持應(yīng)用異步寫。

更完整的功能介紹，可以看內(nèi)核文檔Documentation/sysctl/vm.txt，也可看我寫的一篇總結(jié)博客《Linux 臟數(shù)據(jù)回刷參數(shù)與調(diào)優(yōu)》

對當(dāng)前的案例而言，我的配置如下：

dirty_background_ratio = 60dirty_ratio = 80dirty_writeback_centisecs = 6000dirty_expire_centisecs = 12000

這樣的配置有以下特點(diǎn)：

當(dāng)臟數(shù)據(jù)達(dá)到可用內(nèi)存的60%時喚醒回刷進(jìn)程

當(dāng)臟數(shù)據(jù)達(dá)到可用內(nèi)存的80%時，應(yīng)用每一筆數(shù)據(jù)都必須同步等待

每隔60s喚醒一次回刷進(jìn)程

內(nèi)存中臟數(shù)據(jù)存在時間超過120s則在下一次喚醒時回刷

當(dāng)然，為了避免重啟后丟失優(yōu)化結(jié)果，我們在/etc/sysctl.conf中寫入：

# cat /etc/sysctl.conf...vm.dirty_background_ratio = 60vm.dirty_ratio = 80vm.dirty_expire_centisecs = 12000vm.dirty_writeback_centisecs = 6000

Request層

在異步寫的場景中，當(dāng)臟頁達(dá)到一定比例，就需要通過通用塊層把頁緩存里的數(shù)據(jù)回刷到磁盤中。bio層記錄了磁盤塊與內(nèi)存頁之間的關(guān)系，在request層把多個物理塊連續(xù)的bio合并成一個request，然后根據(jù)特定的IO調(diào)度算法對系統(tǒng)內(nèi)所有進(jìn)程產(chǎn)生的IO請求進(jìn)行合并、排序。那么都有什么IO調(diào)度算法呢？

網(wǎng)上檢索IO調(diào)度算法，大量的資料都在描述Deadline，CFQ，NOOP這3種調(diào)度算法，卻沒有備注這只是單隊列上適用的調(diào)度算法。在最新的代碼上（我分析的代碼版本為 5.7.0），已經(jīng)完全切換到multi-queue的新架構(gòu)上了，支持的IO調(diào)度算法就成了mq-deadline，BFQ，Kyber，none。

關(guān)于不同IO調(diào)度算法的優(yōu)劣，網(wǎng)上有非常多的資料，本文不再累述。

在《Linux-storage-stack-diagram_v4.10》對 Block Layer 的描述可以形象闡述單隊列與多隊列的差異。

單隊列的架構(gòu)，一個塊設(shè)備只有一個全局隊列，所有請求都要往這個隊列里面塞，這在多核高并發(fā)的情況下，尤其像服務(wù)器動則32個核的情況下，為了保證互斥而加的鎖就導(dǎo)致了非常大的開銷。此外，如果磁盤支持多隊列并行處理，單隊列的模型不能充分發(fā)揮其優(yōu)越的性能。

多隊列的架構(gòu)下，創(chuàng)建了Software queues和Hardware dispatch queues兩級隊列。Software queues是每個CPU core一個隊列，且在其中實(shí)現(xiàn)IO調(diào)度。由于每個CPU一個單獨(dú)隊列，因此不存在鎖競爭問題。Hardware Dispatch Queues的數(shù)量跟硬件情況有關(guān)，每個磁盤一個隊列，如果磁盤支持并行N個隊列，則也會創(chuàng)建N個隊列。在IO請求從Software queues提交到Hardware Dispatch Queues的過程中是需要加鎖的。理論上，多隊列的架構(gòu)的效率最差也只是跟單隊列架構(gòu)持平。

咱們回到當(dāng)前待優(yōu)化的服務(wù)器，當(dāng)前使用的是什么IO調(diào)度器呢？

# cat /sys/block/vda/queue/schedulernone# cat /sys/block/sda/queue/schedulernoop [deadline] cfq

這服務(wù)器的內(nèi)核版本是

# uname -r3.13.0-170-generic

查看Linux內(nèi)核git提交記錄，發(fā)現(xiàn)在 3.13.0 的內(nèi)核版本上還沒有實(shí)現(xiàn)適用于多隊列的IO調(diào)度算法，且此時還沒完全切到多隊列架構(gòu)，因此使用單隊列的 sda 設(shè)備依然存在傳統(tǒng)的noop，deadline和cfq調(diào)度算法，而使用多隊列的 vda 設(shè)備(virtio)的IO調(diào)度算法只有none。為了使用mq-deadline調(diào)度算法把內(nèi)核升級的風(fēng)險似乎很大。因此IO調(diào)度算法方面沒太多可優(yōu)化的。

但Request層優(yōu)化只能這樣了？既然IO調(diào)度算法無法優(yōu)化，我們是否可以修改queue相關(guān)的參數(shù)？例如加大Request隊列的長度，加大預(yù)讀的數(shù)據(jù)量。

在/sys/block/vda/queue中有兩個可寫的文件nr_requests和read_ahead_kb，前者是配置塊層最大可以申請的request數(shù)量，后者是預(yù)讀最大的數(shù)據(jù)量。默認(rèn)情況下，

nr_request = 128read_ahead_kb = 128

我擴(kuò)大為

nr_request = 1024read_ahead_kb = 512

優(yōu)化效果

優(yōu)化后，在滿負(fù)荷的情況下，查看內(nèi)存使用情況：

# cat /proc/meminfoMemTotal: 49459060 kBMemFree: 1233512 kBBuffers: 12643752 kBCached: 21447280 kBActive: 19860928 kBInactive: 16930904 kBActive(anon): 2704008 kBInactive(anon): 19004 kBActive(file): 17156920 kBInactive(file): 16911900 kB...Dirty: 7437540 kBWriteback: 1456 kB

可以看到，文件相關(guān)內(nèi)存（Active(file) + Inactive(file) ）達(dá)到了32.49GB，臟數(shù)據(jù)達(dá)到7.09GB。臟數(shù)據(jù)量比預(yù)期要少，遠(yuǎn)沒達(dá)到dirty_background_ratio和dirty_ratio設(shè)置的閾值。因此，如果需要緩存更多的寫數(shù)據(jù)，只能延長定時喚醒回刷的時間dirty_writeback_centisecs。這個服務(wù)器主要用于編譯SDK，讀的需求遠(yuǎn)大于寫，因此緩存更多的臟數(shù)據(jù)沒太大意義。

我還發(fā)現(xiàn)Buffers達(dá)到了12G，應(yīng)該是ext4的inode占用了大量的緩存。如上分析的，此服務(wù)器的ext4有大量富余的inode，在緩存的元數(shù)據(jù)里，無效的inode不知道占比多少。減少inode數(shù)量，提高inode利用率，說不定可以提高inode預(yù)讀的命中率。

優(yōu)化后，一次使能8個SDK并行編譯，走完一次完整的編譯流程（包括更新代碼，抓取提交，編譯內(nèi)核，編譯SDK等），在沒有進(jìn)入錯誤處理流程的情況下，用時大概13分鐘。

這次的優(yōu)化就到這里結(jié)束了，等后期使用過程如果還有問題再做調(diào)整。