java - 64-बिट जेवीएम 300 जीबी मेमोरी तक सीमित है?




memory-management jvm (4)

मैं क्लस्टर कंप्यूटिंग पर्यावरण (आईबीएम एलएसएफ रनिंग सेंटोस रिलीज 6.2 फ़ाइनल) पर जावा एप्लिकेशन चलाने का प्रयास कर रहा हूं जो मुझे 1TB रैम स्पेस प्रदान कर सकता है।

मैं 300 जीबी अधिकतम मेमोरी (एक्सएमएक्स) के साथ एक जेवीएम बना सकता हूं, हालांकि मुझे उससे अधिक की आवश्यकता है (अगर अनुरोध किया गया है तो मैं विवरण प्रदान कर सकता हूं)।

हालांकि, एक्सएमएक्स विकल्प का उपयोग कर 300 जीबी से अधिक अधिकतम मेमोरी के साथ एक जेवीएम बनाना असंभव प्रतीत होता है। अधिक विशिष्ट होने के लिए, मुझे क्लासिक त्रुटि संदेश मिलता है:

वीएम की शुरुआत के दौरान त्रुटि हुई।

वस्तु ढेर के लिए पर्याप्त जगह आरक्षित नहीं कर सका।

मेरे (64-बिट) जेवीएम का विवरण नीचे दिया गया है:

ओपनजेडीके रनटाइम एनवायरनमेंट (आईसीएसटीए 6610.6) (रेल-1.43.1.10.6.el6_2-x86_64)

ओपनजेडीके 64-बिट सर्वर वीएम (20.0-बी 11, मिश्रित मोड का निर्माण)

मैंने जावा 7 64-बिट जेवीएम के साथ भी कोशिश की है लेकिन मुझे बिल्कुल वही समस्या है।

इसके अलावा, मैंने HelloWorld.jar चलाने के लिए एक JVM बनाने का प्रयास किया है, लेकिन यदि आप -Xmx300G से अधिक पूछते हैं तो अभी भी JVM निर्माण विफल रहता है, इसलिए मुझे नहीं लगता कि इसका विशिष्ट एप्लिकेशन के साथ कुछ लेना देना है।

क्या किसी को कोई विचार है कि मैं अधिकतम मेमोरी के 300 जी से अधिक के साथ एक JVM क्यों नहीं बना सकता?

क्या कोई समाधान / समाधान का सुझाव दे सकता है?


Ulimit -a को JVM प्रक्रिया के उपयोगकर्ता के रूप में चलाएं और सत्यापित करें कि आपका कर्नेल आपके अधिकतम मेमोरी आकार को सीमित नहीं कर रहा है। आपको /etc/security/limit.conf को संपादित करने की आवश्यकता हो सकती है


मैं कुछ संभावित स्पष्टीकरणों के बारे में सोच सकता हूं:

  • आपके सिस्टम पर अन्य एप्लिकेशन इतनी मेमोरी का उपयोग कर रहे हैं कि अभी 300 जीबी उपलब्ध नहीं है।

  • प्रति-प्रक्रिया मेमोरी आकार पर संसाधन सीमा हो सकती है। आप ulimit का उपयोग कर यह जांच सकते हैं। (ध्यान दें कि इस बग के अनुसार, आपको त्रुटि संदेश मिलेगा यदि प्रति-प्रक्रिया संसाधन सीमा ढेर क्षेत्रों को आवंटित करने वाले JVM को रोकती है।)

  • यह भी संभव है कि यह एक "अधिक प्रतिबद्ध" मुद्दा है; उदाहरण के लिए यदि आपका एप्लिकेशन वर्चुअल में चल रहा है और पूरी तरह से सिस्टम मांग को पूरा नहीं कर सकता है क्योंकि अन्य वर्चुअल से बहुत अधिक प्रतिस्पर्धा है।

सुझाए गए कुछ अन्य विचार हैं (आईएमओ) की संभावना नहीं है:

  • जेआरई स्विच करना कोई फर्क नहीं पड़ता है। मैंने विशिष्ट 64 बिट JVMs में मनमाने ढंग से स्मृति सीमाओं को कभी नहीं सुना या देखा है।

  • पर्याप्त संगत स्मृति न होने की वजह से यह संभावना नहीं है। निश्चित रूप से संगत भौतिक स्मृति की आवश्यकता नहीं है। स्वैप डिवाइस पर एकमात्र संभावना हो सकती है, लेकिन मुझे याद नहीं है कि ठेठ लिनक्स ओएस के लिए एक मुद्दा है।

