2011-06-12 14 views
9

मैं जेटी को लगभग 100 अनुरोध/सेकंड करने वाली वेबसाइट पर चल रहा हूं, जिसमें nginx सामने है। मैं सिर्फ लॉग में देखा, केवल कुछ ही मिनट एक तैनाती कर रहे हैं और जेट्टी शुरू, कि एक छोटे के लिए यह स्पैमिंग था, जबकि बाद:जेट्टी IOException: बहुत सारी खुली फ़ाइलें

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) 

एक या दो मिनट के लिए। मैं एक "lsof -u घाट" किया था और की तर्ज के सैकड़ों देखा:

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) 

कहाँ 192.168.1.100 सर्वर आंतरिक IP है।

जैसा कि आप देख सकते हैं, यह खुली फ़ाइलों की संख्या 1024 के डिफ़ॉल्ट अधिकतम तक लाया। मैं इसे बढ़ा सकता हूं, लेकिन मुझे आश्चर्य है कि यह पहली जगह क्यों होता है? यह जेटी के एनओ सॉकेट स्वीकार्य में है, तो क्या यह कनेक्शन अनुरोधों के तूफान के कारण होता है?

+1

प्रत्येक सॉकेट एक फ़ाइल है, इसलिए प्रत्येक कनेक्शन में फ़ाइल (डिस्क्रिप्टर) है, भले ही यह प्रतीक्षा हो। आमतौर पर अनुरोध क्या करता है, और इसमें कितना समय लगता है? जेटी पर 100 अनुरोध/सेकंड के साथ, एक स्थानीय डीबी सर्वर से पूछताछ 2 एस/अनुरोध लेने से पहले आपके पास 400 "फाइलें" हैं। – extraneon

+0

मेरे अधिकांश अनुरोध केवल कुछ एमएस लेते हैं, हालांकि जब एप्लिकेशन पहली बार शुरू होता है तो उन्हें कई सेकंड लग सकते हैं, जो मुझे लगता है कि वहां हुआ था। कचरा कलेक्टर कभी-कभी "दुनिया को रोक" रोकता है, जिससे सभी अनुरोधों को थोड़े समय के लिए ढेर कर दिया जाता है, जिससे यह अंतःक्रियात्मक हो जाता है। मुझे बाद में जीसी को ट्यून करना होगा, इस बीच में मैंने अभी सीमा बढ़ा दी है। –

+1

मुझे समय-समय पर टॉमकैट 6 में कुछ मिल रहा है, शुरुआत में सोचा था कि यह अपने खिलौने फेंकने वाला ऑपरेटिंग सिस्टम था। एक अस्थायी समाधान के रूप में सीमा को भी बढ़ाया। –

उत्तर

11

जेटी में एक बग हो सकता है, मुझे लगता है कि एक बहुत अधिक संभावना स्पष्टीकरण यह है कि आपकी खुली फ़ाइल उलटी बहुत कम है। आम तौर पर 1024 डिफ़ॉल्ट डिफ़ॉल्ट उपयोग के साथ वेब सर्वर के लिए पर्याप्त नहीं है।

इसका परीक्षण करने का एक अच्छा तरीका यह है कि आप देख रहे इनबाउंड ट्रैफ़िक को अनुकरण करने के लिए अपाचे बेंच का उपयोग करें। रिमोट होस्ट पर इसे चलाने से प्रत्येक 10 समवर्ती कनेक्शनों में 1000 अनुरोध उत्पन्न होंगे।

ab -c 10 -n 1000 [http://]hostname[:port]/path 

अब netstat का उपयोग कर अपने वेब सर्वर पर सॉकेट गिनती ...

netstat -a | grep -c 192.168.1.100 

उम्मीद है कि आप क्या मिलेगा कि आपके सॉकेट कुछ मूल्य नहीं नाटकीय रूप से 1024 से बड़ा (मेरा है पर पठार जाएगा 16384 पर)।

यह सुनिश्चित करने के लिए एक और अच्छी बात यह है कि कनेक्शन आपके व्यापार तर्क में ठीक से बंद हो रहे हैं।

netstat -a | grep -c CLOSE_WAIT 

यदि आप देखते हैं तो यह संख्या आपके आवेदन के जीवन चक्र से अधिक विकसित करने के लिए जारी रखते हैं, आप Connection.close करने के लिए कुछ कॉल गायब हो सकता है()।

+0

इसके अतिरिक्त, यदि यह स्पष्ट हो जाता है कि पूर्ण जीसी वास्तव में बहुत अधिक समय ले रहा है, तो जावा के समवर्ती मार्कस्वेप कलेक्टर पर एक नज़र डालें। – jpredham