Java৪-বিট ওএসে একটি 32-বিট জেভিএমের সর্বোচ্চ জাভা হিপ আকার size


107

32-বিট ওএসের সর্বাধিক হিপ আকার সম্পর্কে প্রশ্ন নয়, দেওয়া হয়েছে যে 32-বিট ওএসের সর্বাধিক ঠিকানাযোগ্য 4 মেমরির আকার রয়েছে এবং জেভিএমের সর্বাধিক হিপ আকারটি কতটা নিখরচায় মুক্ত মেমরি সংরক্ষণ করতে পারে তার উপর নির্ভর করে।

আমি 64৪-বিট ওএসে চলমান ৩২-বিট জেভিএমের সর্বাধিক (তাত্ত্বিক এবং ব্যবহারিকভাবে উভয়ই অর্জনযোগ্য) হ্যাপের আকার জানতে আরও আগ্রহী। মূলত, আমি এসও সম্পর্কিত একটি প্রশ্নের মধ্যে পরিসংখ্যানগুলির অনুরূপ উত্তরগুলি দেখছি ।

কেন 64৪-বিটের পরিবর্তে 32-বিট জেভিএম ব্যবহার করা হয়, কারণটি প্রযুক্তিগত নয় বরং প্রশাসনিক / আমলাতান্ত্রিক - উত্পাদন পরিবেশে একটি 64-বিট জেভিএম ইনস্টল করতে সম্ভবত খুব দেরি হয়েছে is

উত্তর:


70

৩২-বিট জেভিএম যা প্রত্যাশা করে যে একক বড় মেমোরি রয়েছে এবং কাঁচা পয়েন্টার ব্যবহার করে তারা 4 জিবি-র বেশি ব্যবহার করতে পারে না (যেহেতু এটি 32 টি বিট সীমা যা পয়েন্টারগুলিতেও প্রযোজ্য)। এর মধ্যে সান এবং - আমি বেশ নিশ্চিত - আইবিএম বাস্তবায়নও অন্তর্ভুক্ত। আমি জানি না উদাহরণস্বরূপ JRockit বা অন্যদের কাছে 32-বিট বাস্তবায়ন সহ একটি বড় মেমরি বিকল্প রয়েছে কিনা।

আপনি যদি এই সীমাটিকে আঘাত হানার প্রত্যাশা করেন তবে আপনার উত্থানের পরিবেশের জন্য 64৪-বিট জেভিএমকে বৈধতা দেওয়ার জন্য একটি সমান্তরাল ট্র্যাক শুরু করার বিষয়ে দৃ strongly়তার সাথে বিবেচনা করা উচিত যাতে 32-বিট পরিবেশটি ভেঙে যাওয়ার জন্য আপনার প্রস্তুত থাকে have অন্যথায় চাপের মধ্যে আপনাকে সেই কাজটি করতে হবে, যা কখনই সুন্দর হয় না।


2014-05-15 সম্পাদনা করুন: ওরাকল এফএকিউ:

32-বিট জেভিএমের সর্বাধিক তাত্ত্বিক হিপ সীমা 4 জি। বিভিন্ন অতিরিক্ত বাধা যেমন উপলব্ধ অদলবদল, কার্নেল ঠিকানার জায়গার ব্যবহার, মেমরি ফ্র্যাগমেন্টেশন এবং ভিএম ওভারহেডের কারণে অনুশীলনে সীমাটি অনেক কম হতে পারে। বেশিরভাগ আধুনিক 32-বিট উইন্ডোজ সিস্টেমে সর্বাধিক হ্যাপের আকার 1.4G থেকে 1.6G অবধি হবে। 32-বিট সোলারিস কার্নেলগুলিতে ঠিকানার স্থান 2 জি-তে সীমাবদ্ধ। 32-বিট ভিএম চালিত 64৪-বিট অপারেটিং সিস্টেমগুলিতে, সোলারিস সিস্টেমে সর্বাধিক হ্যাপের আকার 4G এর কাছাকাছি হতে পারে।

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


এখানে কোনও কাজের চাপ নেই। আমি জানি যে প্রথম স্থানে একটি 64-বিট জেভিএম ইনস্টল করা উচিত ছিল। তবে এটি কীভাবে একটি 32-বিট জেভিএম তার পরিবেশনে আরও সংস্থান নিয়ে পরিবেশে কাজ করবে সে সম্পর্কে আমাকে ভাবতে বাধ্য করেছে।
ভিনিতে রেনল্ডস

