64-बिट OS पर 32-बिट JVM का अधिकतम जावा हीप आकार

Question

सवाल 32-बिट OS पर अधिकतम ढेर के आकार के बारे में नहीं है, यह देखते हुए कि 32-बिट OS में अधिकतम 4GB की मेमोरी योग्य आकार है, और यह कि JVM का अधिकतम हीप आकार इस बात पर निर्भर करता है कि कितनी सन्निहित मुक्त मेमोरी आरक्षित की जा सकती है।

मैं 64-बिट ओएस में चलने वाले 32-बिट जेवीएम के लिए अधिकतम (सैद्धांतिक और व्यावहारिक रूप से प्राप्त करने योग्य) आकार जानने में अधिक रुचि रखता हूं। मूल रूप से, मैं एसओ पर संबंधित प्रश्न में आंकड़ों के समान उत्तर देख रहा हूं ।

क्यों 64-बिट वाले के बजाय 32-बिट जेवीएम का उपयोग किया जाता है, इसका कारण तकनीकी नहीं है, बल्कि प्रशासनिक / नौकरशाही है - उत्पादन वातावरण में 64-बिट जेवीएम स्थापित करने में शायद बहुत देर हो चुकी है।

Answer 1

32-बिट JVM जो कि मेमोरी का एक बड़ा हिस्सा है और कच्चे पॉइंटर्स का उपयोग करने की उम्मीद करते हैं, 4 जीबी से अधिक का उपयोग नहीं कर सकते हैं (क्योंकि यह 32 बिट सीमा है जो पॉइंटर्स पर भी लागू होती है)। इसमें सन शामिल है और - मुझे पूरा यकीन है - आईबीएम कार्यान्वयन भी। मुझे नहीं पता कि उदाहरण के लिए JRockit या दूसरों के पास अपने 32-बिट कार्यान्वयन के साथ एक बड़ा मेमोरी विकल्प है।

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

---

2014-05-15 संपादित करें: Oracle FAQ:

32-बिट जेवीएम के लिए अधिकतम सैद्धांतिक हीप सीमा 4 जी है। उपलब्ध अतिरिक्त स्वैप, कर्नेल पता स्थान उपयोग, स्मृति विखंडन और VM ओवरहेड जैसे विभिन्न अतिरिक्त बाधाओं के कारण, व्यवहार में सीमा बहुत कम हो सकती है। अधिकांश आधुनिक 32-बिट विंडोज सिस्टम पर अधिकतम ढेर का आकार 1.4G से 1.6G तक होगा। 32-बिट सोलारिस गुठली पर पता स्थान 2G तक सीमित है। 32-बिट वीएम चलाने वाले 64-बिट ऑपरेटिंग सिस्टम पर, अधिकतम हीप आकार अधिक हो सकता है, जो कई सोलारिस सिस्टम पर 4 जी के करीब पहुंचता है।

( http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit )

Comments

यहां कोई काम का दबाव नहीं। मुझे पता है कि 64-बिट जेवीएम को पहले स्थान पर स्थापित किया जाना चाहिए था। लेकिन मुझे यह सोचने में मदद मिली कि एक 32-बिट JVM अपने निपटान में अधिक संसाधनों वाले वातावरण में कैसे काम करेगा।

— विनीत रेनॉल्ड्स

क्या यह हस्ताक्षर के 2GB के आसपास नहीं है? या कि सिर्फ सूर्य JVM है?

— सेबेस्टियन गैन्सलैंड्ट

पॉइंटर्स पर हस्ताक्षर नहीं किए गए हैं - यह नकारात्मक मेमोरी स्थानों की बात करने का कोई मतलब नहीं है।

— थोरबजोरन रावन एंडरसन

नहीं, यह हस्ताक्षर के कारण 2GB नहीं है। हालाँकि, 4GB पता स्थान का हिस्सा OS कर्नेल के लिए आरक्षित है। विंडोज के सामान्य उपभोक्ता संस्करणों पर, सीमा 2GB है। विंडोज के लिनक्स और सर्वर संस्करणों पर (32-बिट) सीमा 3 जीबी प्रति प्रक्रिया है।

— जेस्पर

@ जेस्पर मैं सोच रहा था कि क्या 64-बिट ऑपरेटिंग सिस्टम पर चलने वाला 32-बिट जेवीएम में पूर्ण 4 जीबी एड्रेस स्पेस उपलब्ध हो सकता है?

— थोर्बोजर्न रावन एंडरसन

Answer 2

आप जावा रनटाइम पूछ सकते हैं:

