我在Ubuntu 12上使用Tomcat7时遇到了太多打开文件的问题，因此我将打开文件的硬限制和软限制从分别为4096和1024增加到16384。现在我不再收到有关打开文件的错误，但总体CPU％似乎已经上升了。增加最大文件数是否也会在CPU时间方面产生一些成本？如果没有，为什么不将ulimit设置得非常高呢？
1个回答
6
整个ulimit存在的原因是通过防止进程使用超出“正常”资源的数量来保护系统的整体性能。
“正常”可能因所做的事情而异，但默认情况下将限制设置得非常高会使ulimit失去意义，并允许任何进程使用荒谬的资源量。对于没有用户的服务器而言，这不如大型多用户环境那么重要，但它仍然是针对有缺陷或被攻击的进程的有用保障。
您的CPU可能会上升，因为您的计算机现在正在执行更多的工作，而不是错误输出。
PS-您需要确保您的tomcat环境中没有问题...它可能可以打开数千个文件，我不知道您的应用程序，但这也可能是某些故障的迹象。如果是这样，您刚刚允许了该漏洞的影响变得更加严重:( 如果您能解释为什么tomcat需要打开数千个文件，那很好，但如果不能...哎呀。
“正常”可能因所做的事情而异，但默认情况下将限制设置得非常高会使ulimit失去意义，并允许任何进程使用荒谬的资源量。对于没有用户的服务器而言，这不如大型多用户环境那么重要，但它仍然是针对有缺陷或被攻击的进程的有用保障。
您的CPU可能会上升，因为您的计算机现在正在执行更多的工作，而不是错误输出。
PS-您需要确保您的tomcat环境中没有问题...它可能可以打开数千个文件，我不知道您的应用程序，但这也可能是某些故障的迹象。如果是这样，您刚刚允许了该漏洞的影响变得更加严重:( 如果您能解释为什么tomcat需要打开数千个文件，那很好，但如果不能...哎呀。
- user3109924
3
是的，预计会有数千个开放连接 - 我们通常有2000-3500个同时用户，并且峰值可达4500个。我们使用30秒的保持活动时间进行长期连接，以避免重复SSL握手的开销。感谢您的回答！ - Jesse Barnum
成千上万的开放套接字/并发用户不一定等于成千上万的打开文件，但如果在您的应用程序中确实如此，那么这就可以解释为什么默认限制4096会引起问题。如果问题直到达到16000个用户才再次出现，那么我就不会担心它。 - user3109924
我的理解是，套接字只是用于通信目的的特殊“文件”。在Unix中创建套接字时，您会得到一个文件描述符作为返回值。所以我不明白为什么打开套接字/连接并不意味着打开文件描述符？？解决10K问题的Web服务器是否具有超过10K个打开文件描述符的限制？？ - Mikki
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接