2012-09-10 18 views
8

मैं एक बड़े प्रयोग के हिस्से के रूप में क्लस्टर पर NetLogo (जावा सिमुलेशन फ्रेमवर्क) सिमुलेशन चलाने की कोशिश कर रहा हूं। मैं (अपेक्षाकृत) सरल सिमुलेशन की प्रतीत होता है कि भारी स्मृति आवश्यकता पर आश्चर्यचकित था। क्लस्टर पर यह "java.lang.OutOfMemoryError: जावा हीप स्पेस" फेंकता है "-Xmx2500M" से कम कुछ भी के लिए अपवाद। एक निष्पादन को चलाने के लिए 5 घंटे लगते हैं। मैंने अपने मैक (आईमैक और मैकबुक प्रो) दोनों पर एक ही प्रयोग चलाया, और उन्होंने "-Xmx1024" के साथ कोई त्रुटि नहीं देकर एक घंटे से भी कम समय में निष्पादित किया। क्लस्टर नौकरियों के लिए "-XX: MaxPermSize = 250M" की आवश्यकता होती है जबकि मेरे मैक पर डिफ़ॉल्ट से ऊपर कोई वृद्धि आवश्यक नहीं होती है। मैं सभी मामलों में सटीक उसी जार का उपयोग करके, वही कोड चलाता हूं, वही इनपुट करता हूं।वही प्रोग्राम, एक ही जेवीएम, लेकिन विभिन्न मशीनों पर काफी अलग मेमोरी आवश्यकताएं और निष्पादन समय - क्यों?

64 बिट JVMs प्रत्येक मामले में उपयोग किया जाता है (और जहाँ तक पता के रूप में मैं इन सुंदर समान हैं):

<on the cluster> 
$ java -version 
java version "1.6.0_26" 
Java(TM) SE Runtime Environment (build 1.6.0_26-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) 

<on my macs> 
$ java -version 
java version "1.6.0_31" 
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-10M3646) 
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) 

और मैं (सभी मामलों में ग्राहक JVM चला रहा हूँ शुरू में क्लस्टर पर सर्वर का उपयोग किया गया था, स्विचिंग ग्राहक को कोई फर्क नहीं पड़ता)। मैंने जावा 7 के साथ क्लस्टर पर निष्पादन करने की कोशिश की है, वही विशाल स्मृति और निष्पादन समय के मुद्दे।

मैं पूरी तरह से परेशान हूं, मैंने इसे समझाया नहीं है। क्या इससे पहले कोई भी इस पर आ गया है? किसी भी मदद की बहुत सराहना की!

+0

हो सकता है कि आपको -x: + HeapDumpOnOutOfMemoryError के साथ एक हीप डंप बनाना चाहिए और फिर मैट का उपयोग करना या स्मृति का उपयोग करने के समान दिखाना चाहिए। –

+0

मैं विजुअलVM या आपके किट जैसे वाणिज्यिक मेमोरी प्रोफाइलर का उपयोग करूंगा। –

+0

मुझे लगता है कि आपके पास दो अलग-अलग जेवीएम संस्करण भी हैं। यह नहीं कह रहा कि यह आपका मुद्दा है, लेकिन यह योगदान दे सकता है। – Matt

उत्तर

3

मुझे संदेह है कि किसी के पास तेज नेटवर्क या डिस्क IO है। यदि आप डिस्क पर लिखने के लिए कतार का उपयोग कर रहे हैं या नेटवर्क पर लिखते हैं जहां एक कंप्यूटर रख सकता है और दूसरा नहीं कर सकता है, तो कतार मशीन को धीमा कर सकती है और असीमित मात्रा में स्मृति का उपयोग कर सकती है।

आप तेजी से नेटवर्क आईओ है, तो यह भी कर सकते हैं डेटा तेजी से भेजने के लिए (कतारों छोटे रखने के लिए), या यह मतलब हो सकता है आपको प्राप्त डेटा बहुत तेजी से (जिसका अर्थ कतार तेजी से बढ़ सकता है की तुलना में वे खपत होती है)

एक बहुत निर्भर करता है मदद वास्तव में आपका आवेदन क्या करता है। जब आपका प्रोग्राम ओओएमई प्राप्त करता है तो मेरा सुझाव है कि आपको एक ढेर डंप प्राप्त करें और इसका विश्लेषण करें और संग्रह (उदा। कतार) की तलाश करें जो बहुत सारी स्मृति का उपभोग कर रहे हैं।

+0

बहुत तेज़ उत्तर के लिए धन्यवाद। आईओ गति पहले सुझावों में से एक थी। क्लस्टर बहुत धीमा है, और यह मेरी मशीनों की तुलना में बहुत धीमी प्रारंभिकता बताता है। हालांकि, एक बार चलने वाला कार्यक्रम, अंत तक (5 घंटे बाद) डिस्क तक पढ़/लिखता नहीं है, और एक फ़ाइल में एक पंक्ति लिखता है जब यह करता है। मुझे यह भी कहना चाहिए कि इन परीक्षणों के दौरान क्लस्टर पर कोई और नहीं चल रहा है। मैं ढेर डंप में देखूंगा, लेकिन औसत समय में, कोई अन्य सुझाव? – user1660640

+0

यदि आप क्लस्टर अनुकरण कर रहे हैं, तो क्या आपके पास लूपबैक पर भी कोई नेटवर्क IO है? गति डेटा को लूपबैक पर स्थानांतरित किया जा सकता है और प्रोसेसर और ओएस द्वारा नाटकीय रूप से भिन्न हो सकता है। –

+0

पूरे काम (एक भी काम) एक एकल क्लस्टर नोड पर निष्पादित किया जाता है: विचार एक बार में कई सौ तरह के काम चलाने के लिए है। आवश्यक नोड्स के बीच कोई संचार नहीं है, प्रत्येक नौकरी पूरी तरह से अपनी जावा प्रक्रिया के रूप में स्वयं निहित है। – user1660640

0

मुझे संदेह है कि समस्या यह है कि आप सर्वर JVM का उपयोग कर रहे हैं। क्लाइंट जेवीएम 64 बिट मशीनों पर उपलब्ध नहीं है। भले ही आप क्लाइंट JVM के लिए पूछें, यह आपको सर्वर एक देगा।