public class MaxMemory {
    public static void main(String[] args) {
        Runtime rt = Runtime.getRuntime();
        long totalMem = rt.totalMemory();
        long maxMem = rt.maxMemory();
        long freeMem = rt.freeMemory();
        double megs = 1048576.0;

        System.out.println ("Total Memory: " + totalMem + " (" + (totalMem/megs) + " MiB)");
        System.out.println ("Max Memory:   " + maxMem + " (" + (maxMem/megs) + " MiB)");
        System.out.println ("Free Memory:  " + freeMem + " (" + (freeMem/megs) + " MiB)");
    }
}

यह डिफ़ॉल्ट हीप आवंटन के आधार पर "मैक्स मेमोरी" की रिपोर्ट करेगा। इसलिए आपको अभी भी -Xmx( हॉटस्पॉट पर ) खेलना होगा । मैंने पाया कि विंडोज 7 एंटरप्राइज 64-बिट पर चल रहा है, मेरा 32-बिट है हॉटस्पॉट JVM 15772BB तक आवंटित कर सकता है:

[C: स्क्रैच]> java -Xmx1600M MaxMemory
VM के प्रारंभ के दौरान त्रुटि आई
ऑब्जेक्ट हीप के लिए पर्याप्त स्थान आरक्षित नहीं किया जा सका
जावा वर्चुअल मशीन नहीं बन सकी।
[C: स्क्रैच]> java -Xmx1590M MaxMemory
कुल मेमोरी: 2031616 (1.9375 MiB)
अधिकतम मेमोरी: 1654456320 (1577.8125 MiB)
मुफ्त मेमोरी: 1840872 (1.75559234619 MiB)
[सी: खरोंच]>

जबकि एक ही OS पर 64-बिट JVM के साथ , निश्चित रूप से यह बहुत अधिक है (लगभग 3TiB)

[C: स्क्रैच]> java -Xmx3560G MaxMemory
VM के प्रारंभ के दौरान त्रुटि आई
ऑब्जेक्ट हीप के लिए पर्याप्त स्थान आरक्षित नहीं किया जा सका
[C: स्क्रैच]> java -Xmx3550G MaxMemory
कुल मेमोरी: 94240768 (89.875 MiB)
अधिकतम मेमोरी: 3388252028928 (3184151.84297 MiB)
मुफ्त मेमोरी: 93747752 (89.4048233032 MiB)
[सी: खरोंच]>

जैसा कि दूसरों ने पहले ही उल्लेख किया है, यह ओएस पर निर्भर करता है।

• 32-बिट विंडोज के लिए: यह <2GB होगा ( विंडोज इंटर्नल बुक उपयोगकर्ता प्रक्रियाओं के लिए 2GB कहता है)
• 32-बिट बीएसडी / लिनक्स के लिए: <3 जीबी (डेविल बुक से)
• 32-बिट MacOS X के लिए: <4GB ( Mac OS X इंटर्नल बुक से)
• 32-बिट सोलारिस के बारे में निश्चित नहीं है, उपरोक्त कोड की कोशिश करें और हमें बताएं।

64-बिट होस्ट ओएस के लिए, यदि जेवीएम 32-बिट है, तो यह अभी भी निर्भर करेगा, सबसे अधिक संभावना है जैसा कि ऊपर दिखाया गया है।

- अपडेट 20110905 : मैं सिर्फ कुछ अन्य टिप्पणियों / विवरणों को इंगित करना चाहता था:

• जिस हार्डवेयर पर मैंने इसे चलाया वह 6GB की वास्तविक रैम के साथ 64-बिट था। ऑपरेटिंग सिस्टम विंडोज 7 एंटरप्राइज था, 64-बिट
• उस की वास्तविक राशि को Runtime.MaxMemoryआवंटित किया जा सकता है जो ऑपरेटिंग सिस्टम के कार्य सेट पर भी निर्भर करता है । मैंने एक बार इसे चलाया, जबकि मुझे भी VirtualBox चल रहा था और मैंने पाया कि मैं हॉटस्पॉट JVM को सफलतापूर्वक शुरू नहीं कर सका -Xmx1590Mऔर इसे छोटा करना पड़ा। इसका मतलब यह भी है कि आपको उस समय काम करने वाले सेट के आकार के आधार पर 1590M से अधिक मिल सकता है (हालांकि मैं अभी भी इसे बनाए रखता हूं क्योंकि विंडोज के डिजाइन के कारण 32-बिट के लिए 2GiB के तहत होगा)

Comments

मुझे यह पसंद है कि आपने वास्तव में किए गए अनुमानों के बजाय परीक्षण किया है।

— जिम हर्न

@djangofan सही है। कार्यक्रम को 1,048,576 (1024 * 1024, या 2 ^ 20) से विभाजित किया जाना चाहिए, न कि 104,856। लेकिन, यह सिर्फ एक प्रदर्शन की बात है। जैसा कि आप कमांड से देख सकते हैं, उन्होंने केवल 1,590 MiB में अधिकतम हीप आकार सेट करने का प्रयास किया।

— जिम हर्न

