জাভা হ্যাপের আকারের চেয়ে অনেক বেশি মেমরি ব্যবহার করে (বা আকার সঠিকভাবে ডকার মেমরি সীমা)


118

আমার অ্যাপ্লিকেশনটির জন্য, জাভা প্রক্রিয়া দ্বারা ব্যবহৃত মেমরিটি হিপ আকারের চেয়ে অনেক বেশি।

যে পাত্রে চালিত হয় সেই সিস্টেমে মেমরির সমস্যা হতে শুরু করে কারণ ধারকটি গাদা আকারের চেয়ে অনেক বেশি মেমরি নিয়েছে।

গাদা আকারটি 128 এমবি ( -Xmx128m -Xms128m) তে সেট করা থাকে যখন ধারকটি 1 গিগাবাইট পর্যন্ত মেমরি নেয়। স্বাভাবিক অবস্থায় এটির 500MB দরকার। ডকারের ধারকটির নীচে সীমাবদ্ধতা থাকলে (উদাহরণস্বরূপ mem_limit=mem_limit=400MB) ওএসের মেমরি কিলারের বাইরে প্রক্রিয়াটি মারা যায়।

আপনি কী ব্যাখ্যা করতে পারেন যে জাভা প্রক্রিয়া কেন গাদা চেয়ে অনেক বেশি মেমরি ব্যবহার করছে? ডকার মেমরি সীমাটি কীভাবে সঠিকভাবে আকার করতে হবে? জাভা প্রক্রিয়াটির অফ অফ হিপ মেমরির পদক্ষেপ হ্রাস করার কোনও উপায় আছে কি?


আমি জেভিএম-এ নেটিভ মেমরি ট্র্যাকিংয়ের কমান্ড ব্যবহার করে সমস্যাটি সম্পর্কে কিছু বিশদ সংগ্রহ করি ।

হোস্ট সিস্টেম থেকে, আমি ধারকটির দ্বারা ব্যবহৃত স্মৃতি পেয়েছি।

$ docker stats --no-stream 9afcb62a26c8
CONTAINER ID        NAME                                                                                        CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
9afcb62a26c8        xx-xxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.0acbb46bb6fe3ae1b1c99aff3a6073bb7b7ecf85   0.93%               461MiB / 9.744GiB   4.62%               286MB / 7.92MB      157MB / 2.66GB      57

ধারকটির ভিতরে থেকে, আমি প্রক্রিয়াটির দ্বারা ব্যবহৃত স্মৃতি পেয়েছি।

$ ps -p 71 -o pcpu,rss,size,vsize
%CPU   RSS  SIZE    VSZ
11.2 486040 580860 3814600

$ jcmd 71 VM.native_memory
71:

Native Memory Tracking:

Total: reserved=1631932KB, committed=367400KB
-                 Java Heap (reserved=131072KB, committed=131072KB)
                            (mmap: reserved=131072KB, committed=131072KB) 

