java - एक 64-बिट ओएस पर 32-बिट जेवीएम का अधिकतम जावा ढेर आकार




jvm (11)

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

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

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


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

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

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

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


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

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

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

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

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

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

संक्षेप में

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


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

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


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

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

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

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


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

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

मुझे अभी तक मेरी नई ढेर सीमा नहीं मिली है, लेकिन मैंने अभी 5 9 00 मीटर के ढेर आकार के साथ एक जेवीएम खोला है। कोई बात नहीं!

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


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


वर्तमान में ओरेकल के स्वामित्व वाले JROCKIT JVM गैर-संगत ढेर उपयोग का समर्थन करता है, इस प्रकार 32 बिट जेवीएम को 3.8 जीबी मेमोरी तक पहुंचने की अनुमति देता है जब JVM 64 बिट विंडोज ओएस पर चल रहा है। (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


सैद्धांतिक 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) [[email protected] 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.


सोलारिस और लिनक्स 64-बिट के तहत कुछ परीक्षण यहां दिए गए हैं

सोलारिस 10 - एसपीएआरसी - 32 जीबी रैम के साथ टी 5220 मशीन (और लगभग 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

बीटीडब्ल्यू: स्पष्ट रूप से जावा स्टार्टअप के साथ बहुत वास्तविक स्मृति आवंटित नहीं करता है। ऐसा लगता है कि प्रति उदाहरण केवल 100 एमबी शुरू हुआ (मैंने 10 शुरू किया)

सोलारिस 10 - x86 - 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

रेडहाट 5.5 - x86 - 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

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

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

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

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


4.1.2 से ढेर आकार :

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

यहां एक बहुत अच्छा जवाब मिला: विंडोज एक्सपी पर जावा अधिकतम मेमोरी





jvm