बहुत जवाब शांत (मैं कहना चाहते हैं जवाब), एक कोड उदाहरण के साथ, और विवरण सभी OSes को कवर।

— TGP1994

मेरी पिछली टिप्पणी के बाद: jdocs (विंडोज़ के लिए कम से कम) निर्दिष्ट करें कि -Xmx और -Xms पैरामीटर्स को एक मान दिया जाना चाहिए जो कि 1024 से अधिक है ... मुझे यकीन नहीं है कि अगर 1590 है, तो मुझे अजीब लगता है परिणामों की उम्मीद की जानी चाहिए।

— TGP1994

अच्छी तरह से देखा गया TGP1994। मुझे लगता है कि, क्योंकि मैंने 'M' और 'G' गुणकों को निर्दिष्ट किया है, तो आकार (बाइट्स में) वैसे भी 1024 बाइट्स से अधिक का काम करेगा। उदाहरण के लिए 1590M को 1590 * (1024 * 1024) = 1667235840 बाइट्स (1628160KiB - यहां तक ​​कि 1024 के एक से अधिक) के लिए पार्स किया जाएगा।

— माइक

Answer 3

आप निर्दिष्ट नहीं करते हैं कि कौन सा ओएस।

विंडोज के तहत (मेरे आवेदन के लिए - एक लंबे समय तक चलने वाला जोखिम प्रबंधन अनुप्रयोग) हमने देखा कि हम विंडोज 32 बिट पर 1280 एमबी से आगे नहीं जा सकते। मुझे संदेह है कि 64 बिट के तहत 32 बिट जेवीएम चलाने से कोई फर्क नहीं पड़ेगा।

हमने ऐप को लिनक्स में पोर्ट किया और हम 64 बिट हार्डवेयर पर 32 बिट जेवीएम चला रहे हैं और 2.2 जीबी वीएम को आसानी से चला रहे हैं।

आपके लिए सबसे बड़ी समस्या जीसी है जो आप स्मृति के लिए उपयोग कर रहे हैं उसके आधार पर है।

Comments

मैं सोलारिस 10 के लिए सीमा जानना पसंद करूंगा, लेकिन फिर यह केवल मेरी समस्या के लिए है। अन्य ओएस के लिए भी जानना चाहेंगे, बरसात के दिन के लिए :)

— विनीत रेनॉल्ड्स

सोलारिस के बारे में निश्चित नहीं है। मुझे उम्मीद है कि वीएम का आकार काफी बड़ा होगा, सोलारिस पर जावा का मेरा अनुभव कुछ साल पहले था। और सन हार्डवेयर पर एक सन ओएस पर एक सन वीएम होने के नाते - चीजें बहुत अच्छी तरह से काम करती थीं। मुझे यह भी विश्वास है कि लिनक्स / विंडोज की तुलना में सोलारिस के तहत कम जीसी मुद्दे थे।

— फ़ॉर्च्युनर

यह कौन सी विंडोज थी। मेरा मानना ​​है कि विंडोज 32-बिट के सर्वर संस्करण बड़ी मात्रा में मेमोरी को बेहतर तरीके से संभाल सकते हैं।

— थोरबजोरन रेव एंडरसन

आह, आखिरकार ओएस का उल्लेख ;-) आपके पास 64-बिट कर्नेल स्थापित है?

— थोरबजोरन रेव एंडरसन

यह Win2k सर्वर था। Win2k3 के लिए एक चाल (चीजें धीरे चलती हैं ..) बहुत देर हो चुकी थी और हमने इसके बजाय लिनक्स पर स्विच किया।

— Fortyrunner

Answer 4

से 4.1.2 ढेर आकार :

"32-बिट प्रक्रिया मॉडल के लिए, प्रक्रिया का अधिकतम आभासी पता आकार आमतौर पर 4 जीबी है, हालांकि कुछ ऑपरेटिंग सिस्टम इसे 2 जीबी या 3 जीबी तक सीमित करते हैं। अधिकतम हीप आकार आमतौर पर 2 जीबी सीमा के लिए -Xmx3800m (1600 मीटर) है। ), हालांकि वास्तविक सीमा आवेदन पर निर्भर है। 64-बिट प्रक्रिया मॉडल के लिए, अधिकतम अनिवार्य रूप से असीमित है। "

यहाँ एक बहुत अच्छा जवाब मिला: Windows XP पर जावा अधिकतम मेमोरी ।

Answer 5

हमें हाल ही में इसके साथ कुछ अनुभव हुआ था। हमने हाल ही में सोलारिस (x86-64 संस्करण 5.10) से लिनक्स (रेडहैट x86-64) में पोर्ट किया है और महसूस किया है कि हमारे पास सोलारिस की तुलना में लिनक्स पर 32 बिट जेवीएम प्रक्रिया के लिए कम मेमोरी उपलब्ध है।