1
এটি সাইনডনেসগুলি 2 জিবি কাছাকাছি না? নাকি সেটাই কি সান জেভিএম?
সেবাস্তিয়ান গ্যানসল্যান্ড 18

9
পয়েন্টারগুলি স্বাক্ষরিত নয় - নেতিবাচক মেমরির অবস্থানগুলির কথা বলার অর্থ নেই।
থোরবজর্ন রাভন অ্যান্ডারসন

12
না, স্বাক্ষরের কারণে এটি 2 জিবি নয়। তবে, 4 জিবি ঠিকানা স্পেসের কিছু অংশ ওএস কার্নেলের জন্য সংরক্ষিত। উইন্ডোজের সাধারণ গ্রাহক সংস্করণে, সীমাটি 2 জিবি। লিনাক্স এবং উইন্ডোজ এর সার্ভার সংস্করণে (32-বিট) প্রতিটি প্রক্রিয়াতে সীমা 3GB।
জেস্পার

3
@ জেস্পার আমি ভাবছিলাম যে 32৪-বিট অপারেটিং সিস্টেমে কোনও 32-বিট জেভিএম চলমান একটি 4 গিগাবাইট ঠিকানা স্থান উপলব্ধ থাকতে পারে?
থরবজর্ন রাভন অ্যান্ডারসন

90

আপনি জাভা রানটাইম জিজ্ঞাসা করতে পারেন:

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-বিট হটস্পট জেভিএম 1577MiB অবধি বরাদ্দ করতে পারে:

[সি: স্ক্র্যাচ]> জাভা -Xmx1600 এম ম্যাক্সেমোরি
ভিএম শুরু করার সময় ত্রুটি ঘটেছে
অবজেক্ট হ্যাপের জন্য পর্যাপ্ত জায়গা সংরক্ষণ করতে পারেনি
জাভা ভার্চুয়াল মেশিন তৈরি করতে পারে নি.
[সি: স্ক্র্যাচ]> জাভা -Xmx1590M ম্যাক্সেমোরি
মোট স্মৃতি: 2031616 (1.9375 মাইবি)
সর্বাধিক স্মৃতি: 1654456320 (1577.8125 মাইবি)
ফ্রি মেমোরি: 1840872 (1.75559234619 MiB)
[সি: স্ক্র্যাচ]>

যেখানে একই ওএসে 64৪ -বিট জেভিএম রয়েছে, অবশ্যই এটি অনেক বেশি (প্রায় 3 টিআইবি)

[সি: স্ক্র্যাচ]> জাভা-এক্সএমএক্স 3560 জি ম্যাক্সেমোরি
ভিএম শুরু করার সময় ত্রুটি ঘটেছে
অবজেক্ট হ্যাপের জন্য পর্যাপ্ত জায়গা সংরক্ষণ করতে পারেনি
[সি: স্ক্র্যাচ]> জাভা-এক্সএমএক্স 3550 জি ম্যাক্সেমোরি
মোট স্মৃতি: 94240768 (89.875 মাইবি)
সর্বাধিক স্মৃতি: 3388252028928 (3184151.84297 এমআইবি)
ফ্রি মেমোরি: 93747752 (89.4048233032 মাইবি)
[সি: স্ক্র্যাচ]>

অন্যরা যেমন ইতিমধ্যে উল্লেখ করেছে, এটি ওএসের উপর নির্ভর করে।

  • 32-বিট উইন্ডোজের জন্য: এটি <2GB হবে ( উইন্ডোজ ইন্টারনাল বইতে ব্যবহারকারী প্রসেসের জন্য 2 জিবি বলে)
  • 32-বিট বিএসডি / লিনাক্সের জন্য: <3 জিবি (শয়তান বই থেকে)
  • 32-বিট ম্যাকোস এক্স এর জন্য: <4 জিবি ( ম্যাক ওএস এক্স ইন্টারনাল বই থেকে)
  • 32-বিট সোলারিস সম্পর্কে নিশ্চিত নন, উপরের কোডটি ব্যবহার করে দেখুন এবং আমাদের জানান।

একটি 64-বিট হোস্ট ওএসের জন্য, যদি জেভিএম 32-বিট হয় তবে এটি এখনও নির্ভর করবে, সম্ভবত উপরের মতো প্রদর্শিত হবে।

