2011-09-22 7 views
71

क्या कोई कृपया बता सकता है कि जेवीएम विकल्प ReservedCodeCacheSize और InitialCodeCacheSize क्या हैं? विशेष रूप से कब मैं इसे बदलना चाहूंगा? मैं कैसे तय करूं कि सही आकार क्या है?ReservedCodeCacheSize और InitialCodeCacheSize क्या हैं?

यह डॉक्स क्या कहना है:

-XX: ReservedCodeCacheSize = 32m आरक्षित कोड कैश आकार (बाइट्स में) - अधिकतम कोड कैश आकार। [सोलारिस 64-बिट, एमडी 64, और -सेवर x86: 2048 मीटर; 1.5.0_06 में और इससे पहले, सोलारिस 64-बिट और and64:। 1024M]

+2

इस पोस्ट के ओपी ने लिखा:> -XX: ReservedCodeCacheSize = 32m आरक्षित कोड कैश आकार (बाइट्स में) - अधिकतम कोड कैश आकार। [सोलारिस 64-बिट, एमडी 64, और -सर x86: 48 मीटर; 1.5.0_06 और इससे पहले, सोलारिस 64-बिट और और64: 1024 मीटर।] मैं बस यह सही करना चाहता हूं कि 48 मीटर पर उल्लिखित ऊपरी सीमा एक टाइपो होनी चाहिए। यह 2048 मीटर है। –

उत्तर

66

ReservedCodeCacheSize (और InitialCodeCacheSize) जावा हॉटस्पॉट वी एम के (बस-इन-टाइम) संकलक के लिए एक विकल्प है। असल में यह कंपाइलर के कोड कैश के लिए अधिकतम आकार सेट करता है।

कैश जो निम्नलिखित की तरह चेतावनी में परिणाम पूरा हो सकता है,:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. 
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= 
Code Cache [0x000000010958f000, 0x000000010c52f000, 0x000000010c58f000) 
total_blobs=15406 nmethods=14989 adapters=362 free_code_cache=835Kb largest_free_block=449792 

यह बहुत बदतर है जब Java HotSpot(TM) Client VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated द्वारा पीछा किया है।

इस विकल्प को कब सेट करें?

  1. जब हॉटस्पॉट संकलक विफलताओं होने
  2. स्मृति JVM द्वारा की जरूरत (और इसलिए जोखिम JIT कम्पाइलर विफलताओं) को कम करने के

आम तौर पर आप यह राशि बदल नहीं चाहते हैं। मुझे लगता है कि डिफ़ॉल्ट मान काफी संतुलित हैं क्योंकि यह समस्याएं केवल मेरे दुर्लभ अवसरों पर होती हैं (मेरे प्रयोगकर्ता में)।

+1

अच्छा। डिफ़ॉल्ट मान क्या हैं, और यदि हमें "कोडेकैच भरा हुआ" दिखाई देता है तो उन्हें क्या बढ़ाया जाना चाहिए। चेतावनी? – axel22

+2

@ axel22: मान वास्तव में मंच और JVM संस्करण पर निर्भर करते हैं; सूर्य JVM के लिए दस्तावेज़ से मान: 'सुरक्षित कोड कैश आकार (बाइट्स में) - अधिकतम कोड कैश आकार। [सोलारिस 64-बिट, एमडी 64, और -सर x86: 48 मीटर; 1.5.0_06 और इससे पहले, सोलारिस 64-बिट और एमडी 64: 1024 मीटर।] 'ओपनजेडीके मानों को नहीं जानते। एक मध्यम वृद्धि पर्याप्त होनी चाहिए (पहले 1024 मीटर की सेटिंग एक बुराई से परे थी)। , ReservedCodeCacheSize = 512 एम – jeha

12

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

हालांकि, आप अपने चल रहे जावा प्रक्रिया से जुड़ने के लिए jconsole का उपयोग कर सकते हैं, और उसके बाद कोड कैश आकार का पता लगाने के लिए 'मेमोरी' टैब का उपयोग कर सकते हैं। इस वसीयत आपकी मशीन पर

  1. आग अप JConsole
  2. सही प्रक्रिया आईडी का पता लगाएं और इसे करने के लिए JConsole देते हैं (: पूर्णता के लिए, कदम (लिनक्स वी एम पर्यावरण, हालांकि मैं कर रहा हूँ यकीन है कि अन्य वातावरण समान हैं) कर रहे हैं कुछ ही क्षणों 'मेमोरी' टैब
  3. -
  4. नेविगेट लेने के लिए) से 'चार्ट:' 'मेमोरी पूल "कोड कैश"' फिर से चयन
  5. ड्रॉप-डाउन सूची,, इसमें कुछ समय लग सकता है स्क्रीन रीफ्रेश करने के लिए, और फिर आपको कुछ ऐसा दिखना चाहिए: jconsole code cache image

    जैसा कि आप देख सकते हैं, मेरा कोड कैश लगभग 49 एमबी का उपयोग कर रहा है। इस बिंदु पर मुझे अभी भी डिफ़ॉल्ट था जो प्रलेखन (और @ जेहा) कहता है 48 एमबी है। सेटिंग बढ़ाने के लिए निश्चित रूप से मेरे लिए एक महान प्रेरणा!

    बेन।


    1024 एमबी डिफ़ॉल्ट रूप से शायद यह अति था, लेकिन 48 एमबी डिफ़ॉल्ट रूप से यह underdoing किया जा रहा है ...

+0

