समांतरता: जावा थ्रेड्स को सिंक्रनाइज़ेशन और I/O के अलावा अन्य ब्लॉक करने का क्या कारण बनता है?

Question

लघु संस्करण शीर्षक में है।

लंबा संस्करण: मैं जावा का उपयोग कर वैज्ञानिक अनुकूलन के लिए एक कार्यक्रम पर काम कर रहा हूं। कार्यक्रम के वर्कलोड को समानांतर और धारावाहिक चरणों में विभाजित किया जा सकता है - समांतर चरणों का अर्थ है कि अत्यधिक समानांतर कार्य किया जा रहा है। प्रोग्राम को तेज़ करने के लिए (यह घंटों/दिनों तक चलता है) मैं जिस मशीन का उपयोग कर रहा हूं उस पर सीपीयू कोर की संख्या के बराबर कई धागे बनाते हैं - आम तौर पर 4 या 8 - और उनके बीच काम को विभाजित करें। मैं फिर इन धागे को शुरू करता हूं और एक धारावाहिक चरण में आगे बढ़ने से पहले उन्हें() में शामिल करता हूं।

अभी तक इतना अच्छा है। मुझे परेशान करने वाला यह है कि समानांतर चरणों का सीपीयू उपयोग और गति "सैद्धांतिक अधिकतम" के निकट कहीं नहीं है - उदा। अगर मेरे पास 4 कोर हैं, तो मुझे 350-400% "उपयोग" (शीर्ष पर रिपोर्ट के रूप में) के बीच कहीं और देखने की उम्मीद है, लेकिन इसके बजाय यह लगभग 180 और लगभग 310 के बीच उछालती है। केवल एक ही थ्रेड का उपयोग करके, मुझे 100% CPU उपयोग मिलता है।/हे तुल्यकालन

नहीं, मैं के कारण -blocking मैं के कारण -blocking/हे जो भी मेरी समानांतर धागे में चल रहा है:

केवल कारणों मैं धागे पूरी रफ्तार से चलाने के लिए नहीं करने के लिए के बारे में पता कर रहे हैं , न ही कोई सिंक्रनाइज़ेशन - धागे द्वारा साझा की गई एकमात्र डेटा संरचना केवल पढ़ने के लिए होती है, और या तो मूल प्रकार या (गैर-समवर्ती) संग्रह होते हैं। तो मैं अन्य स्पष्टीकरण की तलाश में हूं। एक संभावना यह होगी कि कई धागे कचरे के संग्रह के लिए बार-बार अवरुद्ध हो रहे हैं, लेकिन यह केवल स्मृति दबाव के साथ एक स्थिति में समझ में आता है, और मैं आवश्यक अधिकतम ढेर अंतरिक्ष से ऊपर आवंटित कर रहा हूं।

किसी भी सुझाव की सराहना की जाएगी।

अपडेट: कुछ और जांच के बाद, मैंने सामान्य प्रदर्शन के लिए कोड tweaked और बेहतर उपयोग देख रहा है, भले ही मैंने कुछ भी नहीं बदला है सिंक्रनाइज़ेशन के साथ करना है। हालांकि, कुछ बदलावों के परिणामस्वरूप कम नए हीप आवंटन में विशेष रूप से इटरेटर्स और अस्थायी बॉक्स किए गए नंबर (उच्च प्रदर्शन जावा कंप्यूटिंग के लिए सीईआरएन "कोल्ट" लाइब्रेरी यहां उपयोगी था: बुनियादी प्रकारों के लिए IntArrayList, DoubleArrayList आदि जैसे संग्रह प्रदान करता है।)। तो मुझे लगता है कि कचरा संग्रह शायद अपराधी था।

Answer 1

स्विंग में एक ही थ्रेड पर चलने वाले सभी ग्राफिक्स ऑपरेशंस। यदि वे स्क्रीन पर प्रतिपादन कर रहे हैं तो वे प्रभावी रूप से इस धागे तक पहुंच के लिए संघर्ष करेंगे।

यदि आप विंडोज़ पर चल रहे हैं, तो सभी ग्राफिक्स ऑपरेशंस एक थ्रेड पर चलते हैं चाहे कोई फर्क नहीं पड़ता। अन्य ऑपरेटिंग सिस्टम की समान सीमाएं होती हैं।

कभी-कभी थ्रेडेड श्रमिकों की उचित ग्रैन्युलरिटी प्राप्त करना काफी कठिन होता है, और कभी-कभी उन्हें बहुत बड़ा या बहुत छोटा बनाना आसान होता है, जो आम तौर पर आपको सभी कोरों का 100% से कम उपयोग प्रदान करता है।

यदि आप अधिक गुई नहीं दे रहे हैं, तो सबसे अधिक संभावना है कि आप कुछ साझा संसाधनों के बारे में सोचने से ज्यादा विरोध कर रहे हैं। यह आसानी से jprofiler जैसे प्रोफाइलर उपकरणों के साथ देखा जाता है। बीएम के झटके की तरह कुछ वीएम आपको सीधे बॉक्स से बाहर बता सकते हैं।