क्या कोई समाधान / समाधान का सुझाव दे सकता है?

  • ulimit जांच करें।

  • एक छोटा सी प्रोग्राम लिखें जो बहुत सारी मेमोरी को malloc करने का प्रयास करता है और देखता है कि यह विफल होने से पहले कितना आवंटित कर सकता है।

  • मदद के लिए सिस्टम (या हाइपरवाइजर) व्यवस्थापक से पूछें।


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


(संपादित, स्वैप स्पेस पर जोड़ा गया अनुभाग देखें)

श्मामैक्स और शमल

चूंकि आप CentOS का उपयोग कर रहे हैं, इसलिए आप ओरेकल डीबी को कॉन्फ़िगर करने के लिए यहां वर्णित SHMMAX और SHMALL कर्नेल सेटिंग के बारे में एक समान समस्या में भाग ले सकते हैं। उसी लिंक के तहत सही SHMALL सेटिंग प्राप्त करने और सेट करने के लिए एक उदाहरण गणना है।

संगत स्मृति

कुछ उपयोगकर्ताओं ने पहले से ही सूचित किया है कि पर्याप्त संगत स्मृति उपलब्ध नहीं है, अन्य ने कहा है कि यह अप्रासंगिक है।

मुझे यकीन नहीं है कि CentOS पर JVM स्मृति की एक संगत ब्लॉक की आवश्यकता है या नहीं। एसएएस के मुताबिक , खंडित स्मृति आपके जेवीएम को बड़े अधिकतम Xms साथ स्टार्टअप करने या Xms मेमोरी सेटिंग शुरू करने से Xms , लेकिन इंटरनेट पर अन्य दावों का कहना है कि इससे कोई फर्क नहीं पड़ता। मैंने अपने 48 जीबी विंडोज वर्कस्टेशन पर उस सबूत को प्रमाणित या अप्रसन्न करने की कोशिश की, लेकिन 40 जीबी की शुरुआती और अधिकतम सेटिंग के साथ जेवीएम शुरू करने में कामयाब रहा। मुझे पूरा यकीन है कि उस आकार का कोई भी संगत ब्लॉक उपलब्ध नहीं था, लेकिन विभिन्न ओएस पर जेवीएम अलग-अलग व्यवहार कर सकता है, क्योंकि स्मृति प्रबंधन प्रति ओएस अलग हो सकता है (यानी, विंडोज आमतौर पर व्यक्तिगत प्रक्रियाओं के लिए भौतिक पते छुपाता है)।

सबसे बड़ा संगत स्मृति ब्लॉक ढूँढना

सबसे बड़ा संगत मेमोरी ब्लॉक उपलब्ध /proc/meminfo लिए /proc/meminfo का उपयोग करें, VmAllocChunk अंतर्गत मान देखें। यहां सभी मूल्यों की एक गाइड और स्पष्टीकरण दिया गया है। यदि आप जो मान देखते हैं वह VmAllocChunk से VmAllocChunk , तो VmAllocChunk के मान के नीचे सही मूल्य का VmAllocChunk

हालांकि, आमतौर पर यह संख्या भौतिक रूप से उपलब्ध स्मृति से अधिक है (क्योंकि यह वर्चुअल मेमोरी मान उपलब्ध है), यह आपको झूठी सकारात्मक दे सकती है। यह वह मान है जिसे आप आरक्षित कर सकते हैं, लेकिन एक बार जब आप इसका उपयोग करना शुरू कर देते हैं, तो उसे स्वैपिंग की आवश्यकता हो सकती है। इसलिए आपको MemFree और Inactive मानों को भी देखना चाहिए। इसके विपरीत, आप पूरी सूची को भी देख सकते हैं और देख सकते हैं कि 300 जीबी से अधिक मूल्य क्या नहीं हैं।

अन्य ट्यूनिंग विकल्प जिन्हें आप 64 बिट जेवीएम के लिए देख सकते हैं

मुझे यकीन नहीं है कि आप 300 जीबी पर मेमोरी सीमा मुद्दे क्यों मारते हैं। एक पल के लिए मैंने सोचा कि आपने अधिकतम पृष्ठों को मारा होगा। 78,643,200 के डिफ़ॉल्ट के साथ, 78,643,200 पेज देता है। कुछ प्रसिद्ध जादुई संख्या की तरह दिखता नहीं है। यदि, उदाहरण के लिए, 2^24 अधिकतम है, तो 16,777,216 पृष्ठ, या 64 जीबी आपके सैद्धांतिक आवंटित अधिकतम होना चाहिए।

