जावा एप्लिकेशन में उच्च CPU उपयोग - क्यों?

Question

मेरे पास जावा एप्लिकेशन (वेब-आधारित) है जो कई बार कई घंटे के लिए बहुत अधिक CPU उपयोग (लगभग 9 0%) दिखाता है। लिनक्स TOP कमांड यह दिखाता है। आवेदन पुनरारंभ करने पर, समस्या दूर हो जाती है।

तो जांच करने के लिए:

मैं थ्रेड डंप ले क्या धागे कर रहे हैं खोजने के लिए। 'RUNNABLE' राज्य में कई थ्रेड पाए जाते हैं, कुछ अन्य राज्यों में कुछ। बार-बार थ्रेड डंप लेने पर, मुझे कुछ धागे दिखाई देते हैं जो हमेशा 'RUNNABLE' राज्य में मौजूद होते हैं। तो, वे अपराधी प्रतीत होते हैं।

लेकिन मैं निश्चित रूप से यह बताने में असमर्थ हूं कि थ्रेड सीपीयू को घुमा रहा है या एक अनंत लूप में चला गया है (जिससे उच्च CPU उपयोग होता है)।

लॉग आवश्यक रूप से मदद नहीं करते हैं, क्योंकि अपमानजनक कोड कुछ भी लॉगिंग नहीं कर सकता है।

मैं कैसे जांच करूं - एप्लिकेशन का क्या हिस्सा या थ्रेड-थ्रेड उच्च CPU उपयोग कर रहा है? - कोई अन्य विचार?

Answer 1

यदि आपके सेटअप में कोई प्रोफाइलर लागू नहीं है, तो आप this post में निम्न चरणों को थ्रेड की पहचान करने का प्रयास कर सकते हैं।

असल में, वहाँ तीन चरण हैं:

1. रन top -H और उच्चतम सीपीयू के साथ धागे की पीआईडी ​​मिलता है।
2. पीआईडी ​​को हेक्स में परिवर्तित करें।
3. अपने थ्रेड डंप में मिलान HEX PID के साथ थ्रेड के लिए देखो।

Answer 2

आपका पहला दृष्टिकोण Thread.sleep के सभी संदर्भ खोजने के लिए हो सकता है और जाँच करें कि चाहिए:

1. स्लीपिंग करना सही बात है - शायद सावधान उपयोग - आप इंतजार तंत्र यदि संभव हो तो किसी प्रकार का उपयोग करना चाहिए BlockingQueue की सहायता करेगा।

2. सोते समय सही काम करने के लिए है, क्या आप सही समय के लिए सो रहे हैं - यह अक्सर जवाब देने के लिए एक बहुत मुश्किल सवाल है।

मल्टी-थ्रेडेड डिजाइन में सबसे आम गलती विश्वास करने के लिए आप सभी की जब कुछ होता है के लिए प्रतीक्षा कर सब करने की ज़रूरत एक तंग पाश में थोड़ी देर के लिए और सोने के लिए जाँच करने के लिए है। यह शायद ही कभी एक प्रभावी समाधान है - आपको हमेशा घटना के लिए wait पर प्रयास करना चाहिए।

दूसरा सबसे आम मुद्दा लूप के बिना है। यह भी बदतर है और ट्रैक करने के लिए थोड़ा कम आसान है।

Answer 3

इन चरम CPU समय के दौरान, उपयोगकर्ता लोड की तरह क्या है? आप कहते हैं कि यह एक वेब आधारित अनुप्रयोग है, इसलिए जिन अपराधियों को ध्यान में आता है वह स्मृति उपयोग के मुद्दे हैं। यदि आप सत्र में बहुत सारी चीज़ें संग्रहीत करते हैं, उदाहरण के लिए, और सत्र की गणना काफी अधिक हो जाती है, तो ऐप सर्वर इसके बारे में थ्रैशिंग शुरू कर देगा। यह एक ऐसा मामला भी है जहां जीसी आपके द्वारा उपयोग की जा रही योजना के आधार पर मामलों को और खराब कर सकती है। ऐप और सर्वर कॉन्फ़िगरेशन के बारे में अधिक जानकारी अधिक डिबगिंग विचारों की ओर इशारा करते हुए सहायक होगी।

Answer 4

आप कचरा संग्रहण समस्या का शिकार हो सकते हैं।

जब आपके एप्लिकेशन को मेमोरी की आवश्यकता होती है और कचरा कलेक्टर का उपयोग करने के लिए कॉन्फ़िगर किया गया है, तो यह बहुत कम हो जाएगा जो अक्सर कई CPU चक्रों का उपभोग करेगा। यदि यह कुछ भी एकत्र नहीं कर सकता है तो आपकी याददाश्त कम रहेगी, इसलिए इसे बार-बार चलाया जाएगा। जब आप अपने आवेदन को दोबारा तैनात करते हैं तो स्मृति साफ़ हो जाती है और कचरा संग्रह आवश्यक से अधिक नहीं होगा, इसलिए CPU उपयोग तब तक कम रहता है जब तक कि यह फिर से पूर्ण न हो जाए।

आपको जांचना चाहिए अपने आवेदन में कोई संभव स्मृति रिसाव है कि वहाँ और यह अच्छी तरह स्मृति के लिए कॉन्फ़िगर किया गया है कि (जाँच -Xmx पैरामीटर, देख What does Java option -Xmx stand for?)

इसके अलावा, क्या आप वेब ढांचे के रूप में प्रयोग कर रहे हैं? जेएसएफ सत्रों पर बहुत निर्भर करता है और बहुत सारी याददाश्त करता है, सबसे ज्यादा स्टेटलेस होने पर विचार करें!

Answer 5

थ्रेड डंप में आप नीचे पंक्ति संख्या पा सकते हैं।

मुख्य थ्रेड जो अभी चल रहा है के लिए

...

"main" #1 prio=5 os_prio=0 tid=0x0000000002120800 nid=0x13f4 runnable [0x0000000001d9f000] 
    java.lang.Thread.State: **RUNNABLE** 
    at java.io.FileOutputStream.writeBytes(Native Method) 
    at java.io.FileOutputStream.write(FileOutputStream.java:313) 
    at com.rana.samples.**HighCPUUtilization.main(HighCPUUtilization.java:17)**