यह उन स्थानों में से एक है जहां आप अनुमान लगाने पर काम नहीं करना चाहते हैं। एक प्रोफाइलर प्राप्त करें!

Answer 2

सबसे पहले, जीसी केवल "स्मृति दबाव के साथ स्थिति में नहीं होगा", लेकिन किसी भी समय जेवीएम फिट (अप्रत्याशित, जहां तक ​​मुझे पता है) दिखाई देता है।

दूसरा, यदि आपके धागे ढेर में स्मृति आवंटित करते हैं (आप उल्लेख करते हैं कि वे संग्रह का उपयोग करते हैं तो मुझे लगता है कि वे ढेर में स्मृति आवंटित करते हैं), आप कभी भी यह सुनिश्चित नहीं कर सकते कि यह स्मृति वर्तमान में रैम या वर्चुअल मेमोरी पेज पर है या नहीं (ओएस निर्णय लेता है), और इस प्रकार "मेमोरी" तक पहुंच अवरुद्ध I/O पहुंच उत्पन्न कर सकता है!

अंत में, जैसा कि एक पूर्व उत्तर में सुझाया गया है, आपको यह जांचना उपयोगी हो सकता है कि प्रोफाइलर का उपयोग करके क्या होता है (या यहां तक ​​कि जेएमएक्स निगरानी कुछ संकेत दे सकती है)।

मेरा मानना ​​है कि जब तक आप अधिक ठोस (कोड) जानकारी प्रदान नहीं करते हैं, तब तक आपकी समस्या पर और संकेत प्राप्त करना मुश्किल होगा।

Answer 3

आप अपनी गणना के लिए पूर्ण CPU क्षमता का उपयोग करने का प्रयास करते हैं लेकिन ओएस स्वयं भी संसाधनों का उपयोग करता है। इसलिए ध्यान रखें कि ओएस अपनी आवश्यकताओं को पूरा करने के लिए आपके कुछ निष्पादन को अवरुद्ध कर देगा।

Answer 4

सबसे पहले, मुझे लगता है कि आप बॉक्स पर कोई अन्य महत्वपूर्ण काम नहीं कर रहे हैं। यदि आप हैं, तो यह स्पष्ट रूप से चीजों के साथ गड़बड़ करने जा रहा है।

यदि आप वास्तव में कुछ साझा नहीं कर रहे हैं तो यह बहुत अजीब लगता है। क्या आप हमें और अधिक विचार दे सकते हैं कि कोड वास्तव में क्या कर रहा है?

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

Answer 5

यह भी एक महत्वपूर्ण बात है: आप किस हार्डवेयर का उपयोग करते हैं? ईजी। 4-8 कोर का मतलब यह हो सकता है कि आप सनस नियाग्रा सीपीयू में से एक पर काम करते हैं। और 4-8 कोर होने के बावजूद उनके पास FPU एस है। वैज्ञानिक सामग्री की गणना करते समय यह हो सकता है कि एफपीयू बाधा है।

Answer 6

आप कुछ स्तर पर सिंक्रनाइज़ेशन कर रहे हैं।

शायद कचरा संग्रह सहित स्मृति आवंटन प्रणाली में ही। जबकि जेवीएम विक्रेता ने इन क्षेत्रों में न्यूनतम से अवरुद्ध रखने के लिए काम किया है, वे इसे शून्य तक कम नहीं कर सकते हैं। शायद आपके आवेदन के बारे में कुछ इस क्षेत्र में एक कमजोर बिंदु पर जोर दे रहा है।

स्वीकृत ज्ञान "अपनी याददाश्त पुनः दावा पूल नहीं बनाओ, जीसी आपके लिए काम करें"। यह ज्यादातर समय सच है लेकिन कोड के कम से कम एक टुकड़े में नहीं है (प्रोफाइलिंग के साथ सिद्ध)। शायद आपको अपने ऑब्जेक्ट आवंटन को कुछ प्रमुख तरीके से पुन: कार्य करने की आवश्यकता है।

Answer 7

जेआरॉकिट मिशन कंट्रोल के साथ आने वाले विलंबता विश्लेषक का प्रयास करें। यह आपको दिखाएगा कि सीपीयू क्या कर रहा है जब यह कुछ भी नहीं कर रहा है, अगर एप्लिकेशन फ़ाइल I/O, TLA-fetches, ऑब्जेक्ट आवंटन, थ्रेड निलंबन, JVM-locks, gc-pauses इत्यादि का इंतजार कर रहा है। आप संक्रमण भी देख सकते हैं उदाहरण के लिए जब एक धागा दूसरे उठता है। ओवरहेड नगण्य है, 1% या तो।

अधिक जानकारी के लिए यह blog देखें। उपकरण विकास के लिए उपयोग करने के लिए स्वतंत्र है और आप इसे डाउनलोड कर सकते हैं here