播放框架scala - 打开的文件太多 - 如何在生产中答案

【问题标题】：Play framework scala - too many open files - how to in production播放框架scala - 打开的文件太多 - 如何在生产中
【发布时间】：2015-10-12 23:13:54
【问题描述】：

在下文中，我将 Play framework 2.4.0 与 Scala 2.11.7 一起使用。

我正在强调一个带有 Gatling 的简单游戏应用程序，在 60 秒内注入 5000 个用户，并且在几秒钟内，游戏服务器返回以下内容：

“无法接受连接。”和“java.io.IOException：系统中打开的文件太多”。

这是相关的堆栈跟踪：

22:52:48.943 [application-akka.actor.default-dispatcher-12] INFO  play.api.Play$ - Application started (Dev)
22:53:08.939 [New I/O server boss #17] WARN  o.j.n.c.s.nio.AbstractNioSelector - Failed to accept a connection.
java.io.IOException: Too many open files in system
        at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) ~[na:1.8.0_45]
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422) ~[na:1.8.0_45]
        at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250) ~[na:1.8.0_45]
        at org.jboss.netty.channel.socket.nio.NioServerBoss.process(NioServerBoss.java:100) [netty-3.10.3.Final.jar:na]
        at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) [netty-3.10.3.Final.jar:na]
        at org.jboss.netty.channel.socket.nio.NioServerBoss.run(NioServerBoss.java:42) [netty-3.10.3.Final.jar:na]
        at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.10.3.Final.jar:na]
        at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.10.3.Final.jar:na]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_45]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_45]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]

我想这是由于系统的ulimit（可以确认吗？），如果是这样，我的问题如下：

在生产环境中如何管理这种错误？这是通过使用ulimit -n <high_value> 设置高值吗？

【问题讨论】：

Java Too Many Open Files 的可能重复项
通过增加某些用户或全局打开文件数量的限制来避免此错误。这是一个操作系统级别的问题，答案取决于您的操作系统类型和版本。建议确定，然后为您的平台搜索特定程序。对于 CentOS/Fedora，一个不错的程序是pro.benjaminste.in/post/318453669/…。
感谢您的回答。增加限制是生产环境的唯一/最佳解决方案吗？此外，正如我在其他评论中所述，文件系统、操作系统或其他正在运行的应用程序在延迟、性能或其他方面是否存在任何缺陷？还是说“ulimit -n 高价值”只是没有缺点的标准解决方案？即使操作系统的 ulimit 最高，如果播放应用程序的问题仍然存在怎么办？谢谢！

标签： scala playframework production

【解决方案1】：

最简单的检查方法是：

cat /proc/PID/limits

你会看到：

Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
...
Max open files            1024                 1024                 files
...

要查看您当前的外壳，您可以随时：

ulimit -a

得到

...
open files                      (-n) 1024
...

最好通过 /etc/security/limits.conf 在系统范围内进行更改但您可以使用 ulimit -n 仅更改当前 shell。

就如何处理这种情况而言，除了拥有足够的文件描述符之外别无选择。将其设置为高，如果它命中，则存在泄漏或您为 facebook 工作。在生产中，我认为一般建议是 16k。

【讨论】：

感谢您的回答！但是，我不是在寻求解决 ulimit 问题的解决方案，而是在生产中如何管理这种错误。换句话说，增加这个打开文件的限制是一个很好的解决方案吗？文件系统、延迟、其他正在运行的应用程序的性能或其他方面是否有任何缺点？还是 ulimit -n 具有高值已经是选择的解决方案？如果即使使用此操作系统的最高 ulimit，播放应用程序的问题仍然存在怎么办？谢谢！
好的。除了拥有足够的文件描述符之外，别无选择。将其设置为高，如果它命中，则存在泄漏或您为 facebook 工作。在生产中，我认为一般建议是 16k。
谢谢！我会接受这个答案。顺便问一下，有什么方法可以检测到播放应用程序中可能存在的泄漏？
对 API 或 ab (apache bench) 运行 JMeter 一段时间，看看是否可以让它崩溃。
我已经用 Gatling 做到了这一点，并且应用程序在 5000 名用户之前就崩溃了，但我不知道如何识别这些文件是由什么创建的？