- 20110905 আপডেট করুন : আমি কেবল কিছু অন্যান্য পর্যবেক্ষণ / বিশদটি উল্লেখ করতে চেয়েছিলাম:

  • আমি যে হার্ডওয়্যারটি চালিয়েছি তা হ'ল GB৪ বিট প্রকৃত র‌্যাম ইনস্টল হয়েছে। অপারেটিং সিস্টেমটি ছিল উইন্ডোজ 7 এন্টারপ্রাইজ, 64-বিট
  • এর প্রকৃত পরিমাণ Runtime.MaxMemoryবরাদ্দ করা যায় অপারেটিং সিস্টেমের কার্যকারী সেটের উপরও নির্ভর করে । ভার্চুয়ালবক্স চলাকালীন আমি একবার এটি চালিয়েছি এবং হটস্পট জেভিএম সাফল্যের সাথে আরম্ভ করতে পারিনি-Xmx1590M এবং আরও ছোট হতে হয়েছিল। এটি এও বোঝায় যে আপনি সেই সময় আপনার কার্যনির্বাহী আকারের উপর নির্ভর করে 1590M এর বেশি পেতে পারেন (যদিও আমি এখনও বজায় রেখেছি এটি উইন্ডোজ ডিজাইনের কারণে 32-বিটের জন্য 2GiB এর অধীনে থাকবে)

13
আমি পছন্দ করি যে আপনি আসলে অনুমানের চেয়ে পরীক্ষা করেছেন।
জিম হুর্ন

3
@ ডিজেঙ্গোফান ঠিক আছে প্রোগ্রামটি 104,856 নয়, 1,048,576 (1024 * 1024 বা 2 ^ 20) দ্বারা ভাগ করা উচিত। তবে, এটি কেবল একটি প্রদর্শন জিনিস। আপনি কমান্ডটি থেকে দেখতে পাচ্ছেন, তিনি কেবল সর্বোচ্চ গাদা আকারটি 1,590 এমবি সেট করার চেষ্টা করেছিলেন।
জিম হুরনে

1
খুব উত্তর ঠান্ডা (আমি বলতে চাই উত্তর), একটি কোড উদাহরণ সঙ্গে, এবং বিস্তারিত সব অপারেটিং সিস্টেমের আচ্ছাদন।
TGP1994

3
আমার পূর্ববর্তী মন্তব্য অনুসরণ করে: jdocs (অন্তত উইন্ডোজগুলির জন্য) নির্দিষ্ট করে যে -Xmx এবং -Xms প্যারামিটারগুলিকে অবশ্যই 1024 এর একাধিক মান দেওয়া উচিত ... আমি নিশ্চিত না 1515 হয় কিনা তাই আমি আশ্চর্যজনক মনে করি ফলাফল আশা করা উচিত।
TGP1994

4
ভাল স্পটেড টিজিপি 1994। আমি মনে করি, কারণ আমি 'এম' এবং 'জি' গুণগুলি নির্দিষ্ট করেছি, তবে আকার (বাইটে) যাইহোক 1024 বাইটের একাধিক হিসাবে কাজ করবে। যেমন 1590M 1590 * (1024 * 1024) = 1667235840 বাইট (1628160KiB - 1024 এর অবশ্যই একাধিক) এ পার্স করা হবে।
মাইকে

16

আপনি কোন ওএস নির্দিষ্ট করবেন না ।

উইন্ডোজের অধীনে (আমার অ্যাপ্লিকেশনটির জন্য - একটি দীর্ঘ চলমান ঝুঁকি ব্যবস্থাপনার অ্যাপ্লিকেশন) আমরা লক্ষ্য করেছি যে আমরা উইন্ডোজ 32 বিট-এ 1280MB এর চেয়ে বেশি কিছুতে যেতে পারি না। আমি সন্দেহ করি যে bit৪ বিবিটের নীচে 32 বিবিটি জেভিএম চালানো যে কোনও তাত্পর্য সৃষ্টি করবে।

আমরা অ্যাপ্লিকেশনটিকে লিনাক্সে পোর্ট করেছি এবং আমরা bit৪ বিট হার্ডওয়্যারটিতে একটি 32 বিবিটি জেভিএম চালিয়ে যাচ্ছি এবং খুব সহজেই একটি 2.2GB ভিএম চলছে।

আপনার সবচেয়ে বড় সমস্যাটি হ'ল জিসি আপনি কীসের জন্য মেমরি ব্যবহার করছেন তার উপর নির্ভর করে।