सुझाव अच्छा है .... मैं -J-XX के साथ कोशिश कर रहा हूँ ध्यान देने योग्य सुधार और इसके बजाय netbeans युक्तियाँ बना दिया। मैं बस इसे हटा दिया समाप्त हो गया। जावा 7/जावा 8 आकार अंतर का उल्लेख करने के लिए – MarcoZen

+0

Netbeans 512 एम के साथ शुरू नहीं होता 256M – MarcoZen

+0

के साथ किया था और लगभग 2 दिनों के लिए परीक्षण के बाद मैं कह सकता हूँ कि सेटिंग किसी भी दिखाई नहीं दिया/किसी भी: – MarcoZen

11

JVM कोड को संकलित करता है, यह कोड कैश में विधानसभा भाषा के निर्देश का सेट रखती है। कोड कैश का एक निश्चित आकार होता है, और एक बार यह भरने के बाद, JVM कोई अतिरिक्त कोड संकलित करने में सक्षम नहीं है।

कोड कैश का अधिकतम आकार -XX के माध्यम से सेट किया गया है: ReservedCodeCacheSize = N ध्वज (जहां एन विशेष संकलक के लिए अभी डिफ़ॉल्ट है)। कोड कैश JVM में अधिकांश मेमोरी की तरह प्रबंधित है: प्रारंभिक आकार ( -XX: InitialCodeCacheSize = N) है। कोड कैश आकार का आवंटन प्रारंभिक आकार से शुरू होता है और कैश भरने के साथ बढ़ता है। कोड कैश का प्रारंभिक आकार चिप आर्किटेक्चर और उपयोग में कंपाइलर के आधार पर भिन्न होता है। का आकार बदलना पृष्ठभूमि में होता है और वास्तव में प्रदर्शन को प्रभावित नहीं करता है, इसलिए ReservedCodeCacheSize आकार (यानी, अधिकतम कोड कैश आकार सेट करना) को सेट करना है जो आम तौर पर आवश्यक है।

डिफ़ॉल्ट रूप से 64-बिट सर्वर के लिए, जावा 7 आकार 48 एमबी है (टायर संकलन के साथ 96 एमबी)। 64 बिट सर्वर के लिए जावा 8 में मेमोरी आकार 240 एमबी है।

- पिनाकी

+2

+1। मुझे संदेह है क्योंकि यह जावा 8 में डिफॉल्ट संकलन डिफ़ॉल्ट रूप से चालू है। – jdv

+0

आप सही हैं, टायर संकलन 1.7.40 के बाद स्थिर हो गया था इससे पहले कि उनके पास कुछ समस्याएं हों। टियर संकलन आसानी से पूरे कोड कैश को इसकी डिफ़ॉल्ट कॉन्फ़िगरेशन में उपयोग कर सकता है, इसलिए उन्होंने इसे Java8 पर सुरक्षित स्तर तक बढ़ा दिया। –

1

दरअसल इंजीनियरिंग टीम और चुनौतियों से एक अच्छा शिक्षण अनुभव वे सामना करना पड़ा जब JDK के लिए 8.

http://engineering.indeedblog.com/blog/2016/09/job-search-web-app-java-8-migration/

निष्कर्ष पलायन: JDK 8 अधिक कोड कैश की जरूरत है हान JDK 7

जेआरई 8 के लिए डिफ़ॉल्ट कोडेकैच आकार लगभग 250 एमबी है, जो जेआरई 7 के लिए 48 एमबी डिफ़ॉल्ट से पांच गुना बड़ा है। हमारा अनुभव यह है कि जेआरई 8 को अतिरिक्त कोडेकैच की आवश्यकता है। हमने जेआरई 8 तक लगभग दस सेवाएं स्विच की हैं, और उनमें से सभी पहले की तुलना में चार गुना अधिक कोडेकैच का उपयोग करते हैं।

0
https://blogs.oracle.com/poonam/entry/why_do_i_get_message से

:

निम्नलिखित + CodeCache फ्लशिंग के संबंध में jdk7u4 में दो ज्ञात समस्याओं कर रहे हैं:

  1. संकलक CodeCache अधिभोग के बाद भी पुन: प्रारंभ नहीं हो सकता है लगभग आधा करने के लिए नीचे चला जाता है आपातकालीन फ्लशिंग के बाद।
  2. आपातकालीन फ्लशिंग संकलन धागे द्वारा उच्च CPU उपयोग का कारण बन सकती है जिससे समग्र प्रदर्शन में गिरावट आती है।

यह प्रदर्शन समस्या, और फिर से सक्षम नहीं होने वाले कंपाइलर की समस्या को जेडीके 8 में संबोधित किया गया है। JDK7u4 + में इन्हें हल करने के लिए, हम संकलित कोड कोड पैचप्रिंट से बड़े मान पर सेट करके ReservedCodeCacheSize विकल्प का उपयोग करके कोड कैश आकार बढ़ा सकते हैं ताकि कोडकैच कभी पूर्ण न हो जाए। इसका एक और समाधान कोडकैच फ्लशिंग को -XX: -UseCodeCacheFlushing JVM विकल्प का उपयोग करके अक्षम करना है।

उपर्युक्त मुद्दों को जेडीके 8 और उसके अपडेट में तय किया गया है।

ताकि जानकारी जेडीके 6 (कोड फ़्लशिंग अक्षम होने) और 7 पर चल रहे सिस्टम के लिए उल्लेखनीय हो सकती है।

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