共計 10239 個字符，預(yù)計需要花費(fèi) 26 分鐘才能閱讀完成。
這篇文章跟大家分析一下“如何進(jìn)行編譯服務(wù)器性能優(yōu)化實戰(zhàn)”。內(nèi)容詳細(xì)易懂，對“如何進(jìn)行編譯服務(wù)器性能優(yōu)化實戰(zhàn)”感興趣的朋友可以跟著丸趣 TV 小編的思路慢慢深入來閱讀一下，希望閱讀后能夠?qū)Υ蠹矣兴鶐椭Ｏ旅娓枞?TV 小編一起深入學(xué)習(xí)“如何進(jìn)行編譯服務(wù)器性能優(yōu)化實戰(zhàn)”的知識吧。
背景
隨著企業(yè) SDK 在多條產(chǎn)品線的廣泛使用，隨著 SDK 開發(fā)人員的增長，每日往 SDK 提交的補(bǔ)丁量與日俱增，自動化提交代碼檢查的壓力已經(jīng)明顯超過了通用服務(wù)器的負(fù)載。于是向公司申請了一臺專用服務(wù)器，用于 SDK 構(gòu)建檢查。
$ cat /proc/cpuinfo | grep ^proccessor | wc -l 48 $ free -h total used free shared buffers cached Mem: 47G 45G 1.6G 20M 7.7G 25G -/+ buffers/cache: 12G 35G Swap: 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 線程，實際可用 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)核直接提供功能實現(xiàn)，而 fopen()/fread()/fwrite()則是 C 庫實現(xiàn)的函數(shù)，通過封裝系統(tǒng)調(diào)用實現(xiàn)更高級的功能。
虛擬文件系統(tǒng)：屏蔽具體文件系統(tǒng)的差異，向用戶空間提供統(tǒng)一的入口。具體的文件系統(tǒng)通過 register_filesystem()向虛擬文件系統(tǒng)注冊掛載鉤子，在用戶掛載具體的文件系統(tǒng)時，通過回調(diào)掛載鉤子實現(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)要實現(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ū)動則是實現(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ù)，以實現(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/swaps Filename Type Size Used Priority #文件系統(tǒng)
用戶發(fā)起一次讀寫，經(jīng)過了虛擬文件系統(tǒng) (VFS) 后，交給了實際的文件系統(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è)備。從網(wǎng)上找到的資料來看，使用半虛擬化的設(shè)備，可以實現(xiàn) Host 與 Guest 更高效的協(xié)作，從而實現(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: 196608000 Block count: 786431991 Free inodes: 145220571 Block size: 4096 ...我猜測 ITer 使用的默認(rèn)參數(shù)格式化的分區(qū)，為其分配了塊大小為 4K，inode 數(shù)量達(dá)到 19660 萬個且使能了日志。
塊大小設(shè)為 4K 無可厚非，適用于當(dāng)前源文件偏小的情況，也沒必要為了更緊湊的空間降低塊大小。空閑 inode 達(dá)到 14522 萬，空閑占比達(dá)到 73.86%。當(dāng)前 74% 的空間使用率，inode 只使用了 26.14%。一個 inode 占 256B，那么 10000 萬個 inode 占用 23.84G。inode 實在太多了，造成大量的空間浪費(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/vda1 tune2fs 1.42.9 (4-Feb-2014) The has_journal feature may only be cleared when the filesystem is unmounted 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ù)一并寫入到日志塊。性能差不多折半，因為數(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 /home mount: /home not mounted or bad option # dmesg [235737.532630] EXT4-fs (vda1): Cannot change data mode on remount沮喪，又是不能動態(tài)改，干脆寫入到 /etc/config，只能寄希望于下次重啟了。
# cat /etc/fstab UUID=... /home ext4 defaults,rw,data=writeback...ext4 掛載參數(shù)：noatime
Linux 上對每個文件都記錄了 3 個時間戳
時間戳全稱含義 atimeaccess time 訪問時間，就是最近一次讀的時間 mtimedata modified time 數(shù)據(jù)修改時間，就是內(nèi)容最后一次改動時間 ctimestatus change time 文件狀態(tài) (元數(shù)據(jù)) 的改變時間，比如權(quán)限，所有者等
我們編譯執(zhí)行的 Make 可以根據(jù)修改時間來判斷是否要重新編譯，而 atime 記錄的訪問時間其實在很多場景下都是多余的。所以，noatime 應(yīng)運(yùn)而生。不記錄 atime 可以大量減少讀造成的元數(shù)據(jù)寫入量，而元數(shù)據(jù)的寫入往往產(chǎn)生大量的隨機(jī) IO。
# mount -o ...noatime... /homeext4 掛載參數(shù)：nobarrier
這主要是決定在日志代碼中是否使用寫屏障(write barrier)，對日志提交進(jìn)行正確的磁盤排序，使易失性磁盤寫緩存可以安全使用，但會帶來一些性能損失。從功能來看，跟 writeback 和 ordered 日志模式非常相似。沒研究過這方面的源碼，說不定就是一回事。不管怎么樣，禁用寫屏障毫無疑問能提高寫性能。
# mount -o ...nobarrier... /homeext4 掛載參數(shù)：delalloc
delalloc 是 delayed allocation 的縮寫，如果使能，則 ext4 會延緩申請數(shù)據(jù)塊直至超時。為什么要延緩申請呢? 在 inode 中采用多級索引的方式記錄了文件數(shù)據(jù)所在的數(shù)據(jù)塊編號，如果出現(xiàn)大文件，則會采用 extent 區(qū)段的形式，分配一片連續(xù)的塊，inode 中只需要記錄開始塊號與長度即可，不需要索引記錄所有的塊。這除了減輕 inode 的壓力之外，連續(xù)的塊可以把隨機(jī)寫改為順序?qū)懀涌鞂懶阅堋＿B續(xù)的塊也符合 局部性原理，在預(yù)讀時可以加大命中概率，進(jìn)而加快讀性能。
# mount -o ...delalloc... /homeext4 掛載參數(shù)：inode_readahead_blks
ext4 從 inode 表中預(yù)讀的 indoe block 最大數(shù)量。訪問文件必須經(jīng)過 inode 獲取文件信息、數(shù)據(jù)塊地址。如果需要訪問的 inode 都在內(nèi)存中命中，就不需要從磁盤中讀取，毫無疑問能提高讀性能。其默認(rèn)值是 32，表示最大預(yù)讀 32 times; block_size 即 64K 的 inode 數(shù)據(jù)，在內(nèi)存充足的情況下，我們毫無疑問可以進(jìn)一步擴(kuò)大，讓其預(yù)讀更多。
# mount -o ...inode_readahead_blks=4096... /homeext4 掛載參數(shù)：journal_async_commit
commit 塊可以不等待 descriptor 塊，直接往磁盤寫。這會加快日志的速度。
# mount -o ...journal_async_commit... /homeext4 掛載參數(shù)：commit
ext4 一次緩存多少秒的數(shù)據(jù)。默認(rèn)值是 5，表示如果此時掉電，你最多丟失 5s 的數(shù)據(jù)量。設(shè)置更大的數(shù)據(jù)，就可以緩存更多的數(shù)據(jù)，相對的掉電也有可能丟失更多的數(shù)據(jù)。在此服務(wù)器不怕掉電的情況，把數(shù)值加大可以提高性能。
# mount -o ...commit=1000... /homeext4 掛載參數(shù)匯總
最終在不能 umount 情況下，我執(zhí)行的調(diào)整掛載參數(shù)的命令為：
mount -o remount,rw,noatime,nobarrier,delalloc,inode_readahead_blks=4096,journal_async_commit,commit=1800 /home此外，在 /etc/fstab 中也對應(yīng)修改過來，避免重啟后優(yōu)化丟失
# cat /etc/fstab UUID=... /home ext4 defaults,rw,noatime,nobarrier,delalloc,inode_readahead_blks=4096,journal_async_commit,commit=1800,data=writeback 0 0 ...頁緩存
頁緩存在 FS 與通用塊層之間，其實也可以歸到通用塊層中。為了提高 IO 性能，減少真實的從磁盤讀寫的次數(shù)，Linux 內(nèi)核設(shè)計了一層內(nèi)存緩存，把磁盤數(shù)據(jù)緩存到內(nèi)存中。由于內(nèi)存以 4K 大小的 頁 為單位管理，磁盤數(shù)據(jù)也以頁為單位緩存，因此也稱為頁緩存。在每個緩存頁中，都包含了部分磁盤信息的副本。
如果因為之前讀寫過或者被預(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)：
配置文件功能默認(rèn)值 dirty_background_ratio 觸發(fā)回刷的臟數(shù)據(jù)占可用內(nèi)存的百分比 0dirty_background_bytes 觸發(fā)回刷的臟數(shù)據(jù)量 10dirty_bytes 觸發(fā)同步寫的臟數(shù)據(jù)量 0dirty_ratio 觸發(fā)同步寫的臟數(shù)據(jù)占可用內(nèi)存的百分比 20dirty_expire_centisecs 臟數(shù)據(jù)超時回刷時間(單位：1/100s)3000dirty_writeback_centisecs 回刷進(jìn)程定時喚醒時間(單位：1/100s)500
對上述的配置文件，有幾點(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 = 60 dirty_ratio = 80 dirty_writeback_centisecs = 6000 dirty_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 = 60 vm.dirty_ratio = 80 vm.dirty_expire_centisecs = 12000 vm.dirty_writeback_centisecs = 6000Request 層
在異步寫的場景中，當(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 一個隊列，且在其中實現(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/scheduler none # cat /sys/block/sda/queue/scheduler noop [deadline] cfq這服務(wù)器的內(nèi)核版本是
# uname -r 3.13.0-170-generic查看 Linux 內(nèi)核 git 提交記錄，發(fā)現(xiàn)在 3.13.0 的內(nèi)核版本上還沒有實現(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 = 128 read_ahead_kb = 128我擴(kuò)大為
nr_request = 1024 read_ahead_kb = 512優(yōu)化效果
優(yōu)化后，在滿負(fù)荷的情況下，查看內(nèi)存使用情況：
# cat /proc/meminfo MemTotal: 49459060 kB MemFree: 1233512 kB Buffers: 12643752 kB Cached: 21447280 kB Active: 19860928 kB Inactive: 16930904 kB Active(anon): 2704008 kB Inactive(anon): 19004 kB Active(file): 17156920 kB Inactive(file): 16911900 kB ... Dirty: 7437540 kB Writeback: 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 分鐘。
關(guān)于如何進(jìn)行編譯服務(wù)器性能優(yōu)化實戰(zhàn)就分享到這里啦，希望上述內(nèi)容能夠讓大家有所提升。如果想要學(xué)習(xí)更多知識，請大家多多留意丸趣 TV 小編的更新。謝謝大家關(guān)注一下丸趣 TV 網(wǎng)站！