আমি সোলারিস 10 এর সীমাবদ্ধতাটি জানতে পছন্দ করব তবে তারপরে এটি কেবল আমার সমস্যার জন্য। অন্যান্য ওএসের জন্যও বর্ষার দিনের জন্য জানতে চাই :)
ভিনিত রেনল্ডস

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

এটি কোন উইন্ডোজ ছিল। আমি বিশ্বাস করি উইন্ডোজ 32-বিটের সার্ভার সংস্করণগুলি বৃহত্তর পরিমাণে মেমরিটিকে আরও ভালভাবে পরিচালনা করতে পারে।
থোরবজর্ন রাভন অ্যান্ডারসন

আহ, অবশেষে ওএস এর একটি উল্লেখ ;-) আপনি একটি -৪-বিট কার্নেল ইনস্টল করেছেন?
থোরবজর্ন রাভন অ্যান্ডারসন

এটি ছিল Win2k সার্ভার। উইন 2 কে 3 এ সরানো (জিনিসগুলি ধীরে ধীরে সরে যায় ..) খুব দেরি হয়ে গেছে এবং আমরা তার পরিবর্তে লিনাক্সে স্যুইচ করেছি।
ফরটিআরুনার

14

4.1.2 থেকে হিপ সাইজিং :

"৩২-বিট প্রক্রিয়া মডেলের জন্য, প্রক্রিয়াটির সর্বাধিক ভার্চুয়াল ঠিকানার আকার সাধারণত 4 গিগাবাইট হয় যদিও কিছু অপারেটিং সিস্টেম এটিকে 2 জিবি বা 3 জিবিতে সীমাবদ্ধ করে দেয়। ), যদিও প্রকৃত সীমাবদ্ধতাটি নির্ভরশীল অ্যাপ্লিকেশন 64৪-বিট প্রক্রিয়া মডেলের ক্ষেত্রে, সর্বাধিক মূলত সীমাহীন ""

এখানে একটি দুর্দান্ত উত্তর পেয়েছে: উইন্ডোজ এক্সপি তে জাভা সর্বাধিক মেমরি


12

আমরা সম্প্রতি এটির সাথে কিছু অভিজ্ঞতা পেয়েছি। আমরা সোলারিস (x86-64 সংস্করণ 5.10) থেকে লিনাক্সে (রেডহ্যাট x86-64) পোর্ট করেছি এবং বুঝতে পেরেছি যে সোলারিসের তুলনায় লিনাক্সে 32 বিট জেভিএম প্রক্রিয়ার জন্য আমাদের কম মেমরি উপলব্ধ available

সোলারিসের জন্য এটি প্রায় 4 জিবি (http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit) প্রায় আসে।

আমরা আমাদের অ্যাপ -Xms2560m -Xmx2560m -XX: ম্যাক্স্পার্মসাইজ = 512 মি-এক্সএক্স: পার্মসাইজ = 512 মি নিয়ে গত কয়েক বছর ধরে সোলারিস নিয়ে কোনও সমস্যা নেই with এটি লিনাক্সে স্থানান্তরিত করার চেষ্টা করা হয়েছিল এবং আমাদের শুরুতে স্মৃতি ত্রুটি থেকে এলোমেলো সমস্যা ছিল। আমরা কেবল এটি -Xms2300 -Xmx2300 এ ধারাবাহিকভাবে শুরু করতে পারি । তারপরে সমর্থন দ্বারা আমাদের এটি সম্পর্কে পরামর্শ দেওয়া হয়েছিল।

লিনাক্সে একটি 32 বিট প্রক্রিয়াতে 3gb (3072mb) সর্বাধিক ঠিকানার ঠিকানার স্থান রয়েছে তবে সোলারিসে এটি পূর্ণ 4gb (4096mb)।


সমর্থনের দ্বারা প্রদত্ত উত্তরের কারণটি কোনও প্রক্রিয়াতে কতটা ঠিকানাযোগ্য স্মৃতি উপলব্ধ in তার মধ্যে রয়েছে। এটি লিনাক্স কার্নেল এবং এমনকি হার্ডওয়ারের উপর নির্ভর করে। তাত্ত্বিকভাবে, ঠিকানাযোগ্য মেমরিটি 2 ^ 32 = 4G এর মধ্যে সীমাবদ্ধ (এবং জাভা হ্যাপের আকারটি এর চেয়ে কম হবে)। তবে, এটিকে (তাত্ত্বিকভাবে) বিশাল মাইম এবং পিএই ব্যবহার করে বাড়ানো যেতে পারে; আমি এটি চেষ্টা করিনি।
ভিনিত রেনল্ডস

