這段時間一直忙於用ISV的workload來進行對比測試。
在測試過程中，有兩個遊戲客戶都出現了CPU利用率上不去的問題。
現象就是，CPU佔用不高，內存，硬盤，網絡都不存在瓶頸，但是服務器響應變得非常慢。
這個問題讓我們很困擾，卻找不到問題的原因所在。
在測試過程中，有兩個遊戲客戶都出現了CPU利用率上不去的問題。
現象就是，CPU佔用不高，內存，硬盤，網絡都不存在瓶頸，但是服務器響應變得非常慢。
這個問題讓我們很困擾，卻找不到問題的原因所在。
後來倒是一個很巧合的機會讓答案浮出水面。
我們用新平臺作爲客戶端進行壓力測試，壓到1000個用戶之後，就開始報錯：“Too much open file”。
我們用新平臺作爲客戶端進行壓力測試，壓到1000個用戶之後，就開始報錯：“Too much open file”。
用ulimite -a查看max open file的設置是1024.
原來RHEL4.7缺省的max open file值就是1024.
使用 ulimite -n 65535 修改max open file的值爲65535，錯誤沒有再出現。
再用機器作爲服務器進行測試，之前的問題也沒有再出現。
原來RHEL4.7缺省的max open file值就是1024.
使用 ulimite -n 65535 修改max open file的值爲65535，錯誤沒有再出現。
再用機器作爲服務器進行測試，之前的問題也沒有再出現。
需要注意的是，ulimite命令的執行只在當前shell下有作用，
爲了永久更改openfile的數量，需要把這個命令寫到profile中。
爲了永久更改openfile的數量，需要把這個命令寫到profile中。
答案總是在不斷的嘗試中被發現，這算是另一份經驗總結吧。