सोलारिस के लिए यह लगभग 4GB (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit) पर आता है।

हमने अपना ऐप -Xms2560m -Xmx2560m -XX के साथ चलाया: MaxPermSize = 512m -XX: PermSize = 512m पिछले कुछ वर्षों से Solaris पर कोई समस्या नहीं है। इसे लिनक्स में स्थानांतरित करने की कोशिश की और हमारे पास स्टार्ट अप पर मेमोरी त्रुटियों के यादृच्छिक रूप से मुद्दे थे। हम केवल इसे लगातार स्टार्ट -Xms2300 -Xmx2300 पर प्राप्त कर सकते हैं । तब हमें समर्थन से सलाह दी गई थी।

लिनक्स पर एक 32 बिट प्रक्रिया में 3 जीबी (3072 एमबी) का अधिकतम पता योग्य स्थान होता है जबकि सोलारिस पर यह पूर्ण 4 जीबी (4096 एमबी) है।

Comments

समर्थन द्वारा दिए गए उत्तर का कारण एक प्रक्रिया के लिए कितना पता योग्य स्मृति उपलब्ध है। यह लिनक्स कर्नेल और हार्डवेयर पर भी निर्भर करता है। सैद्धांतिक रूप से, पता योग्य मेमोरी 2 ^ 32 = 4G तक सीमित है (और जावा हीप का आकार इससे कम होगा)। लेकिन, यह (सैद्धांतिक रूप से) ह्यूजेम और पीएई का उपयोग करके बढ़ाया जा सकता है; मैंने यह प्रयास नहीं किया है।

— विनीत रेनॉल्ड्स

Answer 6

64-बिट OS पर 32-बिट JVM की सीमाएं बिल्कुल वैसी ही होंगी जैसी कि 32-बिट OS पर 32-बिट JVM की सीमाएं। आखिरकार, 32-बिट JVM चल रहा होगा। 32-बिट वर्चुअल मशीन में (वर्चुअलाइजेशन अर्थ में) तो यह पता नहीं चलेगा कि यह 64-बिट OS / मशीन पर चल रहा है।

64-बिट OS बनाम 32-बिट OS पर 32-बिट JVM चलाने का एक फायदा यह है कि आपके पास अधिक भौतिक मेमोरी हो सकती है, और इसलिए कम बार स्वैपिंग / पेजिंग का सामना करेंगे। यह लाभ वास्तव में पूरी तरह से महसूस किया जाता है जब आपके पास कई प्रक्रियाएं होती हैं।

Comments

हार्डवेयर और यह कैसे वर्चुअलाइज़ किया जाता है, इसके आधार पर थोड़ा अंतर हो सकता है। 4GB पता योग्य स्थान में से कुछ का उपयोग आम तौर पर मेमोरी मैप किए गए उपकरणों के लिए किया जाता है। वर्चुअलाइजेशन परत मशीन पर भौतिक उपकरणों के समान स्मृति पदचिह्न हो सकती है या नहीं भी हो सकती है।

— एरिक जे।

काफी नहीं। 64-बिट मशीन में JVM के लिए अधिक जगह है क्योंकि 32-बिट एड्रेस स्पेस को ऑपरेटिंग सिस्टम या हार्डवेयर इंटरफेस के साथ साझा नहीं करना पड़ता है।

— थोरबजोरन रावन एंडरसन

यह सच है, लेकिन इसका मतलब यह है कि आपके 32-बिट-वर्चुअल-मशीन में 32-बिट-वास्तविक मशीन (या तो बदतर, या बेहतर) की तुलना में थोड़ा अलग ओवरहेड हो सकता है। किसी भी तरह से, आप 32-बिट-मशीन (वास्तविक या आभासी) पर जेवीएम चला रहे हैं और इसलिए आप मानक 32-बिट बाधाओं के अधीन होंगे। यानी: 4 जीबी की पूर्ण छत।

— लॉरेंस गोंसाल्वेस

Thorbjørn: ऑपरेटिंग सिस्टम और हार्डवेयर इंटरफेस को अभी भी 32-बिट VM में मैप करने की आवश्यकता है। ओवरहार्ट की सटीक मात्रा अलग हो सकती है, लेकिन यह अभी भी वहां होगी। यदि आप इसे 64-बिट OS के नीचे वर्चुअलाइज कर सकते हैं, तो 32-बिट OS के तहत इसे वर्चुअलाइज करने से आपको क्या रोकना है? यह वर्चुअल मेमोरी है जिसके बारे में हम बात कर रहे हैं।

— लॉरेंस गोंसाल्वेस