9

-৪-বিট ওএস-তে একটি 32-বিট জেভিএমের সীমাবদ্ধতা 32-বিট ওএস-তে 32-বিট জেভিএমের সীমাবদ্ধতার মতোই হবে। সর্বোপরি, 32-বিট জেভিএম একটি 32-বিট ভার্চুয়াল মেশিনে চলবে (ভার্চুয়ালাইজেশন অর্থে) যাতে এটি জানতে পারে না যে এটি 64-বিট ওএস / মেশিনে চলছে।

32-বিট ওএসের বিপরীতে 64-বিট ওএসে 32-বিট জেভিএম চালানোর এক সুবিধাটি হ'ল আপনার আরও শারীরিক স্মৃতি থাকতে পারে, এবং তাই কম ঘন ঘন অদলবদল / পেজিংয়ের মুখোমুখি হবেন। তবে আপনার যদি একাধিক প্রক্রিয়া থাকে তবে এই সুবিধাটি সত্যই পুরোপুরি উপলব্ধি করা যায়।


1
হার্ডওয়্যার এবং এটি কীভাবে ভার্চুয়ালাইজ করা হয়েছে তার উপর নির্ভর করে কিছুটা পার্থক্য থাকতে পারে। 4 জিবি অ্যাড্রেসযোগ্য স্পেসের কিছু সাধারণত মেমরি ম্যাপযুক্ত ডিভাইসের জন্য ব্যবহৃত হয়। ভার্চুয়ালাইজেশন স্তরটির মেশিনে শারীরিক ডিভাইসের মতো মেমরির পদচিহ্ন থাকতে পারে এবং নাও থাকতে পারে।
এরিক জে

8
বেশ না। অপারেটিং সিস্টেম বা হার্ডওয়্যার ইন্টারফেসের সাথে 32-বিট অ্যাড্রেস স্পেস ভাগ করার দরকার নেই বলে 64-বিট মেশিনে জেভিএমের আরও জায়গা রয়েছে।
থরবজর্ন রাভন অ্যান্ডারসন

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

থরবজর্ন: অপারেটিং সিস্টেম এবং হার্ডওয়্যার ইন্টারফেসগুলি এখনও 32-বিট ভিএম-এ ম্যাপ করা দরকার। শ্রবণটির সঠিক পরিমাণটি ভিন্ন হতে পারে তবে এটি এখনও থাকবে। যদি আপনি এটি একটি -৪-বিট ওএসের আওতায় ভার্চুয়ালাইজ করতে পারেন তবে এটি আপনাকে 32-বিট ওএসের আওতায় ভার্চুয়ালাইজিং করা থেকে বিরত রাখতে পারে? এটি আমরা ভার্চুয়াল মেমরির কথা বলছি।
লরেন্স গনসালভেস

2
এলজি: আমি আপনার মূল উত্তরটির সাথে একমত নই। ওএস কার্নেল এবং যে কোনও এইচডাব্লু এবং বাসের ঠিকানা স্থান এটি মানচিত্রগুলি প্রচুর ঠিকানা স্থান চিবিয়ে তুলবে, এবং এটি ব্যবহারকারী প্রোগ্রামে ম্যাপ না করা থাকলে, ওএস নিজেকে সেট আপ করার পরে এটি "বামদিকে" পরিমাণ হ্রাস করবে। এটি 4 জিবি 32-বিট স্পেসের যথেষ্ট পরিমাণ। Ditionতিহ্যগতভাবে, এর অর্থ হ'ল 4GB এর প্রায় 25% -75% ব্যবহারকারী প্রসেসের জন্য অনুপলব্ধ। :-) কার্নেল হ্যাকার
ডিজিটালরোস

6

কেন 64৪-বিটের পরিবর্তে ৩২-বিট জেভিএম ব্যবহার করা হয়, কারণটি প্রযুক্তিগত নয়, বরং প্রশাসনিক / আমলাতান্ত্রিক ...

