उत्पादन में थ्रेड डंप लेना

Question

मैं थ्रेड डंप लेने के दृष्टिकोण के बीच मतभेदों का विश्लेषण कर रहा हूं। नीचे उनमें से जोड़ी मैं एक JMX सेम जो एक घोषित सेम आपरेशन क्लिक करने पर() Runtime.exec के माध्यम से चलाता है jstack परिभाषित

1. पर शोध कर रहा हूँ रहे हैं।

2. डेमॉन थ्रेड निष्पादित "प्रबंधनFactory.getThreadMXBean()। डंपअल्ट थ्रेड (सत्य, सत्य)" एक पूर्वनिर्धारित अंतराल के बाद बार-बार।

दोनों के बीच तुलना करना धागा डंप आउटपुट, मैं दृष्टिकोण 2

1. थ्रेड डंप दृष्टिकोण 2 के साथ लॉग इन के साथ नीचे नुकसान देख TDA तरह
2. खुला स्रोत धागा डंप विश्लेषक द्वारा पार्स नहीं किया जा सकता है आउटपुट में मूल थ्रेड आईडी शामिल नहीं है जो उच्च सीपीयू मुद्दों का विश्लेषण करने में उपयोगी हो सकती है (दाएं?)
3. और भी?

मैं

1. पर सुझाव/आदानों प्राप्त करने की सराहना करेंगे वहाँ रहे हैं उत्पादन कोड में Runtime.exec() के माध्यम से jstack को क्रियान्वित करने के किसी भी नुकसान? विभिन्न ऑपरेटिंग सिस्टम पर कोई संगतता मुद्दे - विंडोज़, लिनक्स?

2. थ्रेड डंप लेने के लिए कोई अन्य दृष्टिकोण?

धन्यवाद।

संपादित करें -

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

Answer 1

आप बॉक्स जहां प्रक्रिया चल रही है पर उपयोगकर्ता के रूप में चल

jstack {pid} > stack-trace.log 

उपयोग कर सकते हैं।

यदि आप इसे कई बार चलाते हैं तो आप diff का उपयोग कर सकते हैं यह देखने के लिए कि कौन से थ्रेड अधिक आसानी से सक्रिय हैं।

---

स्टैक निशान का विश्लेषण करने के लिए मैं एक समर्पित धागे में समय-समय पर नमूना का उपयोग करता हूं।

Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces(); 

इस जानकारी का उपयोग करके आप थ्रेड की आईडी प्राप्त कर सकते हैं, राज्य चला सकते हैं और स्टैक निशान की तुलना कर सकते हैं।

Answer 2

यदि यह एक * निक्स मैं kill -3 <PID> कोशिश करता हूं, लेकिन फिर आपको प्रक्रिया आईडी पता होना चाहिए और शायद आपके पास कंसोल तक पहुंच नहीं है?

Answer 3

मैं सुझाव देता हूं कि यदि आप ऐसा env है तो स्टेजिंग वातावरण पर सभी ढेर विश्लेषण करें, फिर किसी भी उत्पादन पर आपके आवश्यक एप्लिकेशन सर्वर ट्यूनिंग को प्रतिबिंबित करें। यदि आपको अपने एप्लिकेशन के मेमोरी उपयोग के विश्लेषण के लिए डंप की आवश्यकता है, तो शायद आपको इसे बेहतर विश्लेषण के लिए प्रोफाइलिंग पर विचार करना चाहिए।

हीप डंप आमतौर पर OutOfMemoryExceptions के परिणामस्वरूप मेमोरी लीक और खराब मेमोरी प्रबंधन के परिणामस्वरूप उत्पन्न होते हैं।

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

Answer 4

तस्वीर 8 में जावा के साथ, जेसीएमडी पसंदीदा दृष्टिकोण है।

jcmd <PID> Thread.print 

बाद Oracle documentation से स्निपेट है:

JDK 8 की रिहाई की शुरुआत की जावा मिशन नियंत्रण, जावा उड़ान रिकॉर्डर, और JVM और Java अनुप्रयोगों के साथ समस्याओं के निदान के लिए jcmd उपयोगिता। उन्नत डायग्नोस्टिक्स और कम प्रदर्शन ओवरहेड के लिए पिछले जेस्टैक उपयोगिता के बजाय नवीनतम उपयोगिता, जेसीएमडी का उपयोग करने का सुझाव दिया गया है।

हालांकि, आवेदन के साथ इसे शिपिंग करना लाइसेंसिंग प्रभाव हो सकता है जो मुझे यकीन नहीं है।