एलजी: मैं आपके मूल उत्तर से असहमत हूं। ओएस कर्नेल और किसी भी एचडब्ल्यू और बस एड्रेस स्पेस को मैप करता है, जो बहुत सारे एड्रेस स्पेस को चबाएगा, और जब यह यूजर प्रोग्राम में मैप नहीं किया जाता है, तो यह ओएस द्वारा खुद को सेट करने के बाद "बाईं ओर" राशि को कम करता है। यह 4GB 32-बिट स्पेस की काफी मात्रा है। परंपरागत रूप से, इसका मतलब है कि 4GB का लगभग 25% -75% उपयोगकर्ता प्रक्रियाओं के लिए उपलब्ध नहीं है। :-) कर्नेल हैकर

— DigitalRoss

Answer 7

क्यों 64-बिट वाले के बजाय 32-बिट जेवीएम का उपयोग किया जाता है, इसका कारण तकनीकी नहीं है, बल्कि प्रशासनिक / नौकरशाही है ...

जब मैं बीईए के लिए काम कर रहा था, तो हमने पाया कि औसत आवेदन वास्तव में 64-बिट जेवीएम में धीमी गति से चलता है , तब यह 32-बिट जेवीएम में चलने पर होता है। कुछ मामलों में, प्रदर्शन हिट 25% धीमा था। इसलिए, जब तक कि आपके एप्लिकेशन को वास्तव में सभी अतिरिक्त मेमोरी की आवश्यकता नहीं होती है, तब तक आप अधिक 32-बिट सर्वर स्थापित करने से बेहतर थे।

जैसा कि मुझे याद है, 64-बिट का उपयोग करने के लिए तीन सबसे आम तकनीकी औचित्य है कि BEA पेशेवर सेवा कर्मियों में भाग लिया था:

1. आवेदन कई बड़े पैमाने पर छवियों में हेरफेर कर रहा था,
2. आवेदन बड़े पैमाने पर क्रंचिंग कर रहा था,
3. एप्लिकेशन में एक मेमोरी लीक था, ग्राहक एक सरकारी अनुबंध पर प्रमुख था, और वे मेमोरी लीक को ट्रैक करने का समय और खर्च नहीं लेना चाहते थे। (बड़े पैमाने पर मेमोरी हीप का उपयोग करने से MTBF में वृद्धि होगी और प्रधानमंत्री को अभी भी भुगतान मिलेगा)

।

Comments

यह अच्छा है कि आप पहले हाथ की सलाह प्रदान करें, BEA के पूर्व कार्यकर्ता :)

— emecas

Answer 8

वर्तमान में ऑरेकल के स्वामित्व वाली JROCKIT JVM गैर-सन्निहित हीप उपयोग का समर्थन करती है, इस प्रकार 32 बिट JVM को तब एक्सेस करने की अनुमति मिलती है जब 3.8 बिट मेमोरी OS पर चलती है। (32 जीबी ओएस पर चलने पर 2.8 जीबी)।

http://blogs.oracle.com/jrockit/entry/how_to_get_almost_3_gb_heap_on_windows

JVM को मुफ्त में (पंजीकरण आवश्यक) डाउनलोड किया जा सकता है

http://www.oracle.com/technetwork/middleware/jrockit/downloads/index.html

Answer 9

यहाँ Solaris और Linux 64-बिट के तहत कुछ परीक्षण किया गया है

सोलारिस 10 - स्पार्क - 32 जीबी रैम के साथ T5220 मशीन (और लगभग 9 जीबी मुफ्त)

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3750m MaxMemory
Error occurred during initialization of VM
Could not reserve space for ObjectStartArray
$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3700m MaxMemory
Total Memory: 518520832 (494.5 MiB)
Max Memory:   3451912192 (3292.0 MiB)
Free Memory:  515815488 (491.91998291015625 MiB)
Current PID is: 28274
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Server VM (build 20.5-b03, mixed mode)

$ which java
/usr/bin/java
$ file /usr/bin/java
/usr/bin/java: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available

$ prstat -p 28274
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
28274 user1     670M   32M sleep   59    0   0:00:00 0.0% java/35

BTW: जाहिरा तौर पर जावा स्टार्टअप के साथ बहुत वास्तविक स्मृति आवंटित नहीं करता है। ऐसा लग रहा था कि केवल 100 एमबी प्रति मिनट की शुरुआत हुई (मैंने 10 की शुरुआत की)

सोलारिस 10 - x86 - VMWare VM 8 जीबी रैम (लगभग 3 जीबी मुफ्त *) के साथ

3 जीबी फ्री रैम वास्तव में सच नहीं है। राम का एक बड़ा हिस्सा है जो जेडएफएस कैश का उपयोग करता है, लेकिन मेरे पास यह जांचने के लिए रूट एक्सेस नहीं है कि वास्तव में कितना सही है

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3650m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3600m MaxMemory
Total Memory: 516423680 (492.5 MiB)
Max Memory:   3355443200 (3200.0 MiB)
Free Memory:  513718336 (489.91998291015625 MiB)
Current PID is: 26841
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

