पहले से ही इसी तरह के प्रश्न पूछ चुके हैं, लेकिन इसे हटा दिया, क्योंकि मैंने सोचा कि मैंने इसे ठीक किया है, लेकिन मैं गलत था।प्ले फ्रेमवर्क/नेटटी सॉकेट जारी नहीं करता
मैं अपनी वेब परियोजनाओं में से एक के लिए उत्पादन में प्ले फ्रेमवर्क का उपयोग कर रहा हूं। समय-समय पर Play मुख्य पृष्ठ प्रस्तुत नहीं करता है या कुछ स्थिर सामग्री फ़ाइलों को वापस नहीं करता है।
पहला स्क्रीनशॉट फ़ायरबग कंसोल प्रदर्शित करता है, साइट की लोडिंग शुरुआत में, होम पेज की सेवा करते समय अटक जाती है। 
दूसरा स्क्रीनशॉट फिडलर कंसोल प्रदर्शित करता है, जब 2 स्थिर संसाधन लोड नहीं होते हैं।
शुरू में आवेदन ठीक चलता है, यह 5-7 दिनों के लिए काम करने के लिए है और मैं इस मुद्दे को देख सकते हैं। पुन: पेश करना मुश्किल है, यह 15 में से 1 बार होता है, मुझे कैश डेटा और पेज को फिर से लोड करना होगा। (एफएफ में सीआरटीएल-एफ 5 दबाकर)। विभिन्न मशीनों और ओएस के अधिकांश ब्राउज़रों में समस्या का पुनरुत्पादन किया जा सकता है। प्रारंभ में, मैं सोच रहा था कि होस्टिंग प्रदाता के साथ कुछ समस्याएं हैं। लेकिन मैंने इसे बदल दिया है और मुद्दा नहीं चला है।
नाटक का संस्करण 1.2.5 है। 1.2.2 भी कोशिश की। Play CentOS-5-32 बिट्स पर स्टैंडअलोन सर्वर के रूप में चल रहा है।
मुझे संदेह है कि Netty के साथ कुछ समस्याएं हैं जिनका उपयोग प्ले फ्रेमवर्क द्वारा किया जाता है। नेटटी 3.5.7 फाइनल जार प्ले द्वारा उपयोग किया जाता है।
cd /proc/28761/fd
ls -l | wc -l
337
कुछ दिनों खोला फ़ाइल वर्णनकर्ता की संख्या 140 से 350 नोट करने के लिए बढ़ता है, कि शुरुआत में वेबसाइट के लिए औसत लोड और बाद में एक ही है।
मैं प्रक्रिया द्वारा खोले गए कई सॉकेट देख सकता हूं, जिन्हें बाद में जारी नहीं किया जाता है।
lrwx------ 1 root root 64 Nov 11 10:34 300 -> socket:[1079566]
lrwx------ 1 root root 64 Nov 11 10:34 301 -> socket:[1079568]
lrwx------ 1 root root 64 Nov 11 10:34 302 -> socket:[1149958]
lrwx------ 1 root root 64 Nov 11 10:34 303 -> socket:[1160807]
lrwx------ 1 root root 64 Nov 11 10:34 304 -> socket:[1160605]
lrwx------ 1 root root 64 Nov 11 10:34 305 -> socket:[1157435]
lrwx------ 1 root root 64 Nov 11 10:34 306 -> socket:[1160607]
lrwx------ 1 root root 64 Nov 11 10:34 307 -> socket:[1160609]
lrwx------ 1 root root 64 Nov 11 10:34 308 -> socket:[1155542]
lrwx------ 1 root root 64 Nov 11 10:34 309 -> socket:[1120231]
अद्यतन
आवेदन की शुरुआत पर खोला TCP कनेक्शन की संख्या (चलने के कुछ ही घंटों के) चल रहा है, खुले टीसीपी की संख्या के दिनों 63.
Total: 150 (kernel 181)
TCP: 63 (estab 38, closed 5, orphaned 0, synrecv 0, timewait 3/0), ports 44
Transport Total IP IPv6
* 181 - -
RAW 0 0 0
UDP 7 4 3
TCP 58 9 49
INET 65 13 52
FRAG 0 0 0
2 के बाद है कनेक्शन 4 9 0 है।
[[email protected] fd]# ss -s
Total: 459 (kernel 490)
TCP: 378 (estab 271, closed 23, orphaned 0, synrecv 0, timewait 9/0), ports 37
Transport Total IP IPv6
* 490 - -
RAW 0 0 0
UDP 7 4 3
TCP 355 12 343
INET 362 16 346
FRAG 0 0 0
यह सब खोला गया टी सीपी कनेक्शन http कनेक्शन हैं (डेटाबेस या कोई अन्य नहीं)। वेबसाइट पर औसत भार हर समय समान होता है, लेकिन खोले गए फाइलों की संख्या डिस्क्रिप्टर और खुले सॉकेट too many open files exception
प्रारंभ में आवेदन 9-15 नए I/O थ्रेड (नेटटी श्रमिक) के साथ शुरू होता है। नेटी धागे के अधिकांश समय चलने वाले राज्य में हैं। और ~ 16 प्ले थ्रेड जो प्रतीक्षा राज्य में हैं।
नेटटी श्रमिकों की चल रही संख्या के कुछ दिनों के बाद 27 हो गया। मैं नेटटी विशेषज्ञ नहीं हूं, यह सुनिश्चित नहीं है कि यह सामान्य व्यवहार है या नहीं।
कुछ धागे डेडलॉक चला गया: 1 प्ले थ्रेड और 1 नेटटी थ्रेड। इसके अलावा एक और प्ले थ्रेड है जो पहले प्ले थ्रेड द्वारा लॉक किया गया है। तो कुल मिलाकर 3 लॉक धागे।मुझे यकीन है कि इस गतिरोध समस्या का मुख्य कारण नहीं हैं, लेकिन मूल कारण एक ही
Name: New I/O worker #21
State: BLOCKED on [email protected] owned by: play-thread-2
Total blocked: 44 Total waited: 9
Stack trace:
org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:188)
org.jboss.netty.handler.stream.ChunkedWriteHandler.handleUpstream(ChunkedWriteHandler.java:140)
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:792)
org.jboss.netty.channel.SimpleChannelUpstreamHandler.channelClosed(SimpleChannelUpstreamHandler.java:212)
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:93)
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:792)
org.jboss.netty.handler.codec.replay.ReplayingDecoder.cleanup(ReplayingDecoder.java:636)
org.jboss.netty.handler.codec.replay.ReplayingDecoder.channelClosed(ReplayingDecoder.java:533)
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:93)
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)
org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:476)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:631)
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:109)
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:66)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:780)
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:55)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:785)
org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:111)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
org.jboss.netty.channel.Channels.close(Channels.java:821)
org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:194)
org.jboss.netty.channel.ChannelFutureListener$1.operationComplete(ChannelFutureListener.java:41)
org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:399)
org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:385)
org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:334)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:493)
- locked [email protected]
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromTaskLoop(AbstractNioWorker.java:431)
org.jboss.netty.channel.socket.nio.AbstractNioChannel$WriteTask.run(AbstractNioChannel.java:364)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.processWriteTaskQueue(AbstractNioWorker.java:349)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:245)
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:38)
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
दूसरा धागा हो सकता है:
Name: play-thread-2
State: BLOCKED on [email protected] owned by: New I/O worker #21
Total blocked: 23 Total waited: 34 778
Stack trace:
org.jboss.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:654)
org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:408)
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:127)
org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:66)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:780)
org.jboss.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:63)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:785)
org.jboss.netty.channel.Channels.write(Channels.java:733)
org.jboss.netty.handler.stream.ChunkedWriteHandler.flush(ChunkedWriteHandler.java:262)
- locked [email protected]
org.jboss.netty.handler.stream.ChunkedWriteHandler.handleDownstream(ChunkedWriteHandler.java:121)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591)
org.jboss.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582)
org.jboss.netty.channel.Channels.write(Channels.java:712)
org.jboss.netty.channel.Channels.write(Channels.java:679)
org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:245)
play.server.PlayHandler.serveStatic(PlayHandler.java:886)
play.server.PlayHandler$NettyInvocation.init(PlayHandler.java:182)
play.Invoker$Invocation.run(Invoker.java:276)
play.server.PlayHandler$NettyInvocation.run(PlayHandler.java:229)
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
java.util.concurrent.FutureTask.run(FutureTask.java:138)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
अद्यतन
मैं टोमकैट 7 के लिए एक ही वातावरण में उसी प्ले एप्लिकेशन को तैनात किया गया। 24 घंटे बीत चुके हैं और समस्या चली गई है, खुले टीसीपी कनेक्शन की संख्या स्थिर बनी हुई है। खुले फाइलों की संख्या वर्णक ~ 70 से अधिक नहीं है। यह वही उत्पादन मेजबान, एक ही डेटाबेस और एप्लिकेशन के समान उपयोगकर्ता हैं।
अनुरोध Play ऐप्लिकेशन सीधे (आदि अपाचे,) हिट या एक प्रॉक्सी के माध्यम से वे जाते हैं? –
प्रॉक्सी का उपयोग नहीं, अनुरोध सीधे – Anton
आप सर्वर साइड पर किसी भी धागा डंप किया खेलने के लिए जाना है, शायद वहाँ कुछ सर्वर खेलने को रोकने धागा –