-                     Class (reserved=1120142KB, committed=79830KB)
                            (classes #15267)
                            (  instance classes #14230, array classes #1037)
                            (malloc=1934KB #32977) 
                            (mmap: reserved=1118208KB, committed=77896KB) 
                            (  Metadata:   )
                            (    reserved=69632KB, committed=68272KB)
                            (    used=66725KB)
                            (    free=1547KB)
                            (    waste=0KB =0.00%)
                            (  Class space:)
                            (    reserved=1048576KB, committed=9624KB)
                            (    used=8939KB)
                            (    free=685KB)
                            (    waste=0KB =0.00%)

-                    Thread (reserved=24786KB, committed=5294KB)
                            (thread #56)
                            (stack: reserved=24500KB, committed=5008KB)
                            (malloc=198KB #293) 
                            (arena=88KB #110)

-                      Code (reserved=250635KB, committed=45907KB)
                            (malloc=2947KB #13459) 
                            (mmap: reserved=247688KB, committed=42960KB) 

-                        GC (reserved=48091KB, committed=48091KB)
                            (malloc=10439KB #18634) 
                            (mmap: reserved=37652KB, committed=37652KB) 

-                  Compiler (reserved=358KB, committed=358KB)
                            (malloc=249KB #1450) 
                            (arena=109KB #5)

-                  Internal (reserved=1165KB, committed=1165KB)
                            (malloc=1125KB #3363) 
                            (mmap: reserved=40KB, committed=40KB) 

-                     Other (reserved=16696KB, committed=16696KB)
                            (malloc=16696KB #35) 

-                    Symbol (reserved=15277KB, committed=15277KB)
                            (malloc=13543KB #180850) 
                            (arena=1734KB #1)

-    Native Memory Tracking (reserved=4436KB, committed=4436KB)
                            (malloc=378KB #5359) 
                            (tracking overhead=4058KB)

-        Shared class space (reserved=17144KB, committed=17144KB)
                            (mmap: reserved=17144KB, committed=17144KB) 

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

-                   Logging (reserved=4KB, committed=4KB)
                            (malloc=4KB #179) 

-                 Arguments (reserved=19KB, committed=19KB)
                            (malloc=19KB #512) 

-                    Module (reserved=258KB, committed=258KB)
                            (malloc=258KB #2356) 

$ cat /proc/71/smaps | grep Rss | cut -d: -f2 | tr -d " " | cut -f1 -dk | sort -n | awk '{ sum += $1 } END { print sum }'
491080

অ্যাপ্লিকেশনটি হ'ল জেটি / জার্সি / সিডিআই ব্যবহার করে এমন একটি ওয়েব সার্ভার যা 36 মেগাবাইটের মধ্যে একটি ফ্যাটের অভ্যন্তরে বান্ডিল রয়েছে।

ওএস এবং জাভা এর নিম্নলিখিত সংস্করণ ব্যবহার করা হয় (ধারক ভিতরে)। ডকার চিত্রটি ভিত্তিক openjdk:11-jre-slim

$ java -version
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment (build 11+28-Debian-1)
OpenJDK 64-Bit Server VM (build 11+28-Debian-1, mixed mode, sharing)
$ uname -a
Linux service1 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 GNU/Linux

https://gist.github.com/prasanthj/48e7063cac88eb396bc9961fb3149b58


6
গাদা যেখানে অবজেক্টগুলি বরাদ্দ করা হয়, তবে জেভিএমের শেয়ার্ড লাইব্রেরি, ডাইরেক্ট মেমরি বাফারস, থ্রেড স্ট্যাকস, জিইউআই উপাদানগুলি, মেটাস্পেস সহ অনেকগুলি মেমরি অঞ্চল রয়েছে। আপনাকে দেখতে হবে যে জেভিএম কতটা বড় হতে পারে এবং সীমাটি পর্যাপ্ত পরিমাণে বাড়িয়ে তুলতে হবে যা আপনি আর ব্যবহার না করে প্রক্রিয়াটি মারা যাবেন।
পিটার লরি

2
দেখে মনে হচ্ছে জিসি প্রচুর স্মৃতি ব্যবহার করছে। পরিবর্তে আপনি সিএমএস সংগ্রাহক ব্যবহার করে দেখতে পারেন। দেখে মনে হচ্ছে ~ 125 এমবিটি মেটাস্পেস + কোডের জন্য ব্যবহৃত হয়, তবে আপনার কোড বেসটি সঙ্কুচিত না করে, আপনি এটি আরও ছোট করতে সক্ষম হবেন না। প্রতিশ্রুতিবদ্ধ স্থান আপনার সীমাটির কাছাকাছি তাই এটি মারা যাওয়ার অবাক হওয়ার কিছু নেই।
পিটার লরে

আপনি কোথায় / কীভাবে -Xms এবং -Xmx কনফিগারেশন সেট করবেন?
মিক 14


1
আপনি কি অনেকগুলি ফাইল-ক্রিয়াকলাপ চালানোর প্রোগ্রাম করেন (যেমন গিগাবাইট আকারে ফাইল তৈরি করেন)? যদি তা হয় তবে আপনার জানা উচিত যে cgroupsব্যবহৃত মেমরিতে ডিস্ক-ক্যাশে যুক্ত করে - এমনকি এটি কার্নেল দ্বারা পরিচালিত হলেও এটি ব্যবহারকারীর প্রোগ্রামের জন্য অদৃশ্য। (আপনার কথা মনে করুন, আদেশ দিন psএবং docker statsডিস্ক-ক্যাশে গণনা করবেন না))
লরিনকি জিসিগমন্ড

উত্তর:


204

একটি জাভা প্রক্রিয়া দ্বারা ব্যবহৃত ভার্চুয়াল মেমরি কেবল জাভা হ্যাপ ছাড়িয়ে অনেক প্রসারিত। আপনি জানেন, জেভিএম অনেকগুলি সাবসিটিম অন্তর্ভুক্ত করে: আবর্জনা সংগ্রাহক, শ্রেণি লোডিং, জেআইটি সংকলক ইত্যাদি, এবং এই সমস্ত সাবসিস্টিমে কাজ করার জন্য নির্দিষ্ট পরিমাণের র্যামের প্রয়োজন।

জেভিএম র‌্যামের একমাত্র গ্রাহক নয়। নেটিভ লাইব্রেরিগুলি (স্ট্যান্ডার্ড জাভা ক্লাস লাইব্রেরি সহ) নেটিভ মেমরির বরাদ্দ করতে পারে। এবং এটি নেটিভ মেমোরি ট্র্যাকিংয়ের জন্যও দৃশ্যমান হবে না। নিজে নিজে জাভা অ্যাপ্লিকেশন সরাসরি বাইটবফারগুলির মাধ্যমে অফ-হিপ মেমরিটিও ব্যবহার করতে পারে।

সুতরাং একটি জাভা প্রক্রিয়া মেমরি লাগে?

জেভিএম অংশ (বেশিরভাগ নেটিভ মেমরি ট্র্যাকিং দ্বারা দেখানো হয়)

  1. জাভা হিপ

    সবচেয়ে সুস্পষ্ট অংশ। এটি যেখানে জাভা অবজেক্টগুলি বাস করে। গাদা -Xmxস্মৃতি পরিমাণে লাগে ।

  2. আবর্জনা সংগ্রহকারী

    জিসি স্ট্রাকচার এবং অ্যালগরিদমগুলিতে হিপ পরিচালনার জন্য অতিরিক্ত মেমরির প্রয়োজন। এই স্ট্রাকচারগুলি হ'ল মার্ক বিটম্যাপ, মার্ক স্ট্যাক (অবজেক্ট গ্রাফ ট্র্যাভারিংয়ের জন্য), স্মরণীয় সেটস (আন্তঃ অঞ্চল রেফারেন্স রেকর্ডিংয়ের জন্য) এবং অন্যান্য। এর মধ্যে কয়েকটি সরাসরি সুরক্ষিত হয়, উদাহরণস্বরূপ -XX:MarkStackSizeMax, অন্যরা হিপ লেআউটের উপর নির্ভর করে, উদাহরণস্বরূপ বৃহত্তর জি 1 অঞ্চল ( -XX:G1HeapRegionSize), ছোটগুলি স্মরণীয় সেট হয়।

    জিসি অ্যালগরিদমের মধ্যে জিসি মেমরি ওভারহেড পরিবর্তিত হয়। -XX:+UseSerialGCএবং -XX:+UseShenandoahGCসবচেয়ে ছোট ওভারহেড আছে জি 1 বা সিএমএস সহজেই মোট হ্যাপ আকারের প্রায় 10% ব্যবহার করতে পারে।

  3. কোড ক্যাশে

    গতিশীলভাবে উত্পন্ন কোড রয়েছে: জেআইটি-সংকলিত পদ্ধতি, দোভাষী এবং রান-টাইম স্টাবগুলি। এর আকার সীমাবদ্ধ -XX:ReservedCodeCacheSize(ডিফল্টরূপে 240M)। -XX:-TieredCompilationসংকলিত কোড এবং এইভাবে কোড ক্যাশে ব্যবহারের পরিমাণ হ্রাস করতে বন্ধ করুন ।

  4. সংকলনকারী

    জেআইটি সংকলক নিজেই এর কাজটি করার জন্য মেমরির প্রয়োজন। এই বিশিষ্ট সংকলন বন্ধ সুইচিং দ্বারা বা কম্পাইলার থ্রেডের সংখ্যা কমিয়ে আবার হ্রাস করা যেতে পারে: -XX:CICompilerCount

  5. ক্লাস লোড হচ্ছে

    ক্লাসের মেটাডেটা (পদ্ধতি বাইটোকড, প্রতীক, ধ্রুব পুল, টীকাগুলি ইত্যাদি) মেটাস্পেস নামে অফ-হিপ অঞ্চলে সংরক্ষণ করা হয়। আরও ক্লাস লোড করা হয় - আরও মেটাস্পেস ব্যবহার করা হয়। মোট ব্যবহার সীমাবদ্ধ করা যেতে পারে -XX:MaxMetaspaceSize(ডিফল্ট দ্বারা সীমাহীন) এবং -XX:CompressedClassSpaceSize(ডিফল্ট 1 জি)।

  6. প্রতীক টেবিল

    জেভিএমের দুটি প্রধান হ্যাশটেবল: সিম্বল টেবিলের নাম, স্বাক্ষর, শনাক্তকারী ইত্যাদি রয়েছে এবং স্ট্রিং টেবিলটিতে ইন্টার্নযুক্ত স্ট্রিংগুলির উল্লেখ রয়েছে। যদি নেটিভ মেমরি ট্র্যাকিং কোনও স্ট্রিং টেবিলের মাধ্যমে উল্লেখযোগ্য মেমরির ব্যবহার নির্দেশ করে তবে সম্ভবত এটি অ্যাপ্লিকেশনকে অতিরিক্তভাবে কল করবে String.intern

  7. টপিক

    থ্রেড স্ট্যাকগুলিও র‌্যাম নেওয়ার জন্য দায়ী। স্ট্যাক আকার দ্বারা নিয়ন্ত্রিত হয় -Xss। ডিফল্টটি প্রতি থ্রেডে 1 এম হয় তবে ভাগ্যক্রমে জিনিসগুলি এত খারাপ হয় না। ওএস মেমরি পৃষ্ঠাগুলি আলস্যভাবে বরাদ্দ করে, যেমন প্রথম ব্যবহারের জন্য, তাই প্রকৃত মেমরির ব্যবহার অনেক কম হবে (সাধারণত থ্রেড স্ট্যাকের প্রতি 80-200 কেবি)। আরএসএসের কতটা জাভা থ্রেড স্ট্যাকের অন্তর্গত তা অনুমান করার জন্য আমি একটি স্ক্রিপ্ট লিখেছিলাম ।

    অন্যান্য জেভিএম অংশ রয়েছে যা দেশীয় মেমরির বরাদ্দ করে তবে তারা সাধারণত মোট মেমরির ক্ষেত্রে বড় ভূমিকা নেয় না।

সরাসরি বাফার

একটি অ্যাপ্লিকেশন স্পষ্টভাবে কল করে অফ হিপ মেমরির জন্য অনুরোধ করতে পারে ByteBuffer.allocateDirect। ডিফল্ট অফ হিপ সীমা সমান -Xmx, তবে এটি দিয়ে ওভাররাইড করা যায় -XX:MaxDirectMemorySize। ডাইরেক্ট বাইটবফারগুলি Otherএনএমটি আউটপুট (অথবা জেডিকে Internal11 এর আগে) এর বিভাগে অন্তর্ভুক্ত রয়েছে ।

ব্যবহৃত প্রত্যক্ষ মেমরির পরিমাণ জেএমএক্সের মাধ্যমে দৃশ্যমান, যেমন জে কনসোল বা জাভা মিশন নিয়ন্ত্রণে:

বাফারপুল এমবিয়ান

সরাসরি বাইটবফারগুলি ছাড়াও থাকতে পারে MappedByteBuffers- ফাইলগুলি কোনও প্রক্রিয়াটির ভার্চুয়াল মেমোরিতে ম্যাপ করা হয়। এনএমটি সেগুলি ট্র্যাক করে না, তবে ম্যাপডবাইটবফারগুলি শারীরিক স্মৃতিও নিতে পারে। এবং তারা কতটা নিতে পারে তা সীমাবদ্ধ করার কোনও সহজ উপায় নেই। প্রক্রিয়া মেমরি মানচিত্র দেখে আপনি আসল ব্যবহারটি দেখতে পারেন:pmap -x <pid>

Address           Kbytes    RSS    Dirty Mode  Mapping
...
00007f2b3e557000   39592   32956       0 r--s- some-file-17405-Index.db
00007f2b40c01000   39600   33092       0 r--s- some-file-17404-Index.db
                           ^^^^^               ^^^^^^^^^^^^^^^^^^^^^^^^

নেটিভ লাইব্রেরি

লোড হওয়া জেএনআই কোড System.loadLibraryজেভিএম দিক থেকে কোনও নিয়ন্ত্রণ ছাড়াই যতটা অফ হিপ মেমরি চায় তা বরাদ্দ করতে পারে। এটি স্ট্যান্ডার্ড জাভা ক্লাস লাইব্রেরি নিয়েও উদ্বেগ প্রকাশ করে। বিশেষত, অনাবৃত জাভা সংস্থানগুলি দেশীয় মেমরি ফাঁসের উত্স হয়ে উঠতে পারে। সাধারণ উদাহরণগুলি হ'ল ZipInputStreamবা DirectoryStream

জেভিএমটিআই এজেন্টস, বিশেষত, jdwpডিবাগিং এজেন্ট - অতিরিক্ত মেমরির খরচও ঘটায় ।

এই উত্তরটি কীভাবে অ্যাসিঙ্ক-প্রোফাইলার সহ নেটিভ মেমরির বরাদ্দকে প্রোফাইল করবেন তা বর্ণনা করে ।

বরাদ্দ সংক্রান্ত বিষয়

একটি প্রক্রিয়া সাধারণত ওএস ( mmapসিস্টেম কল দ্বারা) অথবা mallocস্ট্যান্ডার্ড লিবিসি বরাদ্দকারী ব্যবহার করে দেশীয় মেমরির জন্য অনুরোধ করে । পরিবর্তে, mallocওএস ব্যবহার করে মেমরির বড় অংশগুলি অনুরোধ করে mmapএবং তারপরে তার নিজস্ব বরাদ্দ অ্যালগরিদম অনুযায়ী এই খণ্ডগুলি পরিচালনা করে। সমস্যাটি হ'ল - এই অ্যালগরিদমটি খণ্ডিত হওয়া এবং অতিরিক্ত ভার্চুয়াল মেমরির ব্যবহার করতে পারে ।

jemalloc, একটি বিকল্প বরাদ্দকারী, প্রায়শই নিয়মিত libc এর চেয়ে বেশি স্মার্ট দেখা যায় malloc, তাই স্যুইচিংয়ের jemallocফলে বিনামূল্যে একটি ছোট পায়ের ছাপ পড়তে পারে।

উপসংহার

জাভা প্রক্রিয়াটির সম্পূর্ণ মেমরির ব্যবহার অনুমান করার কোনও গ্যারান্টিযুক্ত উপায় নেই, কারণ বিবেচনা করার মতো অনেকগুলি কারণ রয়েছে।

Total memory = Heap + Code Cache + Metaspace + Symbol tables +
               Other JVM structures + Thread stacks +
               Direct buffers + Mapped files +
               Native Libraries + Malloc overhead + ...

জেভিএম পতাকা দ্বারা নির্দিষ্ট মেমরি অঞ্চলগুলি (কোড ক্যাশে যেমন) সঙ্কুচিত করা বা সীমাবদ্ধ করা সম্ভব তবে আরও অনেকে জেভিএমের নিয়ন্ত্রণের বাইরে নয়।

ডকার সীমা নির্ধারণের একটি সম্ভাব্য পন্থা হ'ল প্রক্রিয়াটির একটি "স্বাভাবিক" অবস্থায় প্রকৃত মেমরির ব্যবহার দেখা। আছে: সরঞ্জাম ও জাভা মেমরির খরচ সমস্যা তদন্ত জন্য কৌশল আছে দেশীয় মেমরি ট্র্যাকিং , pmap , jemalloc , ASYNC-প্রোফাইলার

হালনাগাদ

এখানে আমার উপস্থাপনাটির একটি রেকর্ডিং জাভা প্রক্রিয়ার মেমরির পদচিহ্ন

এই ভিডিওটিতে আমি জাভা প্রক্রিয়াতে কী কী স্মৃতি গ্রহণ করতে পারে, কীভাবে নির্দিষ্ট মেমরির ক্ষেত্রগুলির আকার নিরীক্ষণ এবং সংযত করতে হয় এবং জাভা অ্যাপ্লিকেশনে নেটিভ মেমরি ফাঁসকে কীভাবে প্রোফাইল দেওয়া যায় সে সম্পর্কে আমি আলোচনা করেছি।


1
ইন্টারন্যাশনাল স্ট্রিংস কি জেডি কে 7 এর পরে গাদা না? ( bugs.java.com/bugdatedia/view_bug.do?bug_id=6962931 ) - সম্ভবত আমি ভুল করছি
জে-কেক 5'18

5
@ জে-কেক স্ট্রিং অবজেক্টগুলি হিপটিতে রয়েছে, তবে হ্যাশ টেবিল (রেফারেন্স এবং হ্যাশ কোড সহ বালতি এবং এন্ট্রি) অফ হিপ মেমোরিতে রয়েছে। আমি বাক্যটি আরও সুনির্দিষ্ট বলে উল্লেখ করেছি। নির্দেশ করার জন্য ধন্যবাদ।
আপানগিন

এটি যোগ করার জন্য, এমনকি আপনি যদি প্রত্যক্ষ-বাইটবফারগুলি ব্যবহার করেন, জেভিএম মেমরির সীমাবদ্ধতা আরোপিত না করে দেশীয় মেমোরিতে অস্থায়ী সরাসরি বাফারগুলি বরাদ্দ করবে। Cf. evanjones.ca/java-bytebuffer-leak.html
সিপিটি। সেনকফাস

16

https://developers.redhat.com/blog/2017/04/04/openjdk-and-containers/ :

আমি যখন -Xmx = 1g নির্দিষ্ট করি তখন কেন আমার জেভিএম 1 জিবি মেমরির চেয়ে বেশি মেমরি ব্যবহার করে?

-Xmx = 1g উল্লেখ করে JVM কে 1gb হিপ বরাদ্দ করতে বলছে। এটি জেভিএমকে তার সম্পূর্ণ মেমরির ব্যবহার 1 জিবিতে সীমাবদ্ধ করতে বলছে না। কার্ডের টেবিল, কোড ক্যাশে এবং অন্যান্য সমস্ত ধরণের হিপ ডেটা স্ট্রাকচার রয়েছে। মোট মেমরির ব্যবহার নির্দিষ্ট করার জন্য আপনি যে প্যারামিটারটি ব্যবহার করেন তা হ'ল-এক্সএক্স: ম্যাক্সআরাম। সাবধান থাকুন যে -XX এর সাথে: ম্যাক্সরাম = 500 মিটার আপনার গাদাটি প্রায় 250 এমবি হবে।

জাভা হোস্ট মেমরির আকার দেখে এবং এটি কোনও ধারক মেমরির সীমাবদ্ধতা সম্পর্কে অবগত নয়। এটি মেমরির চাপ তৈরি করে না, তাই জিসির জন্য ব্যবহৃত মেমরি ছেড়ে দেওয়ার প্রয়োজন নেই। আমি আশা করি XX:MaxRAMআপনাকে মেমরির পদচিহ্ন হ্রাস করতে সহায়তা করবে। অবশেষে, আপনি জিসি কনফিগারেশন বদলাতে পারেন ( -XX:MinHeapFreeRatio, -XX:MaxHeapFreeRatio, ...)


অনেক ধরণের মেমরি মেট্রিক রয়েছে। ডকার মনে করে আরএসএসের মেমরি আকারের প্রতিবেদন করছে, যা রিপোর্ট করা "প্রতিশ্রুতিবদ্ধ" মেমরির চেয়ে আলাদা হতে পারে jcmd(ডকারের পুরানো সংস্করণ আরএসএস + ক্যাশে মেমরির ব্যবহার হিসাবে রিপোর্ট করে)। ভাল আলোচনা এবং লিঙ্ক: ডকারের ধারক মধ্যে চলমান একটি JVM এর জন্য রেসিডেন্ট সেট সাইজ (আরএসএস) এবং জাভা মোট প্রতিশ্রুতিবদ্ধ মেমরি (এনএমটি) এর মধ্যে পার্থক্য

(আরএসএস) মেমরিটি পাত্রে থাকা আরও কিছু ইউটিলিটি - শেল, প্রসেসার ম্যানেজার, দ্বারাও খাওয়া যেতে পারে ... আমরা জানি না যে ধারকটিতে অন্য কী চলছে এবং আপনি কীভাবে ধারকটিতে প্রক্রিয়া শুরু করবেন।


এটা আসলে ভাল সঙ্গে -XX:MaxRam। আমি মনে করি এটি এখনও সর্বোচ্চ সংজ্ঞায়িতের চেয়ে বেশি ব্যবহার করছে তবে এটি আরও ভাল, ধন্যবাদ!
নিকোলাস হেনাওক্স

সম্ভবত আপনার এই জাভা দৃষ্টান্তটির জন্য আরও স্মৃতি দরকার। 15267 ক্লাস, 56 টি থ্রেড রয়েছে।
জান গরাজ

1
এখানে আরও বিশদ, জাভা আর্গুমেন্ট -Xmx128m -Xms128m -Xss228k -XX:MaxRAM=256m -XX:+UseSerialGC, উত্পাদন Docker 428.5MiB / 600MiBএবং jcmd 58 VM.native_memory -> Native Memory Tracking: Total: reserved=1571296KB, committed=314316KBজেভিএম প্রায় 300MB নিচ্ছে যখন ধারকটির 430MB প্রয়োজন। জেভিএম রিপোর্টিং এবং ওএস প্রতিবেদনের মধ্যে ১৩০ এমবি কোথায়?
নিকোলাস হেনাওক্স

1
আরএসএস মেমরি সম্পর্কে তথ্য / লিঙ্ক যুক্ত হয়েছে।
জান গরাজ

প্রদত্ত আরএসএস কেবল ps -p 71 -o pcpu,rss,size,vsizeজাভা প্রসেসের জন্য ধারকটির ভিতরে থেকে কেবল জাডিয়া প্রসেসের -XX:MaxRamসাথে পিড with১ রয়েছে।
নিকোলাস হেনাওক্স

8

টি এল; ডিআর

মেমরির বিশদ ব্যবহার নেটিভ মেমরি ট্র্যাকিং (এনএমটি) বিশদ (মূলত কোড মেটাটাটা এবং আবর্জনা সংগ্রহকারী) সরবরাহ করে। এটি ছাড়াও, জাভা সংকলক এবং অপ্টিমাইজার সি 1 / সি 2 সারাংশে রিপোর্ট করা মেমরিটি গ্রাস করে না।

জেভিএম পতাকা ব্যবহার করে মেমরির পদচিহ্ন হ্রাস করা যেতে পারে (তবে এর প্রভাব রয়েছে)।

প্রত্যাশিত লোড প্রয়োগের সাথে পরীক্ষার মাধ্যমে অবশ্যই ডকারের ধারক আকারের কাজটি করা উচিত।


প্রতিটি উপাদান জন্য বিশদ

ভাগ বর্গ স্থান একটি ধারক ভিতরে অক্ষম করা যেতে পারে যেহেতু ক্লাস অন্য জেভিএম প্রক্রিয়া দ্বারা ভাগ করা হবে না। নিম্নলিখিত পতাকা ব্যবহার করা যেতে পারে। এটি ভাগ করা শ্রেণীর স্থান (17MB) সরিয়ে ফেলবে।

-Xshare:off

দ্য আবর্জনা সংগ্রাহক সিরিয়াল আবর্জনা সংগ্রহ প্রক্রিয়াকরণের সময় আর বিরতি সময় খরচে একটি ন্যূনতম মেমরির পদাঙ্ক (দেখুন রয়েছে এক ছবিতে জিসি মধ্যে Aleksey Shipilëv তুলনা )। এটি নিম্নলিখিত পতাকা সহ সক্ষম করা যেতে পারে। এটি ব্যবহৃত জিসি স্পেস (48 এমবি) পর্যন্ত সংরক্ষণ করতে পারে।

-XX:+UseSerialGC

দ্য C2 এ কম্পাইলার নিখুত বা না একটি পদ্ধতি তা ঠিক করার জন্য ব্যবহৃত প্রোফাইলিং তথ্য কমাতে নিম্নলিখিত পতাকা দিয়ে নিষ্ক্রিয় করা যাবে।

-XX:+TieredCompilation -XX:TieredStopAtLevel=1

কোড স্পেস 20MB দ্বারা হ্রাস পেয়েছে। তদুপরি, JVM এর বাইরের মেমরিটি 80MB (এনএমটি স্পেস এবং আরএসএস স্পেসের মধ্যে পার্থক্য) দ্বারা হ্রাস পায়। অনুকূলকরণ সংকলক সি 2 এর 100MB প্রয়োজন।

দ্য C1 এবং C2 কম্পাইলার নিম্নলিখিত পতাকা দিয়ে নিষ্ক্রিয় করা যাবে।

-Xint

জেভিএমের বাইরের স্মৃতি এখন মোট প্রতিশ্রুতিবদ্ধ স্থানের চেয়ে কম। কোড স্পেস 43MB দ্বারা হ্রাস পেয়েছে। সাবধান, এটি অ্যাপ্লিকেশনটির কার্য সম্পাদনে বড় প্রভাব ফেলে। সি 1 এবং সি 2 সংকলক অক্ষম করা 170 এমবি দ্বারা ব্যবহৃত স্মৃতি হ্রাস করে।

ব্যবহার গ্রাল ভিএম সংকলক (সি 2 এর প্রতিস্থাপন)কিছুটা ছোট মেমরির পদক্ষেপের দিকে নিয়ে যায়। এটি কোডের মেমরির স্থান 20MB বৃদ্ধি করে এবং JVM মেমরির বাইরের থেকে 60MB হ্রাস পায়।

জেভিএমের জন্য জাভা মেমরি ম্যানেজমেন্ট নিবন্ধটি বিভিন্ন মেমরি স্পেসগুলির সাথে কিছু প্রাসঙ্গিক তথ্য সরবরাহ করে। ওরাকল নেটিভ মেমরি ট্র্যাকিং ডকুমেন্টেশনে কিছু বিশদ সরবরাহ করে । উন্নত সংকলন নীতি এবং সি 2 অক্ষম করতে সংকলন স্তর সম্পর্কে আরও বিশদ কোড ফ্যাক্টর দ্বারা কোড ক্যাশে আকার হ্রাস করুন । কিছু বিবরণ কেন একজন জেভিএম প্রতিবেদন আরো অঙ্গীকারবদ্ধ মেমরির লিনাক্স চেয়ে প্রক্রিয়া বাসিন্দা সেট আকার করে? যখন উভয় সংকলক অক্ষম থাকে।


-1

জাভার অনেক স্মৃতি দরকার। জেভিএম নিজেই চালাতে প্রচুর স্মৃতি দরকার। হিপ হ'ল মেমোরি যা ভার্চুয়াল মেশিনের ভিতরে উপলব্ধ, আপনার অ্যাপ্লিকেশনের জন্য উপলব্ধ। কারণ জেভিএম হ'ল একটি বড় বান্ডিল যা সমস্ত গুডিতে ভরপুর রয়েছে এটি কেবল লোড করতে অনেক বেশি মেমরি লাগে।

জাভা 9 দিয়ে শুরু করে আপনার কাছে প্রজেক্ট জিগস নামে কিছু রয়েছে যা জাভা অ্যাপ্লিকেশন শুরু করার সময় ব্যবহৃত স্মৃতিশক্তি হ্রাস করতে পারে (শুরু করার সময় সহ)। প্রজেক্ট জিগাস এবং একটি নতুন মডিউল সিস্টেম প্রয়োজনীয় মেমরি হ্রাস করার জন্য তৈরি করা হয়নি, তবে এটি গুরুত্বপূর্ণ হলে আপনি চেষ্টা করে দেখতে পারেন।

আপনি এই উদাহরণটি একবার দেখে নিতে পারেন: https://steveperkins.com/ using-java-9-modulariization-to-ship-zero-d dependency-native-apps/ । মডিউল সিস্টেমটি ব্যবহার করে এটি 21 এমবি (জেআরই এমবেডেড সহ) এর সিএলআই অ্যাপ্লিকেশনটির ফলস্বরূপ। জেআরই 200 মিমি বেশি লাগে। অ্যাপ্লিকেশন শেষ হওয়ার পরে এটি কম বরাদ্দ মেমরিতে অনুবাদ করা উচিত (প্রচুর অব্যবহৃত জেআরই ক্লাস আর লোড হবে না)।

এখানে আরও একটি সুন্দর টিউটোরিয়াল: https://www.baeldung.com/project-jigsaw-java- আধুনিকতা

আপনি যদি এর সাথে সময় ব্যয় করতে না চান তবে আপনি আরও বেশি মেমরি বরাদ্দ করতে পারেন। কখনও কখনও এটি সেরা।


jlinkঅ্যাপ্লিকেশনটি সংশোধন করা দরকার বলে ব্যবহার করা বেশ সীমাবদ্ধ। স্বয়ংক্রিয় মডিউল সমর্থিত নয় তাই সেখানে যাওয়ার কোনও সহজ উপায় নেই।
নিকোলাস হেনাওক্স

-1

ডকার মেমরি সীমাটি কীভাবে সঠিকভাবে আকার করতে হবে? অ্যাপ্লিকেশনটি কিছু সময়ের জন্য এটি পর্যবেক্ষণ করে দেখুন। ধারকটির স্মৃতি সীমাবদ্ধ করতে ড-রান কমান্ডের জন্য --m, - মেমরি বাইট বিকল্প ব্যবহার করতে চেষ্টা করুন - বা আপনি যদি অন্যভাবে এটি চালাচ্ছেন তবে সমান কিছু

docker run -d --name my-container --memory 500m <iamge-name>

অন্যান্য প্রশ্নের উত্তর দিতে পারে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.