【问题标题】:Is there any downside to setting ulimit really high?将 ulimit 设置得很高有什么缺点吗?
【发布时间】:2014-03-02 17:27:16
【问题描述】:

我在 Ubuntu 12 上使用 Tomcat7 时遇到了太多打开文件的问题,因此我将打开文件数量的硬限制和软限制分别从 4096 和 1024 增加到 16384。现在我没有得到任何更多关于打开文件的错误,但总体 CPU% 似乎有所上升。增加最大文件的数量是否也会消耗 CPU 时间?如果不是,为什么不把 ulimit 设置的非常高呢?

【问题讨论】:

  • 我经常将我的打开文件描述符限制设置为一百万。我从未注意到任何性能影响(当然,除了我的程序再次开始工作。)

标签: ubuntu tomcat7 ulimit


【解决方案1】:

ulimit 存在的全部原因是通过防止进程使用比“正常”更多的资源来保护系统的整体性能。

“正常”可能会因您正在执行的操作而有所不同,但默认情况下将限制设置得非常高会破坏 ulimit 的目的,并允许任何进程消耗大量资源。在没有用户的服务器上,这没有大型多用户环境那么重要,但它仍然是防止错误或被利用进程的有用保护措施。

您的 CPU 可能刚刚上升,因为您的计算机现在正在做更多的工作而不是出错。

PS - 你想确保你的 tomcat 环境也没有问题......打开数千个文件可能没问题,我不知道你的应用程序,但这也可能是一个迹象东西出了问题。如果是这样,您只是让错误的影响变得可能更糟:(如果您能解释为什么 tomcat 需要打开数千个文件,那很酷,但如果不是……哎呀。

【讨论】:

  • 是的,预计会有数千个打开的连接 - 我们通常有 2000-3500 个同时用户,峰值为 4500。我们使用 30 秒的保活时间进行长期连接以避免开销重复的 SSL 握手。感谢您的回答!
  • 数千个打开的套接字/并发用户不必等于数千个打开的文件,但如果在您的应用程序中确实如此,那么这就解释了为什么默认限制 4096 会导致问题。如果在您达到 16000 个用户之前问题不会再次出现,我不会担心。
  • @user3109924 我的理解是socket不过是一个特殊的文件,用于通信目的。你在 Unix 中创建一个套接字,你会得到一个文件描述符作为返回值。所以我不明白为什么打开套接字/连接并不意味着打开文件描述符?解决 10K 问题的网络服务器是否有超过 10K 的打开文件描述符限制??
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2011-04-26
  • 2011-02-28
  • 2011-11-05
  • 2014-12-18
  • 2010-12-31
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多