আমি যখন বিআইএর জন্য কাজ করছিলাম, তখন আমরা দেখতে পেলাম যে গড় অ্যাপ্লিকেশনটি একটি 64-বিট জেভিএম-তে আসলে ধীরে ধীরে চলেছে , তখন 32-বিট জেভিএম-তে চলার সময় এটি হয়েছিল। কিছু ক্ষেত্রে, পারফরম্যান্স হিট 25% ধীর গতিতে বেশি ছিল। সুতরাং, যতক্ষণ না আপনার অ্যাপ্লিকেশনটির সমস্ত অতিরিক্ত মেমরির প্রয়োজন হয়, আপনি আরও 32-বিট সার্ভার সেট আপ করা থেকে ভাল।

আমার স্মরণ হিসাবে, বিএএর পেশাদারী পরিষেবাগুলির কর্মীরা যে 64৪-বিট ব্যবহারের জন্য তিনটি সাধারণ প্রযুক্তিগত ন্যায্যতা ছিল:

  1. অ্যাপ্লিকেশনটি একাধিক বিশাল চিত্রগুলি ম্যানিপুলেট করছে,
  2. অ্যাপ্লিকেশনটি বিশাল সংখ্যক ক্রাঞ্চিং করছে,
  3. অ্যাপ্লিকেশনটির একটি মেমরি ফাঁস ছিল, গ্রাহক একটি সরকারী চুক্তির প্রধান বিষয়, এবং তারা মেমরি ফাঁস ট্র্যাক করার সময় এবং ব্যয় নিতে চান না। (একটি বিশাল মেমোরি হিপ ব্যবহার এমটিবিএফ বাড়িয়ে দেবে এবং প্রাইম এখনও প্রদান করবে)



4

ওরাকলের মালিকানাধীন JROCKIT JVM বর্তমানে অবিসংবাদিত হিপ ব্যবহার সমর্থন করে, এইভাবে যখন JVM একটি 64 বিট উইন্ডোজ ওএসে চলছে তখন 32 বিট জেভিএমকে 3.8 গিগাবাইট মেমরির আরও বেশি অ্যাক্সেসের অনুমতি দেয়। (32 বিট ওএসে চলাকালীন 2.8 গিগাবাইট)।

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

জেভিএম এ নিখরচায় ডাউনলোড করা যায় (নিবন্ধকরণ প্রয়োজন)

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


4

এখানে সোলারিস এবং লিনাক্স 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

বিটিডাব্লু: স্পষ্টতই জাভা শুরু করার সাথে খুব বেশি প্রকৃত মেমরি বরাদ্দ করে না। দেখে মনে হয়েছে প্রতি মুহূর্তে প্রায় 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

আমরা যে প্ল্যাটফর্মগুলি মিস করছি তার জন্য এখানে কয়েকটি দরকারী পরীক্ষার ফলাফল রয়েছে। ফাইল এবং মেমরি ডাম্পগুলি ব্যবহার করে খুব ভাল কাজ।
মাইকে

3

অনেক ভাল হওয়া উচিত

32৪-বিট হোস্টে একটি 32-বিট জেভিএম চলার জন্য, আমি কল্পনা করেছিলাম যে জীভিএমের পরে অবিচ্ছিন্ন ভার্চুয়াল স্পেস যা পাওয়া যাবে তা তার নিজস্ব ডিএলএল এর, এবং কোনও ওএস 32-বিট সামঞ্জস্যতা স্টাফ লোড হওয়ার পরে হিপগুলির জন্য যা অবশিষ্ট রয়েছে তা হবে। বন্য অনুমান হিসাবে আমি ভাবব 3 গিগাবাইট সম্ভব হওয়া উচিত, তবে এটি কতটা ভাল তার উপর নির্ভর করে আপনি 32-বিট-হোস্ট-জমিতে কতটা ভাল করছেন on

এছাড়াও, আপনি যদি একটি বিশাল 3 গিগাবাইট হিপ তৈরি করতে পারেন তবে আপনি এটি করতেও চাইবেন না, কারণ এটি জিসি বিরতি দেয় সম্ভাব্য সমস্যা হতে পারে। কিছু লোক কেবল একটি দৈত্যের চেয়ে অতিরিক্ত মেমরি ব্যবহার করতে আরও JVM চালায়। আমি ভেবেছি দৈত্যাকার স্তূপগুলির সাথে আরও ভালভাবে কাজ করার জন্য তারা এখনই জেভিএম-এর টিউন করছে।

