这段时间一直忙于用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中。
答案总是在不断的尝试中被发现，这算是另一份经验总结吧。
本文转自Intel_ISN 51CTO博客，原文链接：http://blog.51cto.com/intelisn/131493，如需转载请自行联系原作者
