?最近測試一項目，性能非常不理想。老版本邏輯和功能都簡單時，性能是相當(dāng)?shù)暮茫〗涌邳c擊率是萬級的。誰知修改后上不了百。
??? 架設(shè)Jboss服務(wù)器，業(yè)務(wù)邏輯用Java處理，核心模塊使用C++處理，使用JNI銜接。
??? 本應(yīng)用對CPU和硬盤第三非常敏感，因為有壓縮解壓和大量數(shù)據(jù)交互。起初作壓力測試時，發(fā)現(xiàn)服務(wù)器各資源使用都有剩余，而點擊率曲線波動卻非常大，簡單看似乎是應(yīng)用程序有問題。
??? 使用top查看Cpu各核的使用情況，發(fā)現(xiàn)一個非常詭異的現(xiàn)象：
???????? 1. 經(jīng)常只有部分核是滿載的，另外一部分基本空閑；
???????? 2. 在CPU滿載時，%wa 的波動比較大，有時會占到較大比例。
??? 所以，監(jiān)控整個CPU時會發(fā)現(xiàn)CPU使用率不高，實際上任務(wù)總是分派到某個核上且導(dǎo)致對應(yīng)核滿載。無法有效使用CPU，其它資源自然也難以有效調(diào)度。
??? 廢話不多說，%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`查看文件的讀寫情況，發(fā)現(xiàn)/tmp目錄下有大量文件讀寫。經(jīng)查證，是Jboss處理上傳文件會默認(rèn)寫入到/tmp文件夾，然后再執(zhí)行了一次拷貝到程序讀取的目錄。修改Jboss配置直接寫入到程序讀寫目錄，性能沒有本質(zhì)上的改變。
??? 關(guān)于CPU使用波動大，我們也在程序內(nèi)部加了很多計時器，發(fā)現(xiàn)某些模塊在處理并發(fā)時會有響應(yīng)時間很長的情況，這點證實了為什么點擊率波動很大。
??? 但此模塊進(jìn)行單進(jìn)程串行測試時，每秒完成事務(wù)數(shù)是相當(dāng)可觀的。一個進(jìn)程每秒完成的事務(wù)數(shù)都比當(dāng)前測試點擊率要高很多！使用多進(jìn)程來測試此模塊時，發(fā)現(xiàn)“進(jìn)程數(shù)=核數(shù)”時效果最佳。于是在Java層控制同時進(jìn)入此模塊的數(shù)量，畢竟Java是調(diào)用JNI來使用此模塊，使用全局鎖來控制并發(fā)，最終結(jié)果沒有想象的那么理想，但明顯可以看出：通過控制并發(fā)數(shù)，能有效提高CPU的使用率，點擊率也上升了一些。
??? 另外一個問題就是，CPU會出現(xiàn)一會滿載，一會空閑的情況，導(dǎo)致點擊率曲線仍然波動大的問題。商討后決定在C++代碼中加入“釋放CPU控制權(quán)”的邏輯，這樣就在代碼層來作了一個負(fù)載均衡。點擊率波動的問題得到了好轉(zhuǎn)，但點擊率仍然不理想，預(yù)期瓶頸是網(wǎng)絡(luò)而實際變成了CPU。
??? 優(yōu)化了壓縮解決的處理后，性能沒有明顯提升。這時我才想起%wa，我還沒有進(jìn)一步證明是磁盤的閑忙程度。使用了一些監(jiān)控工具，諸如：vmstat、sar、dstat、sysstat 沒有發(fā)現(xiàn)對磁盤作非常詳細(xì)的監(jiān)控。最后試了下iostat，搞定！
??? iostat的編譯非常簡單，就一個c文件，MakeFile里作者寫了一句話“Cann't be simpler”。直接make install就在目錄下生成了iostat的可執(zhí)行文件，看一下幫助，執(zhí)行 `iostat -cdDx 10` 。其中有一列“%b”描述了磁盤的閑忙程序，簡單直接。另外還有詳細(xì)的磁盤IO讀寫數(shù)據(jù)，幫助里也解釋得非常清楚。
?? 再進(jìn)行一次壓力測試，拿著這份數(shù)據(jù)，已經(jīng)絕對性的說明問題了。此時那些大牛把代碼改了一下，性能立馬就上去了，千兆網(wǎng)絡(luò)直接成為系統(tǒng)瓶頸。并于Java的控制問題，改用Apache直接編譯程序模塊調(diào)用，完成變?yōu)榭煽兀瑔栴}瞬間解決！
附上iostat的源碼：
http://code.google.com/p/tester-higkoo/source/browse/trunk/Tools/iostat/iostat.c