আপনি কতটা আরও ভাল করতে পারবেন তা জানা একটু কঠিন। আমি অনুমান করি যে আপনার 32-বিট পরিস্থিতিটি পরীক্ষার মাধ্যমে সহজেই নির্ধারণ করা যায়। এটি অবশ্যই বিমূর্তভাবে ভবিষ্যদ্বাণী করা শক্ত, কারণ এতে অনেক কিছু ফ্যাক্টর রয়েছে, বিশেষত কারণ 32-বিট হোস্টগুলিতে উপলভ্য ভার্চুয়াল স্পেসটি বরং সীমাবদ্ধ .. এই গর্তটির অবিচ্ছিন্ন ভার্চুয়াল মেমরির উপস্থিতি থাকা দরকার, সুতরাং ঠিকানার জায়গার বিভাজন ওএস কার্নেল দ্বারা dll এর এবং ঠিকানা জায়গার অভ্যন্তরীণ ব্যবহার সম্ভাব্য বরাদ্দের সীমা নির্ধারণ করবে।

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

ডিএলএল লোড করা জেভিএম বাস্তবায়ন এবং প্রকাশের উপর নির্ভর করে। ওএস কার্নেলটি লোড করা বিপুল সংখ্যক বিষয়, রিলিজ, এইচডাব্লু, নির্ভর করে যে এটি পুনরায় বুট করার পরে এখন পর্যন্ত কতটি জিনিস ম্যাপ করেছে, কে জানে ...

সংক্ষেপে

আমি বাজি ধরছি আপনি 32-বিট-জমিতে 1-2 গিগাবাইট পাবেন এবং 64-বিটে প্রায় 3 পাবেন, সুতরাং সামগ্রিকভাবে প্রায় 2x এর উন্নতি হবে ।


1
দুর্ভাগ্যক্রমে, আমার কাছে আমার a৪-বিট পরিবেশ নেই যেখানে আমি এক্সএমএক্স পতাকাটি ব্যবহার করতে পারি। আমি যেটি জানি তার একটি হিউমোগাস (32 * এন) গিগাবাইট পরিমাণ র‍্যাম পাওয়া যায়, তবে সীমা ছাড়িয়ে যায়। এ কারণেই আমি জানতে চেয়েছিলাম যে 32-বিট জেভিএম কীভাবে সমস্ত 3200-বিট বিশ্বে সাধারণত যে সমস্ত প্রতিবন্ধকতাগুলির মুখোমুখি হয় তা ছাড়াই কাজ করবে।
ভিনিতে রেনল্ডস

ভাল, ভাল প্রশ্ন। আমি নিশ্চিত যে এর মূল উত্তরটি "এটি আরও ভাল কাজ করবে"।
ডিজিটালরোস

ঠিক আছে, আমি আপনার উত্তরটি আপনার আসল প্রশ্নে আরও কিছুটা ফোকাস করার জন্য সম্পাদনা করেছি। :-)
ডিজিটালরোস

1
Right 3 গিগাবাইট মধ্যে 64-বিট শব্দ প্রায় ঠিক ডান। থোরজজर्न ইতিমধ্যে ইঙ্গিত দিয়েছিলেন যে এটি তাত্ত্বিকভাবে 4 জিবি অতিক্রম করতে পারে না কেন। খুব খারাপ আমি দুটি উত্তর গ্রহণ করতে পারি না।
ভিনিতে রেনল্ডস

আপনার যদি একটি বড় বাক্স থাকে, আপনি উদাহরণস্বরূপ ভার্চুয়ালবক্সে (যা সেরা সোলারিস অতিথির সমর্থন রয়েছে) একটি 64৪-বিট সোলারিসের সাথে পরীক্ষা করতে পারেন।
থোরবজর্ন রাভন অ্যান্ডারসন

2

সোলারিসে সোলারিস 2.5 এর পরে সীমাটি প্রায় 3.5 গিগাবাইট হয়ে গেছে। (প্রায় 10 বছর আগে)


আমি যে নিয়ে পরীক্ষা করতে, ওরাকল সোলারিস এক্সপ্রেস ব্যবহার করছেন যাচ্ছি 11.
djangofan

1
@ পিটার লরে উহম .. সোলারিস 2.5 প্রায় 20 বছর আগে আপনি 1996 সালের মে মাসের মুক্তির তারিখটি বিবেচনা করলে .... অবশ্যই এটি 2005
সিবি 888

1

