最近測試一項目，性能非常不理想。老版本邏輯和功能都簡單時，性能是相當的好！接口點選率是萬級的。誰知修改後上不了百。
架設Jboss伺服器，業務邏輯用Java處理，核心子產品使用C++處理，使用JNI銜接。
本應用對CPU和硬碟第三非常敏感，因為有壓縮解壓和大量資料互動。起初作壓力測試時，發現伺服器各資源使用都有剩餘，而點選率曲線波動卻非常大，簡單看似乎是應用程式有問題。
使用top檢視Cpu各核的使用情況，發現一個非常詭異的現象：
1. 經常隻有部分核是滿載的，另外一部分基本空閑；
2. 在CPU滿載時，%wa 的波動比較大，有時會占到較大比例。
是以，監控整個CPU時會發現CPU使用率不高，實際上任務總是分派到某個核上且導緻對應核滿載。無法有效使用CPU，其它資源自然也難以有效排程。
廢話不多說，%wa指CPU等待磁盤寫入完成的時間。莫非是磁盤忙，怎樣證明是磁盤在忙？
首先看下%wa的解釋：Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.
起初用`lsof | less`檢視檔案的讀寫情況，發現/tmp目錄下有大量檔案讀寫。經查證，是Jboss處理上傳檔案會預設寫入到/tmp檔案夾，然後再執行了一次拷貝到程式讀取的目錄。修改Jboss配置直接寫入到程式讀寫目錄，性能沒有本質上的改變。
關于CPU使用波動大，我們也在程式内部加了很多計時器，發現某些子產品在處理并發時會有響應時間很長的情況，這點證明了為什麼點選率波動很大。
但此子產品進行單程序串行測試時，每秒完成事務數是相當可觀的。一個程序每秒完成的事務數都比目前測試點選率要高很多！使用多程序來測試此子產品時，發現“程序數=核數”時效果最佳。于是在Java層控制同時進入此子產品的數量，畢竟Java是調用JNI來使用此子產品，使用全局鎖來控制并發，最終結果沒有想象的那麼理想，但明顯可以看出：通過控制并發數，能有效提高CPU的使用率，點選率也上升了一些。
另外一個問題就是，CPU會出現一會滿載，一會空閑的情況，導緻點選率曲線仍然波動大的問題。商讨後決定在C++代碼中加入“釋放CPU控制權”的邏輯，這樣就在代碼層來作了一個負載均衡。點選率波動的問題得到了好轉，但點選率仍然不理想，預期瓶頸是網絡而實際變成了CPU。
優化了壓縮解決的處理後，性能沒有明顯提升。這時我才想起%wa，我還沒有進一步證明是磁盤的閑忙程度。使用了一些監控工具，諸如：vmstat、sar、dstat、sysstat 沒有發現對磁盤作非常詳細的監控。最後試了下iostat，搞定！
iostat的編譯非常簡單，就一個c檔案，MakeFile裡作者寫了一句話“Cann't be simpler”。直接make install就在目錄下生成了iostat的可執行檔案，看一下幫助，執行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盤的閑忙程式，簡單直接。另外還有詳細的磁盤IO讀寫資料，幫助裡也解釋得非常清楚。
再進行一次壓力測試，拿着這份資料，已經絕對性的說明問題了。此時那些大牛把代碼改了一下，性能立馬就上去了，千兆網絡直接成為系統瓶頸。并于Java的控制問題，改用Apache直接編譯程式子產品調用，完成變為可控，問題瞬間解決！
附上iostat的源碼：
<a href="http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c">http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c</a>