Play framework scala - слишком много открытых файлов - как на производстве

Question

В следующем примере я использую Play framework 2.4.0 со Scala 2.11.7.

я подчеркиваю простое приложение игры с Гатлинга, инъекционные 5000 пользователей более 60 секунд, и через несколько секунд, сервер воспроизведения возвращает следующее:

«Не удалось принять соединение.» и "java.io.IOException: Слишком много открытых файлов в системе".

Вот ассоциированная StackTrace:

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>?

Answer 1

Самый надежный способ проверить это:

кошки/Proc/PID/пределы

Вы увидите:

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

Чтобы увидеть текущую оболочку, вы можете всегда:

ulimit -a

И получить

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

Changing это лучше всего сделать для всей системы с помощью /etc/security/limits.conf Но вы можете использовать ULIMIT -n для изменения только для текущей оболочки.

С точки зрения того, как справиться с этой ситуацией, просто нет альтернативы наличию достаточного количества дескрипторов файлов. Установите его высоко, и если он ударит, есть утечка или вы работаете для facebook. В производстве, я считаю, что общая рекомендация составляет 16 тысяч.