Jetty IOException: Zu viele offene Dateien
Ich bin mit Steg auf einer website zu tun rund 100 Anfragen/Sek., mit nginx in der front. Mir ist nur aufgefallen in den logs, nur ein paar Minuten nachdem ich ein bereitstellen und starten von Jetty,, für ein wenig, während er spammt:
java.io.IOException: Too many open files
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163)
at org.mortbay.jetty.nio.SelectChannelConnector$1.acceptChannel(SelectChannelConnector.java:75)
at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:673)
at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:192)
at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:708)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)Für eine minute oder zwei.
Ich habe ein "lsof -u jetty" und sah Hunderte von Zeilen von:
java 15892 jetty 1020u IPv6 298105434 0t0 TCP 192.168.1.100:http-alt->192.168.1.100:60839 (ESTABLISHED)
java 15892 jetty 1021u IPv6 298105438 0t0 TCP 192.168.1.100:http-alt->192.168.1.100:60841 (ESTABLISHED)
java 15892 jetty 1022u IPv6 298105441 0t0 TCP 192.168.1.100:http-alt->192.168.1.100:60842 (ESTABLISHED)
java 15892 jetty 1023u IPv6 298105443 0t0 TCP 192.168.1.100:http-alt->192.168.1.100:60843 (ESTABLISHED)Wo 192.168.1.100 ist die Server interne IP.
Wie Sie sehen können, stieg die Anzahl der offenen Dateien in den Standard-max 1024. Ich könnte nur erhöhen, aber ich Frage mich, warum dies passiert in den ersten Platz? Es ist in jettys nio socket-Akzeptor, so ist dies verursacht durch einen Sturm-Verbindung anfordert?
- Jeder socket ist eine Datei, so wird jede Verbindung hat eine Datei (Deskriptor), auch wenn es wartet. Was bedeutet eine Anforderung in der Regel tun, und wie lange dauert es? Mit 100 requests/Sekunde auf jetty, das Abfragen einer lokalen db-server 2 s / Anfrage Sie haben bereits 400 "Dateien".
- Die meisten meiner Anfragen nehmen Sie nur ein paar ms, wenn die Anwendung zum ersten mal startet, Sie kann einige Sekunden dauern, das ist, was ich denke, passiert es. Der garbage collector auch gelegentlich die "stop the world" - pause, die bewirkt, dass alle Anfragen zu stapeln für eine kurze Zeit, verursacht dies, zeitweise. Ich werde an der Optimierung der GC später, in der Zwischenzeit, ich habe gerade erhöht das limit.
- Ich bin immer etwas ähnliches in Tomcat6 von Zeit zu Zeit, ursprünglich dachte, es war das Betriebssystem werfen sein Spielzeug. Auch nur erhöht das limit als temp-Lösung.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Zwar kann es ein bug im Jetty, ich denke, eine weit wahrscheinlichere Erklärung ist, dass die geöffnete Datei ulimits zu niedrig sind. In der Regel die 1024 Standard ist einfach nicht genug für web-Server, mit mäßiger Nutzung.
Eine gute Möglichkeit, dies zu testen, ist die Verwendung von apache bench zu simulieren, die den eingehenden Datenverkehr, die Sie sehen. Läuft diese auf einem remote-host zu generieren, 1000 Anfragen pro über 10 gleichzeitige verbindungen.
Zählen nun die buchsen auf Ihrem web-server mit netstat...
Hoffentlich, was Sie finden, ist, dass Ihre Steckdosen plateau bei einem bestimmten Wert auch nicht dramatisch größer als 1024 (bei mir ist auf 16384).
Eine weitere gute Sache, um sicherzustellen, ist, dass die verbindungen geschlossen werden, richtig in Ihrem business-Logik.
Wenn Sie sehen, diese Zahl weiter wachsen während des gesamten Lebenszyklus Ihrer Anwendung, Sie können fehlen ein paar Anrufe zu Verbindung.schließen().