জেভিএম নিয়ে আমার একই সমস্যা ছিল যা অ্যান্ড্রয়েড ব্লকস সম্পাদক হিসাবে অ্যাপ উদ্ভাবক ব্যবহার করে। এটি 925 মি সর্বোচ্চে গাদা সেট করে। এটি যথেষ্ট নয় তবে আমি আমার মেশিনে বিভিন্ন এলোমেলো কারণের উপর নির্ভর করে এটি প্রায় 1200 মিটারের বেশি সেট করতে পারিনি।

আমি নাইটলি ডাউনলোড করেছি, ফায়ারফক্স থেকে বিটা -৪-বিট ব্রাউজার এবং জাভা 7 bit৪ বিট সংস্করণও।

আমি এখনও আমার নতুন গাদা সীমাটি খুঁজে পাইনি, তবে আমি সবেমাত্র একটি জেভিএম 5900 মিটার গাদা আকারের সাথে খোলে । সমস্যা নেই!

আমি 24 জিবি র‌্যাম সহ একটি মেশিনে উইন 7 64 বিট আলটিমেট চালাচ্ছি।


0

আমি 32 বিট লিনাক্স মেশিনে 2200M অবধি গাদা আকার সেট করার চেষ্টা করেছি এবং জেভিএম দুর্দান্ত কাজ করেছে। আমি যখন এটি 2300 এম তে সেট করি তখন JVM শুরু হয় নি।


আমি ভেবেছিলাম যে আমি উইন্ডোজ VISTA 64 বিট এ যুক্ত করব, একটি 32 বিট জেভিএম 1582 মি (-Xmx মান) এ সর্বাধিক আউট করে। আমি 1583 মি নির্দিষ্ট করে দিলে এটি অভিযোগ করবে। এই মানটি মেশিন থেকে মেশিনে পরিবর্তিত হয় কিনা তা আমি জানি না। আমি যে কম্পিউটারে এটি পরীক্ষা করেছি সেটিতে আসলে 4 জিবি শারীরিক র‍্যাম ছিল।
সন্তোষ তিওয়ারি

@ সন্তোষ তিওয়ারি এটি মেশিন থেকে মেশিনে পরিবর্তিত হয় তবে এখানে কেন
ইউজিন


0

হটস্পট 32-বিট জেভিএম-এর জন্য এখানে আরও একটি বিষয়: - নেটিভ হিপ ক্ষমতা = 4 গিগ - জাভা হিপ - পার্মজেন;

জাভা হিপ এবং নেটিভ হিপ একটি প্রতিযোগিতায় থাকার কারণে এটি 32-বিট জেভিএমের জন্য বিশেষত জটিল হয়ে উঠতে পারে। আপনার জাভা হিপটি যত বড়, নেটিভ হিপটি তত ছোট। 32-বিট ভিএম-এর জন্য বড় হিপ সেটআপ করার চেষ্টা করা হয় যেমন .2.5 গিগাবাইট + আপনার অ্যাপ্লিকেশন (গুলি) এর পদচিহ্ন, থ্রেডের সংখ্যা ইত্যাদির উপর ভিত্তি করে নেটিভ আউটআফমিওরিরর ঝুঁকি বাড়ায় increases


0

সীমাবদ্ধতাটি এই সত্য থেকেও আসে যে কোনও 32 bitভিএমের জন্য, heapযদি আপনি সমস্ত চান তবে নিজেই ঠিকানা শূন্য থেকে শুরু করতে হবে 4GB

আপনি যদি এর মাধ্যমে কিছু উল্লেখ করতে চান তবে এটি সম্পর্কে ভাবুন:

0000....0001

অর্থাত: একটি উল্লেখ যা এই নির্দিষ্ট বিট উপস্থাপনা আছে, এর অর্থ আপনি গাদা থেকে খুব প্রথম স্মৃতি অ্যাক্সেস করার চেষ্টা করছেন। এটি সম্ভব হওয়ার জন্য, গাদাটি ঠিকানা শূন্য থেকে শুরু করতে হবে। তবে এটি কখনও ঘটে না, এটি শূন্য থেকে কোনও অফসেটে শুরু হয়:

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

যেহেতু হিপ কখনও অ্যাড্রেস শূন্য থেকে শুরু হয় না OS, বেশ কয়েকটি বিট রয়েছে যা কখনও 32বিটস রেফারেন্স থেকে ব্যবহৃত হয় না এবং যেমন হিপগুলি রেফারেন্স করা যায় তা কম হয়।


-1

তাত্ত্বিক 4 জিবি, তবে অনুশীলনে (আইবিএম জেভিএমের জন্য):

উইন 2 কে 8 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.

RHEL 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.

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