लिनक्स प्रक्रिया निवासी सेट आकार की तुलना में एक JVM रिपोर्ट अधिक प्रतिबद्ध स्मृति क्यों करती है?

Question

देशी मेमोरी ट्रैकिंग सक्षम के साथ जावा ऐप (YARN में) चलाते समय (-XX:NativeMemoryTracking=detailhttps://docs.oracle.com/javase/8/docs/technotes/guides/vm/nmt-8.html और https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html देखें), मैं देख सकता हूं कि विभिन्न श्रेणियों में JVM कितनी मेमोरी का उपयोग कर रहा है।

JDK 1.8.0_45 शो पर मेरा ऐप:

 
Native Memory Tracking: 

Total: reserved=4023326KB, committed=2762382KB 
-     Java Heap (reserved=1331200KB, committed=1331200KB) 
          (mmap: reserved=1331200KB, committed=1331200KB) 

-      Class (reserved=1108143KB, committed=64559KB) 
          (classes #8621) 
          (malloc=6319KB #17371) 
          (mmap: reserved=1101824KB, committed=58240KB) 

-     Thread (reserved=1190668KB, committed=1190668KB) 
          (thread #1154) 
          (stack: reserved=1185284KB, committed=1185284KB) 
          (malloc=3809KB #5771) 
          (arena=1575KB #2306) 

-      Code (reserved=255744KB, committed=38384KB) 
          (malloc=6144KB #8858) 
          (mmap: reserved=249600KB, committed=32240KB) 

-      GC (reserved=54995KB, committed=54995KB) 
          (malloc=5775KB #217) 
          (mmap: reserved=49220KB, committed=49220KB) 

-     Compiler (reserved=267KB, committed=267KB) 
          (malloc=137KB #333) 
          (arena=131KB #3) 

-     Internal (reserved=65106KB, committed=65106KB) 
          (malloc=65074KB #29652) 
          (mmap: reserved=32KB, committed=32KB) 

-     Symbol (reserved=13622KB, committed=13622KB) 
          (malloc=12016KB #128199) 
          (arena=1606KB #1) 

- Native Memory Tracking (reserved=3361KB, committed=3361KB) 
          (malloc=287KB #3994) 
          (tracking overhead=3075KB) 

-    Arena Chunk (reserved=220KB, committed=220KB) 
          (malloc=220KB) 

यह आवंटित ढेर के 1.3GB और लगभग 1.2GB आवंटित धागा ढेर के (कई धागे का प्रयोग करके) सहित प्रतिबद्ध स्मृति, की 2.7GB को दर्शाता है।

हालांकि, ps ax -o pid,rss | grep <mypid> या top चलाते समय यह केवल 1.6 जीबी RES/rss निवासी स्मृति दिखाता है। जांच की जा रही स्वैप कहते प्रयोग में कोई भी: जब केवल 1.6GB निवासी है

 
free -m 
      total  used  free  shared buffers  cached 
Mem:  129180  99348  29831   0  2689  73024 
-/+ buffers/cache:  23633  105546 
Swap:  15624   0  15624 

क्यों JVM 2.7GB स्मृति संकेत मिलता है के लिए प्रतिबद्ध है? बाकी कहाँ गए थे?

Answer 1

मुझे संदेह है कि स्टेक मेमोरी (जेवीएम ढेर के विपरीत) को निवासी बनने के बिना पूर्व निर्धारित किया जाता है और समय के साथ ही वास्तविक स्टैक उपयोग के उच्च पानी के निशान तक निवासी बन जाता है।

हां, malloc/mmap आलसी है जब तक अन्यथा नहीं बताया जाता है। पृष्ठों को केवल एक्सेस होने के बाद भौतिक स्मृति द्वारा समर्थित किया जाता है।

जीसी हीप मेमोरी प्रभावी रूप से कॉपी करने वाले कलेक्टर द्वारा या पूर्व-शून्य (-XX:+AlwaysPreTouch) द्वारा स्पर्श किया जाता है, इसलिए यह हमेशा निवासी रहेगा। थ्रेड स्टैक्स ओटो इस से प्रभावित नहीं हैं।

आगे की पुष्टि के लिए आप pmap -x <java pid> का उपयोग कर सकते हैं और एनएमटी से वर्चुअल मेमोरी मैप से उत्पादन के साथ विभिन्न पता श्रेणियों के आरएसएस को पार-संदर्भित कर सकते हैं।

---

सुरक्षित स्मृति PROT_NONE के साथ मिमीपैड किया गया है। जिसका अर्थ है कि आभासी पता स्थान श्रेणी में कर्नेल के वीएमए structs में प्रविष्टियां होती हैं और इस प्रकार अन्य mmap/malloc कॉल द्वारा उपयोग नहीं किया जाएगा। लेकिन वे अभी भी पृष्ठ त्रुटियों को SIGSEGV के रूप में प्रक्रिया में अग्रेषित कर देंगे, यानी उन्हें एक्सेस करना एक त्रुटि है।

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

प्रतिबद्ध-लेकिन-समर्थित बैक-बाय-स्टोरेज मेमोरी को मैप किया गया है - उदाहरण के लिए - PROT_READ | PROT_WRITE लेकिन इसे एक्सेस करने से अभी भी पृष्ठ की गलती होती है। लेकिन कर्नेल द्वारा उस पृष्ठ की गलती को चुपचाप इसे वास्तविक स्मृति के साथ समर्थन करके और निष्पादन पर लौटकर चुपचाप संभाला जाता है जैसे कुछ भी नहीं हुआ।
आईई। यह एक कार्यान्वयन विस्तार/अनुकूलन है जिसे प्रक्रिया द्वारा स्वयं नहीं देखा जाएगा।

प्रयुक्त ढेर: स्मृति की मात्रा पिछले जीसी को

प्रतिबद्ध अनुसार लाइव वस्तुओं के कब्जे में: पता पर्वतमाला कि किया गया है

---

अवधारणाओं के टूटने देने के लिए PROT_NONE के अलावा किसी अन्य चीज़ के साथ मैप किया गया।आलसी आवंटन और पेजिंग के कारण उन्हें भौतिक या स्वैप द्वारा समर्थित किया जा सकता है या नहीं।

सुरक्षित: कुल पता श्रेणी जो किसी विशेष मेमोरी पूल के लिए mmap के माध्यम से प्री-मैप किया गया है।
सुरक्षित - प्रतिबद्ध अंतर PROT_NONE मैपिंग, जो की गारंटी है नहीं करने के लिए भौतिक स्मृति का समर्थन प्राप्त किया जा के होते हैं

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

वर्चुअल: सभी वर्चुअल एड्रेस मैपिंग्स का योग। कवर प्रतिबद्ध, आरक्षित मेमोरी पूल लेकिन मैप की गई फाइलें या साझा मेमोरी भी। यह संख्या शायद ही कभी जानकारीपूर्ण है क्योंकि JVM अग्रिम में बहुत बड़ी पता श्रेणियां आरक्षित कर सकता है या बड़ी फ़ाइलों को एमएमएपी कर सकता है।