بعد استبدال نظام التشغيل الخاص بالكمبيوتر العاملة بـ Win7 ، لم تكن Myeclipse غير مرضية في بدء التشغيل وسرعة التشغيل. خاصة عند تعديل وتصحيح قوالب صفحات متعددة في نفس الوقت ، سيكون التبديل بين ملفين دائمًا عالقًا لمدة عشر ثوانٍ. محاولة إيقاف تشغيل الإضافات المختلفة والتحقق منها لن تساعد. لذلك بعد دراسة JVM تقريبًا ، قررت محاولة حل هذه المشكلة من منظور JVM.
ابدأ التحسين:
أولاً ، دعونا نلقي نظرة على معلمات بدء التشغيل الافتراضية في myeclipse.ini:
-xmx512m: اضبط أقصى قيمة ذاكرة الكومة على 512 متر
-xx: maxpermsize = 256m: اضبط القيمة القصوى للجيل الثابت إلى 256 مترًا
-xx: محجوز CodeCachesize = 64m: اضبط حجم الذاكرة الذي تشغله الرمز إلى 64 مترًا
لا يمكن رؤية أي شيء من معلمات بدء التشغيل ، لذا أضف المعلمات ذات الصلة لطباعة تغييرات ذاكرة:
-xx:+printgctimestamps: اطبع الطابع الزمني لكل GC
-xx:+printgcdetails: طباعة معلومات مفصلة لكل GC
-xloggc: myeclipsegc.log: إخراج سجلات GC للملف
-Verbose: GC: إخراج الموقف ذي الصلة لكل GC
ثم ابدأ myeclipse وتحقق من المعلومات الموجودة في myeclipsegc.log:
يستغرق بدء التشغيل حوالي 30 ثانية. اعتراض انتقائي جزء صغير من السجلات. يمكنك أن ترى أنه في أول 10 ثوانٍ من بدء تشغيل Myeclipse ، قام JVM بتنفيذ أكثر من 300 GCs و 9 GCs كاملة.
من تردد GC ومعلوماته ، يمكن ملاحظة أن معدل استرداد الذاكرة مرتفع للغاية وأن الحجم يتم ضبطه باستمرار. يجب أن يكون هذا بسبب عدم كفاية مساحة في الجيل الأصغر سنا ، وهناك حاجة إلى قيمة أولية كبيرة.
ثم ركز على GC الكامل:
انسخ الرمز على النحو التالي: 5.961: [Full GC 5.961: [Terged: 34568K-> 34456K (49676K) ، 0.1397651 SECS] 35336K-> 34456K (53452K) [مرات: المستخدم = 0.14 sys = 0.00 ، حقيقي = 0.14 ثانية]
9.030: [GC Full 9.030: [Terged: 53310K-> 52332K (64588K) ، 0.2034757 SECS] 56020K-> 52332K (69516K) ، [PEM: 43007K-> 42996K (43008K)] SYS = 0.00 ، حقيقي = 0.20 ثانية]
من مقارنة السجلين ، يمكننا أن نرى أن GC الكامل تقوم بشكل أساسي بإعادة تدوير منطقتي المُثبَّدين والبلاغ ، ويجري تعديل أحجام هاتين المجالين باستمرار ، لذلك قررنا إصلاح حجمهما أولاً.
وبالتالي فإن المعلمات المعدلة هي كما يلي:
-XMS512M: اضبط الحد الأدنى لقيمة المكدس على 512 متر
-xmn192m: اضبط حجم الجيل الأصغر على 192 مترًا
-xx: permsize = 192m: اضبط القيمة الأولية للجيل الثابت إلى 192 مترًا
-xx: maxpermsize = 192m
-xx: محفوظة CodeCachesize = 64m
-xx:+printgctimestamps
-xx:+printgcdetails
-xloggc: myeclipsegc.log
-فيربوز: GC
أعد تشغيل myeclipse مرة واحدة لعرض معلومات السجل:
استغرق بدء التشغيل حوالي 12 ثانية. من السجل ، يمكن ملاحظة أنه تم تنفيذ 5 GCs فقط في أول 10 ثوان ، ولم يتم إشراك أي تعديلات على حجم كل منطقة. هذه النتيجة مقبولة لأنها لا تتطلب إعادة تشغيل متكررة أثناء العمل.
تحسين سرعة استجابة العمل:
بعد ذلك ، درست التأخير المتكرر ومشاكل البطاقة الكبيرة عند تبديل ملفات HTML ذهابًا وإيابًا والتي أزعجتني لفترة طويلة. من أجل دراسة المزيد من التغييرات في ذاكرة JVM ، قررت استخدام JConsole ، وهي أداة مساعد تأتي مع Java. استعد أولاً معلمات myeclipse.ini لتجنب التداخل من المرحلة الأولى من التحسين.
ابدأ myeclipse ، ابدأ jconsole واتصل بـ JVM حيث يوجد myeclipse. مخطط الذاكرة للكومة بأكملها بعد الاستقرار هو كما يلي:
حاول بعد ذلك فتح بعض القوالب ثم مراقبة تغييرات الذاكرة.
بادئ ذي بدء ، الاستخدام العام لذاكرة الكومة:
يمكن ملاحظة أنه بعد فتح العديد من القوالب ، زاد استخدام ذاكرة الكومة فجأة من الأصلي أقل من 100 متر إلى أكثر من 300 متر. تضاعف الاستخدام ثلاث مرات ، لكنه لا يزال ضمن نطاق 512 متر الذي حددته. لذلك ، يمكنك عدم التفكير مؤقتًا في الاستمرار في زيادة ذاكرة الكومة ، ولكن بدلاً من ذلك ، فكر في ضبط نسبة حجم الذاكرة في كل منطقة.
لذلك نلاحظ استخدام ذاكرة كل منطقة خلال هذه الفترة ، من بينها منطقة عدن كما يلي:
زاد معدل استخدام الذاكرة في منطقة عدن بشكل كبير خلال هذه الفترة ، وحدث GC عدة مرات. من خلال معلومات المراقبة أدناه ، يمكننا أن نعرف أنه افتراضيًا ، تخصص منطقة عدن 31 مترًا فقط من الحد الأقصى للذاكرة ، والتي من الواضح أنها ليست كافية. إن تنفيذ نقطة صغيرة سيؤدي إلى قيام GC في منطقة عدن. يجب أن يكون هذا أحد أسباب تأخر التأخير في مفتاح فتح القالب ويجب ضبطه.
التالي هو المنطقة المدفوعة:
الحد الأقصى للمساحة المخصصة من قبل JVM لهذه المنطقة بشكل افتراضي هو 470M. مع تغير استخدام الذاكرة ، يتم تعديل الحجم الفعلي لهذه المنطقة باستمرار. سيحدث GC الكامل في كل مرة يتم فيها ضبط حجم المنطقة ، والتي يجب أن تكون أحد أسباب الكتل الكبيرة المتكررة. إن فتح القالب الجديد هو السبب الرئيسي لإثارة هذا التعديل. من وجهة نظر استخدام الذاكرة في هذا المجال ، لا يزال من الضروري الحفاظ على قدر معين من التكرار من خلال الحفاظ على مساحة الذاكرة وإصلاحها في هذه المنطقة بحوالي 450 مترًا.
من وجهة النظر هذه ، لا يزال من الضروري توسيع ذاكرة الكومة لـ JVM للحفاظ على مساحة أكبر ومنطقة عدن.
أخيرًا ، دعونا نلقي نظرة على منطقة بيرم:
كجزء من منطقة الأسلوب ، تتغير الذاكرة في هذا المجال ليست كبيرة ومستقرة نسبيًا ، لذلك ليست هناك حاجة لترك الكثير من التكرار. ومع ذلك ، بالنظر إلى أن حجم الكود الفعلي للمشروع الذي تم فتحه حاليًا ليس كبيرًا ، فقد قرر الحفاظ عليه مؤقتًا عند حوالي 128 مترًا وضبطه ببطء في المستقبل.
لذلك وفقًا للتحليل أعلاه ، يتم ضبط المعلمات على:
-xmx768m
-xms768m
-xmn256m
-xx: permsize = 192m
-xx: maxpermsize = 192m
-xx: محفوظة CodeCachesize = 64m
أعد تشغيل myeclipse ، والاتصال بـ JConsole ، وفتح ثلاثين قالبًا في نفس الوقت لإجراء الاختبار. عند النظر إلى معدل استخدام الذاكرة لكل منطقة ، وجدت مشكلة. بعد ضبط الجيل الشاب إلى 256 مترًا ، نظرًا لأن عدن لم يعد يحدث بشكل متكرر في GC ، يتم تقليل كمية البيانات التي تدخل المنطقة التي تم إجراؤها بشكل كبير. مخطط استخدام الذاكرة للمنطقة المستقلة كما يلي:
كما هو موضح في الشكل أعلاه ، عندما يتم فتح العديد من القوالب عمداً ، فإن المساحة 450M+ تستخدم فقط أقل من 250 مترًا ، ومعدل استخدام المساحة منخفض للغاية ، لذلك يجب إجراء التعديلات.
لخص
ما سبق هو بعض الأفكار وعملية ضبط فعلية بالنسبة لي لضبط myeclipse الخاص بي. في الاستخدام الفعلي ، قمت ببعض التعديلات والتخصيصات وفقًا لتفضيلاتي. المعلمات النهائية لـ myeclipse.ini هي كما يلي:
-vmargs
-xmx512m
-xms512m
-xmn192m
-xx: permsize = 128m
-xx: maxpermsize = 128m
-xx: محفوظة CodeCachesize = 64m
بموجب هذا إعداد المعلمة ، تكون سرعة استجابة Myeclipse مضمونة نسبيًا ، ويتم تقليل تواتر التأخير المتأخرات المختلفة إلى حد كبير. العيب هو أن ذاكرة النظام التي يشغلها المقيم الدائم مرتفع نسبيًا. يمكن للطلاب الذين يرغبون في فتح myeclipse المتعددة في نفس الوقت إجراء تعديلات مناسبة وفقًا لاحتياجاتهم والظروف الفعلية.
ما سبق هو كل شيء عن هذا المقال ، آمل أن يكون مفيدًا لتعلم الجميع.