$ which java
/usr/bin/java

$ file /usr/bin/java
/usr/bin/java:  ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, no debugging information available

$ prstat -p 26841
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
26841 user1     665M   22M sleep   59    0   0:00:00 0.0% java/12

RedHat 5.5 - x86 - VMWare VM 4 जीबी रैम के साथ (लगभग 3.8 जीबी का उपयोग किया गया - बफ़र्स में 200 एमबी और कैश में 3.1 जीबी, इसलिए लगभग 3 जीबी मुफ्त)

$ alias java='$HOME/jre/jre1.6.0_34/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838768 (488.1274871826172 MiB)
Current PID is: 21879
Waiting for user to press Enter to finish ...

$ java -version
java version "1.6.0_34"
Java(TM) SE Runtime Environment (build 1.6.0_34-b04)
Java HotSpot(TM) Server VM (build 20.9-b04, mixed mode)

$ file $HOME/jre/jre1.6.0_34/bin/java
/home/user1/jre/jre1.6.0_34/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

$ cat /proc/21879/status | grep ^Vm
VmPeak:  3882796 kB
VmSize:  3882796 kB
VmLck:         0 kB
VmHWM:     12520 kB
VmRSS:     12520 kB
VmData:  3867424 kB
VmStk:        88 kB
VmExe:        40 kB
VmLib:     14804 kB
VmPTE:        96 kB

जेआरई 7 का उपयोग करके एक ही मशीन

$ alias java='$HOME/jre/jre1.7.0_21/bin/java'

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3500m MaxMemory
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

$ java -XX:PermSize=128M -XX:MaxPermSize=256M -Xms512m -Xmx3450m MaxMemory
Total Memory: 514523136 (490.6875 MiB)
Max Memory:   3215654912 (3066.6875 MiB)
Free Memory:  511838672 (488.1273956298828 MiB)
Current PID is: 23026
Waiting for user to press Enter to finish ...

$ java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

$ file $HOME/jre/jre1.7.0_21/bin/java
/home/user1/jre/jre1.7.0_21/bin/java: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped

$ cat /proc/23026/status | grep ^Vm
VmPeak:  4040288 kB
VmSize:  4040288 kB
VmLck:         0 kB
VmHWM:     13468 kB
VmRSS:     13468 kB
VmData:  4024800 kB
VmStk:        88 kB
VmExe:         4 kB
VmLib:     10044 kB
VmPTE:       112 kB

Comments

जिन प्लेटफार्मों को हम गायब कर रहे हैं, उनके लिए यहां कुछ उपयोगी परीक्षा परिणाम हैं। फ़ाइल और मेमोरी डंप के उपयोग के साथ अच्छा काम भी।

— जूल

Answer 10

बहुत बेहतर होना चाहिए

32-बिट JVM के लिए 64-बिट होस्ट पर चल रहा है, मुझे लगता है कि ढेर के लिए जो बचा है वह वही होगा जो जेवीएम के बाद अनफिटेड वर्चुअल स्पेस उपलब्ध है, यह खुद का DLL है, और किसी भी OS 32-बिट संगतता सामान को लोड किया गया है। एक जंगली अनुमान के रूप में मुझे लगता है कि 3 जीबी संभव होना चाहिए, लेकिन यह कितना बेहतर है यह इस बात पर निर्भर करता है कि आप 32-बिट-होस्ट-लैंड में कितना अच्छा कर रहे हैं।

इसके अलावा, भले ही आप एक विशाल 3 जीबी हीप बना सकते हैं, आप नहीं करना चाहते हैं, क्योंकि इससे जीसी पॉजेस मुश्किल हो जाएगा। कुछ लोग सिर्फ एक विशालकाय के बजाय अतिरिक्त मेमोरी का उपयोग करने के लिए अधिक जेवीएम चलाते हैं। मुझे लगता है कि वे विशालकाय ढेर के साथ बेहतर काम करने के लिए जेवीएम के अधिकार को हासिल कर रहे हैं।

यह जानना थोड़ा कठिन है कि आप कितना बेहतर कर सकते हैं। मुझे लगता है कि आपकी 32-बिट स्थिति को आसानी से प्रयोग द्वारा निर्धारित किया जा सकता है। यह निश्चित रूप से कठिन भविष्यवाणी करना मुश्किल है, क्योंकि इसमें बहुत सी चीजें कारक हैं, विशेष रूप से क्योंकि 32-बिट मेजबानों पर उपलब्ध आभासी स्थान बल्कि विवश है। ढेर को सन्निहित आभासी स्मृति में मौजूद रहने की आवश्यकता है, इसलिए पते के स्थान का विखंडन ओएस कर्नेल द्वारा पता स्थान का dll और आंतरिक उपयोग संभव आवंटन की सीमा निर्धारित करेगा।

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