हालांकि, तर्क के लिए मान लीजिए कि आपको बड़े पृष्ठों की आवश्यकता है (जो, जैसा कि यह निकलता है, बड़े मेमोरी जावा अनुप्रयोगों के प्रदर्शन के लिए बेहतर है), आपको -XX:+UseLargePages पर इस मैनपेज से परामर्श लेना चाहिए, जो बताता है कि कैसे उपयोग -XX:+UseLargePages और kernel.shmmax सेट kernel.shmmax (वहां फिर से है), vm.nr_hugepages और vm.huge_tlb_shm_group (सुनिश्चित नहीं है कि उत्तरार्द्ध आवश्यक है)।

अपने सिस्टम को तनाव दें

दूसरों ने पहले से ही यह सुझाव दिया है। यह पता लगाने के लिए कि समस्या JVM के साथ है और ओएस के साथ नहीं, आपको इसे स्ट्रेसस्टेस्ट करना चाहिए। एक उपकरण Stresslinux आप उपयोग कर सकते हैं वह Stresslinuxइस ट्यूटोरियल में , आपको कुछ विकल्प मिलते हैं जिनका आप उपयोग कर सकते हैं। आपके लिए विशेष रुचि निम्न आदेश है:

stress --vm 2 --vm-bytes 300G --timeout 30s --verbose

यदि वह आदेश विफल रहता है, या आपके सिस्टम को लॉक करता है, तो आप जानते हैं कि ओएस उस स्मृति की मात्रा को सीमित कर रहा है। यदि यह सफल होता है, तो हमें JVM को ट्विक करने का प्रयास करना चाहिए ताकि यह उपलब्ध स्मृति का उपयोग कर सके।

अप्रैल 6 संपादित करें: स्वैप स्पेस की जांच करें

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

इसलिए: वर्तमान में उपलब्ध स्वैप स्पेस को cat /proc/swaps # free साथ जांचें और, यदि यह 300GB से छोटा है, तो अपने सिस्टम के लिए स्वैप स्पेस बढ़ाने के लिए इस CentOS मैनपेज पर निर्देशों का पालन करें।

नोट 1: हम बग्रेपोर्ट # 4719001 से कटौती कर सकते हैं कि उपलब्ध स्वैप स्पेस का एक संगत ब्लॉक एक आवश्यकता नहीं है। लेकिन यदि आप अनिश्चित हैं, तो सभी स्वैप स्पेस को हटा दें और इसे फिर से बनाएं , जिसे किसी भी विखंडन को हटा देना चाहिए।

नोट 2: मैंने 0 0MB स्वैप स्पेस की रिपोर्टिंग और जेवीएम चलाने में सक्षम होने जैसी कई पोस्ट देखी हैं। शायद यह इस तथ्य के कारण है कि JVM स्वैप स्पेस को बढ़ाता है। अभी भी यह पता लगाने के लिए स्वैप स्पेस को बढ़ाने की कोशिश करने के लिए चोट नहीं पहुंची है कि यह आपकी समस्या को हल करता है या नहीं।

समयपूर्व निष्कर्ष

मुझे एहसास है कि उपर्युक्त में से कोई भी आपके प्रश्न के बाहर का जवाब नहीं है। मुझे उम्मीद है कि यह आपको कुछ पॉइंटर्स देता है हालांकि आप अपने जेवीएम को काम करने के लिए क्या प्रयास कर सकते हैं। यदि आप वर्तमान में उपयोग कर रहे JVM की सीमा के रूप में सामने आते हैं, तो आप अन्य JVM की कोशिश भी कर सकते हैं, लेकिन जो मैंने अभी तक पढ़ा है, उससे 64 बिट जेवीएम के लिए कोई सीमा लागू नहीं की जानी चाहिए।

आपको जेवीएम के प्रारंभिकरण पर सही त्रुटि मिलती है, मुझे विश्वास है कि समस्या JVM के साथ नहीं है, लेकिन ओएस 300 जीबी मेमोरी के आरक्षण का पालन करने में सक्षम नहीं है।

मेरे अपने परीक्षणों से पता चला है कि जेवीएम सभी वर्चुअल मेमोरी तक पहुंच सकता है, और उपलब्ध भौतिक मेमोरी की मात्रा परवाह नहीं करता है। वर्चुअल मेमोरी भौतिक मेमोरी से कम है, तो यह अजीब होगा, लेकिन VmAllocChunk सेटिंग आपको उस दिशा में संकेत देनी चाहिए (यह आमतौर पर बहुत बड़ी होती है)।







cluster-computing