?最近測試一項目，性能非常不理想。老版本邏輯和功能都簡單時，性能是相當的好！接口點擊率是萬級的。誰知修改后上不了百。
??? 架設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的源碼：
http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c