लोड हो रहा है DLL कार्यान्वयन और JVM की रिहाई पर निर्भर करता है। लोड हो रहा है OS कर्नेल बहुत सी चीजों पर निर्भर करता है, रिलीज़, HW, अंतिम रिबूट के बाद से अब तक कितनी चीजें मैप की गई हैं, कौन जानता है ...

संक्षेप में

मुझे यकीन है कि आपको 32-बिट-भूमि में 1-2 जीबी मिलता है, और 64-बिट में लगभग 3, इसलिए लगभग 2x में सुधार होगा ।

Comments

दुर्भाग्य से, मेरे पास अपने निपटान में 64-बिट वातावरण नहीं है जहां मैं एक्सएमएक्स ध्वज के साथ प्रयोग कर सकता हूं। जो मुझे पता है कि उसमें एक विनम्र (32 * n) जीबी रैम की मात्रा उपलब्ध है, लेकिन सीमा से बाहर है। यही कारण है कि मैं जानना चाहता था कि 32-बिट JVM उन सभी बाधाओं के बिना कैसे काम करेगा, जो आम तौर पर 32-बिट दुनिया में होती है।

— विनीत रेनॉल्ड्स

खैर, अच्छा सवाल है। मुझे यकीन है कि मूल उत्तर "यह बेहतर काम करेगा" है।

— डिजिटलरॉस

ठीक है, मैंने आपके वास्तविक प्रश्न पर थोड़ा और ध्यान केंद्रित करने के लिए अपना उत्तर संपादित किया है। :-)

— डिजिटलरॉस

≅ 3GB 64-बिट में सही के बारे में लगता है। Thorbjørn ने पहले ही संकेत दिया था कि यह सैद्धांतिक रूप से 4GB से अधिक क्यों नहीं हो सकता है। बहुत बुरा मैं दो जवाब स्वीकार नहीं कर सकता।

— विनीत रेनॉल्ड्स

यदि आपके पास एक बड़ा बॉक्स है, तो आप उदाहरण के वर्चुअलबॉक्स में 64-बिट सोलारिस के साथ प्रयोग कर सकते हैं (जिसमें सबसे अच्छा सोलारिस अतिथि समर्थन है)।

— थोरबजोरन रावन एंडरसन

Answer 11

सोलारिस 2.5 के बाद से सोलारिस की सीमा लगभग 3.5 जीबी हो गई है। (लगभग 10 साल पहले)

Comments

मैं उस के साथ प्रयोग करने जा रहा हूं, ओरेकल सोलारिस एक्सप्रेस 11 का उपयोग कर रहा हूं।

— djangofan

@Peter लॉरी उह .. सोलारिस 2.5 लगभग 20 साल पहले था अगर आप मई 1996 की रिलीज़ की तारीख पर विचार करते हैं .... बेशक यह 2005 के आसपास

— ईओएल

Answer 12

मुझे जेवीएम के साथ वही समस्याएं आ रही थीं जो एंड्रॉइड ब्लॉक संपादक के लिए ऐप आविष्कारक उपयोग करता है। यह ढेर को 925 मीटर अधिकतम पर सेट करता है। यह पर्याप्त नहीं है, लेकिन मैं अपनी मशीन पर विभिन्न यादृच्छिक कारकों के आधार पर इसे लगभग 1200 मीटर से अधिक सेट नहीं कर सका।

मैंने नाइटली को डाउनलोड किया, फ़ायरफ़ॉक्स से बीटा 64-बिट ब्राउज़र, और जेएवीए 7 64 बिट संस्करण भी।

मुझे अभी तक अपनी नई ढेर सीमा नहीं मिली है, लेकिन मैंने सिर्फ 5900 मीटर के आकार के साथ एक जेवीएम खोला है । कोई दिक्कत नहीं है!

मैं 24gb RAM वाली मशीन पर विन 7 64 बिट अल्टीमेट रन कर रहा हूं।

Answer 13

मैंने 32 बिट लिनक्स मशीन पर 2200M तक हीप साइज़ सेट करने की कोशिश की है और JVM ने ठीक काम किया है। जब मैंने इसे 2300M पर सेट किया तो JVM शुरू नहीं हुआ।

Comments

मैंने सोचा कि मैं विंडोज विस्टा 64 बिट पर जोड़ूंगा, 32 बिट जेवीएम अधिकतम 1582 मीटर (-एक्सएमएल मूल्य) पर। यदि मैं 1583m निर्दिष्ट करता हूं तो यह शिकायत करेगा। मुझे नहीं पता कि यह मूल्य मशीन से मशीन में बदलता है या नहीं। जिस कंप्यूटर पर मैंने यह परीक्षण किया, उसमें वास्तव में 4 जीबी भौतिक रैम था।

