2012-11-24 15 views
5

सोम पृष्ठभूमि जानकारी;लिनक्स सिस्टम/कर्नेल सीपीयू का उपयोग कर जावा जीसी

सर्वर;

130 जीबी राम के साथ नया एसएलएस 12 सर्वर एक बड़े डेटाबेस (150 जी + डेटा) के लिए MySQL चलाने का इरादा रखता है।

सर्वर कुछ जावा एप्लिकेशन भी होस्ट करेगा।

जावा संस्करण (Oracle से डिफ़ॉल्ट) - जावा (टीएम) एसई रनटाइम वातावरण (निर्माण 1.7.0-b147) - जावा हॉटस्पॉट (टीएम) 64-बिट सर्वर वी एम (निर्माण 21.0-B17, मिश्रित मोड)

हम निम्नलिखित मुद्दे में ठोकर खा चुके हैं;

कुछ स्पेशल जावा अनुप्रयोगों को चलाने से कर्ने/सिस्टम सीपीयू शिखर समय के पेरीओड के लिए एप्लिकेशन को धीमा कर/बंद कर देता है। मैंने जावा एप्लिकेशन बनाकर इसे पुन: उत्पन्न किया है जो समय के साथ मेमोरी खाता है और कुछ सीपीयू का उपयोग करता है।

जांच मंदी के दौरान इंटरप्यू की एक बड़ी संख्या दिखाती है (10000-25000)।

प्रत्येक मंदी के बाद जावा ने कुछ और स्मृति प्राप्त की है। एक निश्चित स्मृति के साथ शुरू करने के लिए जावा सेट करना भी समस्या को कम करने लगता है (सेटिंग -Xmx और -Xms एक ही मान पर)। वर्बोज़िंग कचरा संग्रह यह भी इंगित करता है कि जीसी लात मार रहा है और ट्रिगर हो सकता है।

जीसी और स्मृति आवंटन किसी कारण से बहुत महंगा है, और हमें यकीन नहीं है कि यहां से कहां देखना है। जीसी से विस्तृत: एक कम अंत linux सर्वर पर

[GC^C 1024064K->259230K(3925376K), 87,3591890 secs] 

एक ही कार्यक्रम (रवि से चल SLES, जावा 1.6.0_11) जीसी चल रहा है; मंदी के दौरान

[GC 1092288K->253266K(3959488K), 3.0125460 secs]  

टॉप:

top - 11:23:33 up 87 days, 19:55, 5 users, load average: 14.27, 4.50, 10.17 
Tasks: 250 total, 39 running, 211 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.0%us, 71.8%sy, 0.0%ni, 28.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 129033M total, 128576M used,  457M free,  1388M buffers 
Swap: 32765M total,  13M used, 32752M free, 113732M cached 

मंदी (3. पंक्ति से) के दौरान vmstat;

procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------ 
r b swpd free buff cache si so bi bo in cs us sy id wa st 
0 0 13552 1714328 1422268 116462260 0 0 10  9 0 0 0 0 100 0 0 
1 0 13552 1241780 1422268 116462292 0 0  0  0 240 353 1 0 99 0 0 
1 0 13552 695616 1422268 116462292 0 0  0 17 419 431 3 0 97 0 0 
55 0 13552 486384 1422268 116462292 0 0  0  2 20228 458 1 57 43 0 0 
75 0 13552 476172 1422268 116462300 0 0  0  8 12782 684 0 70 30 0 0 
65 0 13552 470304 1422268 116462304 0 0  0  0 13108 792 0 72 28 0 0 

क्यों जीसी तो एक उच्च अंत सर्वर एक कम अंत सर्वर बनाम पर महंगा है? कोई विचार जहां सुराग देखने के लिए?

अद्यतन - आह्वान पैरामीटर 2012-11-26 आह्वान पैरामीटर;

java -Xmx4g -Xms4g -verbose:gc -server -cp "./dest/" UseMemoryMain 

[GC^C 1024064K->259230K(3925376K), 87,3591890 secs] 

देते में बदला गया;

java -Xmx4g -Xms4g -XX:+UseParallelGC -verbose:gc -cp "./dest/" UseMemoryMain 

[GC 1048640K->265430K(4019584K), 0,0902660 secs] 

देते में बदला गया;

java -Xmx4g -Xms4g -XX:+UseConcMarkSweepGC -verbose:gc -cp "./dest/" UseMemoryMain 

देते

[GC 1092288K->272230K(3959488K), 0,1791320 secs] 

क्या असली हास्यास्पद है का पुनर्प्रसारण आज कह जो जीसी विधि का उपयोग करने के बिना इस देता है;

java -Xmx4g -Xms4g -verbose:gc -server -cp "./dest/" UseMemoryMain 

[GC 1024064K->259238K(3925376K), 0,0839190 secs] 

जावा किसी भी तरह जी सी चूक के लिए रणनीति बदल गया है दे ...

+2

बस समानांतर 1 जीसी का उपयोग करने के लिए आवेदन को मजबूर करना अंतर बना दिया; -XX: + UseParallelGC [जीसी 1048640K-> 265430K (4019584K), 0,0902660 सेकंड] – ZiggyF2B

उत्तर

4

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

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

-XX: + UseConcMarkSweepGC

एक बड़ा अंतर कर देगा।

यह ध्यान देने योग्य है कि आपके द्वारा वर्णित जेवीएम का उपयोग करके, बड़े ढेर का उपयोग करके (10GB से अधिक कहें) हमेशा कुछ ट्यूनिंग की आवश्यकता होगी। आपके पास जीसी लॉग लो और देखें कि जब आप जीसी विकल्पों के साथ खेलते हैं तो व्यवहार कैसे बदलता है। मैं विभिन्न संग्राहक रणनीतियों (जैसे सीएमएस, या जी 1) की कोशिश करने और ईडन स्पेस (जैसे एक्सएमएन) की कॉन्फ़िगरेशन के साथ खेलने की सलाह दूंगा।

अंतिम, लेकिन कम से कम नहीं, आप जांच सकते हैं कि एप्लिकेशन प्रोफाइलर का उपयोग कर स्मृति के साथ क्या करता है। शायद कोड में सुधार किया जा सकता है और इस प्रकार बहुत सारे जीसी से बचा जा सकता है।

+0

धन्यवाद, मैंने लॉन्च पैरा के साथ अपडेट किया है। जब मैं आज जीसी पैरामीटर के बिना नमूना आवेदन दोबारा शुरू करता हूं तो जेवीएम ने रणनीति बदल दी है और जीसी डिफ़ॉल्ट रूप से "तेज़" है। – ZiggyF2B

संबंधित मुद्दे