工程師筆記｜其他正常，唯獨順序寫性能很低，怎麼回事？
前言
本文根據Dell EMC工程師處理客戶硬碟寫性能差問題的實踐，詳細重現了從發現問題、排查原因到解決問題的整個過程，提供了多種解決思路，並歸納了修改IO調度配置的兩種方法，供相關人員參考。
一
發現問題：
某汽車交易網站在戴爾易安信R640伺服器上測試Intel S4500 SSD時，遇到了隨機讀、寫和順序讀性能都很高，但順序寫性能低的問題，主要表現在IOPS、BW等指標與其他結果相差10倍。
某品牌伺服器（1U伺服器+ SSD）
4K write：BW=187MiB/s（196MB/s）
Dell R640（Intel S4500 480G SSD）
4K write: BW=18.5MiB/s（19.5MB/s）
>>>>R640硬體配置：
兩顆4110 CPU、4條16G內存、4塊600G SAS 10K+2塊480G SSD、H730P RAID卡、i350網路子卡、495W冗電。客戶安裝的OS版本：CentOS 7.4。
趕到客戶現場後，我們按照客戶提供的FIO腳本進行測試，重現了客戶所說的IO寫性能低的問題。
二
解決過程：
滑動查看
1. 更新測試腳本：降低numjobs值後：IOPS=45.2k, BW=177MiB/s，但是，客戶不接受！
2. 調整BIOS模式：max performance, 問題沒有解決；
3. 升級BIOS、RAID卡FW：問題沒有解決；
4. 將Intel S4500 480G SSD換到R630上，測試結果達到240MB/s；懷疑H730P RAID卡問題；
5. 更換H730P RAID卡，問題依舊沒有解決；
6. 設置RAID 0模式，以及 Non-RAID模式，問題依舊沒有解決；
7. 更換測試軟體FIO的版本：3.1、3.3、3.6，問題依舊沒有解決；
8. 更換RAID卡驅動，從Broadcom官網下載最新的驅動：問
9. 更換OS：安裝CentOS 6.9，問題解決！
10.調整CentOS 7.4的I/O調度，問題解決！
三
原因分析：
通過本次測試，我們發現CentOS 7.4 默認的I/O調度是Deadline（倒計時）演算法，而CentOS 6.9下默認支持的是CFQ（完全公平演算法）。
>>>> cfq（完全公平演算法） :
CFQ演算法，給每個進程一個IO隊列，然後輪詢各個隊列，達到公平的效果。適用於傳統硬碟，也是長久以來的默認演算法。為減少定址，該演算法嘗試給IO排序，極端情況可導致IO飢餓，即如果一個程序有大量順序讀寫，那麼它就會插隊，導致其他程序IO飢餓。CentOS 6默認使用CFQ演算法。
>>>> deadline （倒計時演算法） :
Deadline演算法，維護讀寫兩個隊列，每個隊列都有各自的超時時間，確保每個IO在一定時間內可以得到滿足，能有效防止IO飢餓，適用於傳統硬碟。Ubuntu以及CentOS 7 都默認使用Deadline演算法。
針對本案例，將I/O調度設置為CFQ後，寫性能正常！
四
情景復現：
該汽車交易網站在R640上測試Intel S4500 SSD時，遇到了隨機讀、隨機寫、順序讀性能都很高，但順序寫性能低的問題，主要表現在的IOPS、BW等指標與其他結果相差10倍。
第一天，我們在客戶現場確認環境後，按照提供的FIO腳本進行測試，重現了IO寫性能低的問題。初步測試結果為IOPS=8104, BW=31.7MiB/s。
此後根據以往的FIO調試方法，我們減少了numjobs值，性能達到約IOPS=45.2k,BW=177MiB/s，此時numjobs=4。由於某競爭對手公司的測試腳本在numjobs=50下能夠測到此數量級，客戶較傾向於使用50 numjobs，要求重新測試50 numjobs的結果，但是R640在此壓力下仍然只測到了幾十兆的帶寬水平。
我們又建議客戶使用numjobs=4測試了某公司的伺服器，測試結果為IOPS=32k,BW=129MiB/s，IOPS仍高於R640。
第二天，由於現場測試機的固件並非最新，我們優先更新了固件的版本，主要更新了BIOS固件版本到1.3.7，H730P卡的固件更新到了25.5.4.0006_A12，但這並未引起性能提升。因此我們考慮更換RAID來驗證硬體是否存在問題。
第三天，到達客戶機房後，我們更換了H730P卡，並重裝了操作系統，然後立即對系統進行測試，結果仍然沒有性能提高，因此我們決定將SSD盤拿回公司再測試。
我們將SSD放入了公司的一台R640上，安裝了與客戶一致的CentOS 7.4版本，也使用了同樣的腳本，中間只修改設備名稱而保持其他參數不變，測試結果並沒有改善。
後來我們將SSD放入另一台操作系統為redhat6.9的740xd上進行測試，結果性能達到了200MB+/s，因此初步推斷為不同的操作系統影響了SSD的順序寫性能。
對比兩台伺服器的配置，除硬體不同外，安裝配置也不一樣，主要是OS盤的配置方式、操作系統版本等不同。
我們將R640保持到與740xd一致的安裝方式、配置，也重裝了最新的操作系統，測試後問題依舊，由此證明IO性能低的問題與系統安裝方式、OS盤配置無關。
? 另外，我們也將驅動升級到最新的megaraid_sas-07.705.02.00_el7.4-1.x86_64，結果證明與驅動關係不大。當然我們也考慮到是否是某一版本的驅動性能較好造成的，但客戶伺服器上的驅動也不是最新版本，加上CentOS自帶的驅動與更新過的驅動，關於驅動我們已經測試了三個版本。
排除了主要影響因素，我們考慮直接將R640安裝為Red Hat 6.9來確認性能差異是否是操作系統版本不同導致的。
安裝過程除了操作系統盤為RAID1的VD，S4500 SSD為non-raid配置外，其他配置均為系統默認，除了BIOS的配置只調整為Max Performance Red Hat6.9安裝完成後，我們直接測試FIO，結果達到了平均IOPS=60k, BW=236MiB/s，由此可以斷定是操作系統的問題。
此後我們使用最小化方式在R640上重裝了CentOS 7.4的操作系統，除了編譯FIO需要的相關依賴包外，沒有安裝任何其他程序，也未升級任何驅動。
經研究發現，Red Hat 7.4的IO調度配置為Deadline，這是它與Red Hat6.9版本在IO方面的主要不同點，考慮到可能不同的硬體需要配置不同的調度，於是我們對三種調度都進行了測試，結果只有CFQ的順序寫性能正常，其餘均相差10倍
配置為CFQ的順序寫：
配置為Deadline的順序寫：
配置為Noop的順序寫：
>>>>修改IO調度配置的二種方法
方法一：
① 找到/etc目錄下的grub2-efi.cfg文件，如果boot mode為BIOS，則找到grub2.cfg文件
② 找到引導操作系統的欄位一行，在後面添加elevator=cfq，保存
③ 重新啟動後生效。
方法二：
① 直接使用echo命令修改對應SSD設備的scheduler值
[root@localhost ~]# echo "cfq" > /sys/block/sdb/queue/scheduler
② 使用cat命令查看，即時生效，重啟後恢復原始配置
[root@localhost ~]# cat /sys/block/sdb/queue/scheduler
noop deadline [cfq]
FIO腳本:
fio -filename=/dev/sda -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=1000G -numjobs=1 -runtime=180 -group_reporting -name=sqe_100write_4k
Kernel版本：
Linux g1-net-test-04 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
TAG:至頂網 |