— संतोष तिवारी

@ संतोश तिवारी यह मशीन से मशीन में बदलता है, लेकिन यहाँ क्यों है

— यूजीन

Answer 14

यह भारी ट्यूनिंग है, लेकिन आप एक 3 जीबी ढेर प्राप्त कर सकते हैं।

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://forall.ru-board.com/egor23/online/FAQ/Virtual_Memory/Limits_Virtual_Memory.html

Answer 15

हॉटस्पॉट 32-बिट जेवीएम के लिए यहां एक और बिंदु: - देशी ढेर क्षमता = 4 गिग - जावा हीप - पर्मगेन;

यह 32-बिट JVM के लिए विशेष रूप से मुश्किल हो सकता है क्योंकि जावा हीप और देशी हीप एक दौड़ में हैं। आपका जावा हीप जितना छोटा होगा, देशी हीप उतना ही छोटा होगा। एक 32-बिट वीएम जैसे .2.5 जीबी + के लिए एक बड़े हीप को सेटअप करने का प्रयास करने से आपके आवेदन (नों) के पदचिह्न, थ्रेड्स की संख्या आदि के आधार पर देशी आउटऑफमोरीइर्रर का खतरा बढ़ जाता है।

Answer 16

सीमा भी इस तथ्य से आती है कि एक 32 bitवीएम के लिए, heapखुद को पता शून्य पर शुरू करना होगा यदि आप उन सभी को चाहते हैं 4GB।

इसके बारे में सोचें, अगर आप किसी चीज़ को संदर्भित करना चाहते हैं:

0000....0001

यानी: एक संदर्भ जिसमें यह विशेष बिट्स प्रतिनिधित्व है, इसका मतलब है कि आप ढेर से पहली मेमोरी को एक्सेस करने की कोशिश कर रहे हैं। संभव होने के लिए, पता शून्य पर शुरू करना होगा। लेकिन ऐसा कभी नहीं होता है, यह शून्य से कुछ ऑफसेट पर शुरू होता है:

    | ....               .... {heap_start .... heap_end} ... |
 --> (this can't be referenced) <--

क्योंकि हीप कभी भी एड्रेस शून्य से शुरू नहीं होता है OS, ऐसे कुछ बिट्स होते हैं जिनका उपयोग कभी 32बिट्स संदर्भ से नहीं किया जाता है , और ऐसे हीप को संदर्भित किया जा सकता है जो कम है।

Answer 17

सैद्धांतिक 4 जीबी, लेकिन व्यवहार में (आईबीएम जेवीएम के लिए):

विन 2k8 64, आईबीएम वेब्स्फेयर एप्लीकेशन सर्वर 8.5.5 32 बिट

C:\IBM\WebSphere\AppServer\bin>managesdk.bat -listAvailable -verbose CWSDK1003I: Доступные SDK: CWSDK1005I: Имя SDK: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=windows - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 - com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/win /x86_32/ CWSDK1001I: Задача managesdk выполнена успешно. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2036 MaxMemory JVMJ9GC017E -Xmx слишком мала, должна быть не меньше 1 M байт JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось инициализи ровать Could not create the Java virtual machine. C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2047M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 2146435072 (2047.0 MiB) Free Memory: 3064536 (2.9225692749023438 MiB) C:\IBM\WebSphere\AppServer\java\bin>java -Xmx2048M MaxMemory JVMJ9VM015W Ошибка инициализации для библиотеки j9gc26(2): Не удалось создать эк земпляр кучи; запрошено 2G Could not create the Java virtual machine.

आरएचईएल 6.4 64, आईबीएम वेब्स्फेयर एप्लीकेशन सर्वर 8.5.5 32 बिट

[bin]./java -Xmx3791M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3975151616 (3791.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [root@nagios1p bin]# ./java -Xmx3793M MaxMemory Total Memory: 4194304 (4.0 MiB) Max Memory: 3977248768 (3793.0 MiB) Free Memory: 3232992 (3.083221435546875 MiB) [bin]# /opt/IBM/WebSphere/AppServer/bin/managesdk.sh -listAvailable -verbose CWSDK1003I: Available SDKs : CWSDK1005I: SDK name: 1.6_32 - com.ibm.websphere.sdk.version.1.6_32=1.6 - com.ibm.websphere.sdk.bits.1.6_32=32 - com.ibm.websphere.sdk.location.1.6_32=${WAS_INSTALL_ROOT}/java - com.ibm.websphere.sdk.platform.1.6_32=linux - com.ibm.websphere.sdk.architecture.1.6_32=x86_32 -com.ibm.websphere.sdk.nativeLibPath.1.6_32=${WAS_INSTALL_ROOT}/lib/native/linux/x86_32/ CWSDK1001I: Successfully performed the requested managesdk task.