沒有開場白，直接切主題！各位把這篇當成是報告來閱讀吧：
應用IO模型：大量讀線程同時訪問多塊SSD，請求均爲4KB隨機讀，並且被請求的數據有一定間隔連續性；
服務器硬件配置：LSI SAS 2308直連卡 + 8塊SSD
優化前應用QPS：27K
第一輪優化：讀策略優化
通過 /sys/block/sdx/queue/read_ahead_kb 觀察到預讀大小爲128KB，進一步觀察iostat情況：
觀察到每塊SSD的rMB/s十分高，平均已經達到了250MB/s+，初步判斷是由於read_ahead_kb的設置影響了應用的讀效率（即預先讀取了過多不必要的數據）。遂將read_ahead_kb設置爲0，觀察iostat情況如下：
而應用QPS卻下降至25K！
分析原因：由於之前有預讀功能存在，因此部分數據已經被預先讀取而減輕了SSD的訪問壓力。將read_ahead_kb設置爲0後，所有的讀訪問均通過隨機讀實現，一定程度上加重了SSD的訪問壓力（可以觀察到之前%util大約在60~80%之間波動，而預讀改成0之後%util則在80~90%之間波動）
嘗試16K預讀
通過IO模型瞭解到每次請求的數據大小爲4KB，因此將read_ahead_kb設置爲16KB進行嘗試，結果QPS由25K猛增到34K！
觀察iostat情況如下：
%util降了不少，而且通過rrqm/s可以發現出現了一部分讀合併的請求，這說明優化確有成效。
此時CPU_WA也由原來的平均30%下降到20%，這說明處理器等待IO的時間減少了，進一步驗證了IO優化的有效性。
第二輪優化：直連卡中斷多核綁定
考慮到SSD的隨機讀寫能力較強（通過上面的iostat可以發現），在多盤環境下每秒產生的IO請求數也已接近100K，瞭解到LSI SAS 2308芯片的IOPs處理極限大約在250K左右，因此判斷直連卡控制芯片本身並不存在瓶頸。
其實我們擔心更多的是如此大量的IO請求數必定會產生龐大數量的中斷請求，如果中斷請求全部落在處理器的一個核心上，可能會對單核造成較高的壓力，甚至將單核壓力打死。因此單核的中斷請求的處理能力就有可能成爲整個IO系統的瓶頸所在，於是我們通過mpstat觀察每個核心上的中斷數：
可以發現第二個核心中斷數已經達到了十分恐怖的80K！再來觀察實際的處理器核心壓力情況，爲了能夠更加直觀地瞭解，我們用了比較準確的i7z工具來觀察：
果然不出所料，Core 1的Halt（idle）已經到了1，充分說明第二個核心確實已經滿載。
那麼通過觀察/proc/interrupt的情況再來進一步驗證我們的假設，：
我們截取了片段，可以發現mpt2sas0-misx的大部分壓力都集中在了CPU 1上，並且我們發現直連卡模式是支持多隊列的（注意觀察irq號從107至122，mpt2sas驅動總共有16箇中斷號），因此我們將實際在處理中斷的irq號107至118分別綁定至不同的核心上（這裏就不再贅述有關多核綁定的原理，有興趣的同學可以百度搜索以上命令的含義）：
隨後我們驚奇地觀察到應用的QPS由34K再次猛增至39K！
通過觀察mpstat發現大量的中斷被平均分散到了不同的處理器核心上：
並且CPU_WA也由平均20%下降到15%，io wait被進一步優化！
優化總結：
- 通過以上兩個優化方法將應用的QPS由27K優化至39K，並且處理器的iowait由30%下降至15%，優化收效顯著；
- SSD的優化要根據實際的應用IO模型和設備的理論極限值進行綜合考慮，同時還要考慮到各個層面的瓶頸（包括內核、IO策略、磁盤接口速率、連接控制芯片等）。