Tomcat على خادم الإنتاج ، بيرجن وإعادة النشر

Question

يبدو

 MemoryError: PermGen space
 java.lang.OutOfMemoryError: PermGen space

هي مشكلة شائعة. يمكنك زيادة حجم مساحة PEM الخاصة بك ، ولكن بعد 100 أو 200 إعادة نشر سيكون ممتلئًا. من المستحيل تقريبًا تتبع تسرب ذاكرة Classloader.

ما هي طرقك لـ Tomcat (أو حاوية Servlet بسيطة أخرى - رصيف؟) على خادم الإنتاج؟ هل إعادة تشغيل الخادم بعد كل حل؟

هل تستخدم Tomcat واحد للعديد من التطبيقات؟

ربما يجب أن أستخدم العديد من الخوادم الرصيف على منافذ مختلفة (أو رصيفًا مضمنًا) وأن أقوم بإعادة التشغيل/إعادة التشغيل/النشر في كل مرة؟

Answer 1

لقد تخليت عن استخدام مدير Tomcat والآن أغلقت دائمًا Tomcat لإعادة النشر.

نقوم بتشغيل اثنين من tomcats على نفس الخادم ونستخدم Apache Webserver مع mod_proxy_ajp حتى يتمكن المستخدمون من الوصول إلى كلا التطبيقات عبر نفس المنفذ 80. هذا لطيف أيضًا لأن المستخدمين يرون صفحة Apache غير متوفرة عند انخفاض tomcat.

Answer 2

يمكنك محاولة إضافة خيارات Java هذه:

-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled

يتيح ذلك جمع القمامة في مساحة بيرجن (إيقاف افتراضيًا) ويسمح لجامعة GC بتفريغ فئات. بالإضافة إلى ذلك ، يجب عليك استخدام -xx: permsize = 64m -xx: maxpermsize = 128m المذكورة في مكان آخر لزيادة كمية البيرجين المتاحة.

Answer 3

نعم بالفعل ، هذه مشكلة. نقوم بتشغيل ثلاثة تطبيقات ويب على خادم Tomcat: رقم 1 يستخدم إطار تطبيق ويب ، و hibernate والعديد من الجرار الأخرى ، لا. 2 يستخدم السبات وبعض الجرار وليس. 3 هو في الأساس تطبيق JSP بسيط للغاية.

عندما ننشر لا. 1 ، نحن دائما نعيد تشغيل tomcat. وإلا فإن خطأ Permgen Space سوف يعضنا قريبًا. يمكن في بعض الأحيان نشر رقم 2 دون مشكلة ، ولكن لأنه في كثير من الأحيان يتغير عندما لا. 1 يفعل كذلك ، يتم جدولة إعادة التشغيل على أي حال. رقم 3 لا يمثل أي مشكلة على الإطلاق ويمكن نشره كلما احتاجت دون أي مشكلة.

لذا ، نعم ، عادة ما نعيد تشغيل Tomcat. لكننا نتطلع أيضًا إلى Tomcat 7 ، الذي من المفترض أن يتعامل مع العديد من مشكلات اللودر في الذاكرة / الفئة التي يتم ترحيلها في الجرار والأطر المختلفة.

Answer 4

يتحول بيرجين في نقطة ساخنة فقط تأخير المشكلة ، وفي النهاية ستحصل على OutofMemoryError على أي حال.

لقد واجهنا هذه المشكلة لفترة طويلة ، والحل الوحيد الذي وجدته حتى الآن هو استخدام JRockit بدلاً من ذلك. لا يحتوي على بيرجن ، وبالتالي فإن المشكلة تختفي فقط. نحن نقوم بتقييمها على خوادم الاختبار الخاصة بنا الآن ، ولم نواجه مشكلة واحدة منذ التبديل. لقد حاولت أيضًا إعادة نشر أكثر من 20 مرة على الجهاز المحلي الخاص بي مع تطبيق يحصل على هذا الخطأ في إعادة النشر الأولى ، وكل شيء يتقدم بشكل جميل.

من المفترض أن يتم دمج JRockit في OpenJDK ، لذلك ربما ستزول هذه المشكلة بالنسبة إلى مخزون Java أيضًا في المستقبل.

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

وهو مجاني ، تحت نفس ترخيص الساخنة:

https://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and

Answer 5

يجب عليك تمكين مجموعة Permgen Garbage. بشكل افتراضي ، لا تقوم النقطة الساخنة VM بجمع Garbage Permgen ، مما يعني أن جميع ملفات الفئة المحملة تبقى في الذاكرة إلى الأبد. يقوم كل نشر جديد بتحميل مجموعة جديدة من ملفات الفصل مما يعني أنك تنفد في النهاية من مساحة بيرجن.

Answer 6

ما هو إصدار Tomcat الذي تستخدمه؟ لدى Tomcat 7 و 6.0.30 الميزات العديدة لتجنب هذه التسريبات ، أو على الأقل يحذرك من قضيتهم.

هذا العرض بقلم مارك توماس من Springsource (و Complate Tomcat منذ فترة طويلة) حول هذا الموضوع مثيرة للاهتمام للغاية.

Answer 7

فقط من المرجع ، هناك نسخة جديدة من بلومبر أداة ، يمكنها مراقبة واكتشاف تسربات التوليد الدائمة كذلك.