जावा सीपीयू उपयोग 100% होना चाहिए ... लेकिन यह

Question

नहीं है मैं अपने कोर i7 लैपटॉप पर एक जावा प्रोग्राम चला रहा हूं जिसमें 8 कोर (4 भौतिक, 4 एचटी) हैं। कार्यक्रम 8 समांतर धागे का उपयोग करता है और इसलिए इसे सभी सीपीयू का उपयोग करना चाहिए। '-सेवर' पैरामीटर के साथ चलते समय, यह हर समय 100% पर होता है। इसके बिना, यह लगभग 50% -60% कुल मिलाकर (हमेशा 100% पर चोटियों के साथ बदल रहा है और 30% पर डुबकी)। यहां मुझे अजीब लगता है: जब मैं डीबग में प्रोग्राम चलाता हूं और एक पल का इंतजार करता हूं जहां सीपीयू उपयोग विशेष रूप से कम (30%) होता है और फिर आठ धागे क्या कर रहे हैं, यह देखने के लिए निष्पादन को निलंबित कर दिया जाता है, उनमें से कोई भी अवरुद्ध स्थिति में नहीं है । इसके अलावा, उनके बीच लगभग कोई सिंक्रनाइज़ेशन नहीं है। यहां मैं क्या सोच रहा हूं:

1. सर्वर और क्लाइंट वीएम के बीच क्या अंतर है जो सीपीयू को क्लाइंट में 100% तक पहुंचने से रोक देगा?
2. सिंक्रनाइज़ेशन की अनुपस्थिति में, धागे को पूरी तरह कोर का उपयोग करने से क्या रोक सकता है? (शायद 1)

संपादित करें: यहां एक विचार है: कोड बड़े सरणी आवंटित करता है और उन्हें बहुत जल्दी जीसी में छोड़ देता है। 'नया SomethingBig()' को कॉल करते समय एक थ्रेड सो जाता है और उस स्मृति को आवंटित करने में समय लगता है? यदि थ्रेड के समूह के लिए वीएम हैंडलिंग आवंटन में एक ही प्रक्रिया है, तो मुझे लगता है कि सिंक्रनाइज़ेशन ब्लॉक के बाहर यादृच्छिक रूप से क्यों रोकना प्रतीत होता है ...

संपादित 2: मुझे पूरा यकीन है कि यह है जीसी के कारण अब। अगर मैं डिफ़ॉल्ट 500 एमबी के बजाय वीएम 1500 एमबी देता हूं तो सीपीयू 100% फिर से पहुंचता है। मुझे लगता है कि मंदी सर्वर मोड में नहीं होती है क्योंकि यह डिफ़ॉल्ट रूप से अधिक मेमोरी का उपयोग करती है।

Answer 1

यदि आप जावा थ्रेड कर रहे हैं की निगरानी करना चाहते हैं, तो आपको डीबग मोड में ऐप नहीं चलाया जाना चाहिए और इसे निलंबित करना चाहिए।

बल्कि, आप एकत्र करना चाहिए धागा विशिष्ट अंतराल जहां CPU उपयोग बूंदों में kill -3 <pid> साथ उदासीनता।

आपके दूसरे अपडेट से संबंधित, आपको समय टिकटें के साथ जीसी लॉगिंग सक्षम करना चाहिए और युवा/पूर्ण जीसी संग्रह के समय मंदी/सीपीयू उपयोग बूंदों को सहसंबंधित करना चाहिए।

Answer 2

विशेष रूप से जावा से संबंधित नहीं है, लेकिन आपके पास मौजूद थ्रेड की संख्या आपके सीपीयू का सबसे अच्छा उपयोग करने के लिए कोर की संख्या से अधिक होनी चाहिए, ऐसा इसलिए है क्योंकि बहुत से समय होते हैं जब कोई विशेष धागा निष्पादित नहीं हो सकता है, साथ ही साथ किसी अन्य थ्रेड द्वारा आयोजित एक कंडीशन वैरिएबल पर अधिक स्पष्ट प्रतीक्षा, थ्रेड को अन्य कारणों से भी अवरुद्ध किया जा सकता है जैसे कैश मिस को थ्रेड की प्रतीक्षा करने की आवश्यकता हो सकती है, डेटा को सीपीयू कैश में लोड किया जाएगा, इसे इनपुट के लिए इंतजार करना पड़ सकता है सीपीयू की तुलना में धीमी गति से कुछ स्रोतों से, वर्चुअल मेमोरी पेजिंग आपके थ्रेड का इंतजार कर सकती है। आपके पास कोर की तुलना में अधिक धागे हैं, जब किसी भी धागे को किसी भी कारण से अवरुद्ध कर दिया जाता है, तो दूसरा उस कोर का उपयोग कर सकता है जो मुक्त हो जाता है। एक अच्छा प्रारंभिक मूल्य आपके पास 1.5 कोर की संख्या है।