يدعم JVM الحد الأقصى لعدد الخيوط اختبار بسيط

في الآونة الأخيرة ، إذا كنت ترغب في اختبار الحد الأقصى لعدد التوافق تحت OpenFire ، فأنت بحاجة إلى فتح عدد كبير من المواضيع لمحاكاة العميل. لطالما كنت في حيرة من عدد المواضيع التي يمكن أن تفتحها مثيل JVM ، لذلك أخطط لاختباره وإيجاد العوامل التالية التي تؤثر على عدد المواضيع:

برنامج الاختبار كما يلي: Java Code:

 استيراد java.util.concurrent.atomic.atomicinteger ؛ يمتد TestTreshread من الفئة العامة Thread {private static final atomicinteger count = new AtomicInteger () ؛ public static void main (string [] args) {بينما (صحيح) (جديد testTreThread ()). start () ؛ } Override public void run () {system.out.println (count.incrementandget ()) ؛ بينما (صحيح) حاول {thread.sleep (integer.max_value) ؛ } catch (interruptedException e) {break ؛ }}}

بيئة الاختبار: النظام: Ubuntu 10.04 Linux kernel 2.6 (32 بت)
الذاكرة: 2G
JDK: 1.7

نتائج الاختبار:
Ø لا توجد قيود على النظام

عندما يصل عدد مؤشرات الترابط التي تم إنشاؤها إلى 31،842 ، لا يمكن إنشاء أي مؤشرات ترابط في النظام.

من نتائج الاختبار أعلاه ، يمكن ملاحظة أن زيادة ذاكرة الكومة (-xms ، -xmx) ستقلل من عدد مؤشرات الترابط التي يمكن إنشاؤها ، وزيادة ذاكرة مكدس الخيط (-xss ، فإن الحد الأدنى لقيمة هذه المعلمة في أنظمة 32 بت) ستقلل أيضًا من عدد مؤشرات الترابط التي يمكن إنشاؤها.

Ø جنبا إلى جنب مع قيود النظام

يتم تحديد الحد من عدد المواضيع 31842 من خلال الحد الأقصى لعدد مؤشرات الترابط التي يمكن للنظام توليدها:/proc/sys/kernel/threads-max ، ولكن قيمتها الافتراضية هي 32080. تعديل قيمته إلى 10000: echo 10000>/proc/sys/kernel/threads-max ، ونتائج الاختبار المعدلة هي متابعة:

في هذه الحالة ، هل يعني ذلك أنه يمكن تكوين أكبر عدد ممكن من مؤشرات الترابط؟ قم بإجراء تعديل آخر: Echo 1000000>/proc/sys/kernel/threads-max ، فإن نتائج الاختبار المعدلة هي كما يلي:

لقد وجد أن عدد مؤشرات الترابط لن يزداد بعد الوصول إلى 32279. بعد التحقق ، فإن الحد الأقصى لعدد PIDs الذي يمكن إنشاؤه بواسطة نظام Linux 32 بت هو 32678. يمكن تعديل هذه القيمة من خلال/proc/sys/kernel/pid_max (طريقة التعديل هي نفسها مثل الخيوط) ، ولكن في نظام 32 ، لا يمكن تغيير هذه القيمة إلى أقل. عندما تكون Threads-Max مؤكدة ، تكون نتائج الاختبار لتعديل PID_MAX كما يلي:

يجب أن يكون الموقف على Windows متشابهًا ، ولكن قد يكون عدد مؤشرات الترابط التي يمكن إنشاؤها على Windows أصغر من Linux. الخوادم المستندة إلى نموذج الخيط محدود دائمًا بعدد المواضيع.

يتأثر العدد الأقصى الذي يمكن إنشاؤه في JVM بحجم ذاكرة الكومة لـ JVM ، وحجم ذاكرة المكدس للمعلومات ، والحد الأقصى لعدد مؤشرات الترابط التي يمكن أن ينشئها النظام (تنفيذ مؤشرات ترابط Java تحت linux). يمكن تقدير المبلغ المحدد بناءً على الحد الأقصى للذاكرة التي يمكن أن تصل إليها عملية Java (عمومًا 2G على أنظمة 32 بت) ، وذاكرة كومة ، وذاكرة مكدس الخيط.

تسلسل:

تم اختباره على نظام Linux 64 بت (CentOS6 ، 3G Memory) ، وجدت أن هناك معلمة أخرى تحد من عدد مؤشرات الترابط: MaxuserProcess (يمكن عرضها من خلال Ulimita ، والقيمة الافتراضية هي 1024 ، ويمكن تعديل هذه القيمة من خلال Ulimitu). هذه القيمة ليست محدودة في بيئة اختبار Ubuntu 32 بت أعلاه.

تعديل Threads -Max و Pid_Max و MaxUserProcess ، جميع المعلمات الثلاثة إلى 100000 ، -xms ، -xmx أصغر قدر الإمكان (128 مترًا ، 64 مترًا) ، و -XSS صغيرة قدر الإمكان (104k في 64 بت ، يمكن أن تكون القيمة 128k). المتوقع مقدمًا في بيئة الاختبار هذه ، لن يقتصر عدد مؤشرات الترابط إلا على حجم الذاكرة (3G) لبيئة الاختبار. ومع ذلك ، فإن نتيجة الاختبار الفعلية هي أنه عندما يصل عدد مؤشرات الترابط إلى 32 كيلو (32768 ، فإن الحد الأقصى لعدد المنشأ هو حوالي 33000) ، فإن JVM يرمي تحذيرًا: فشل محاولات alcateStackGuardages ، ثم لا يمكن لخطوط أوف موموريرور إنشاء موضوع محلي. بعد التحقق من الذاكرة ، وجدت أنه لا يزال هناك الكثير من وقت الفراغ ، لذلك لا ينبغي أن يكون بسبب سعة الذاكرة. تحذير Google غير مثمر. لا أعرف لماذا ، ويحتاج إلى مزيد من البحث.

الخطوة 2:

اكتشفت عن طريق الخطأ المقال [7] اليوم وحاولته على الفور. من المؤكد أن هذا العامل سيؤثر على عدد إبداعات الخيط. وفقًا للوصف في المقالة ، يتضاعف عدد/proc/sys/vm/max_map_count ، من 65536 إلى 131072. وقد وصل إجمالي عدد المواضيع التي تم إنشاؤها إلى 65000+. يجب أن يكون الكمبيوتر عالقًا (ذاكرة 3G) ... لقد قمت بفحص وظيفة هذه المعلمة بإيجاز ، والوصف في [8] كما يلي:

"يحتوي هذا الملف على الحد الأقصى لعدد MemoryMapareAsprocessMayhave.MemoryMapareasareusedAseDaside-Effect CallingMalloc ، مباشرة bymmapandmprotect ، Andalso عند تحميل المكتبات المشتركة.

على الرغم من أن معظم التطبيقات ضرورية أقل من تلك الموجودة في الخرائط ، إلا أن بعض البرامج ، وخاصة Mallocdebuggers ، قد تستهلك ASS ، على سبيل المثال ، UptoOnOtwomAppSperAllocation.

thedefaultvalueis65536. "

حسنًا ، تم حل هذه المشكلة أخيرًا تمامًا. أخيرًا ، يتم تلخيص العوامل التي تؤثر على عدد خيوط Java:

الجهاز الافتراضي Java نفسه: -xms ، -xmx ، -xss ؛

قيود النظام:

/proc/sys/kernel/pid_max ،

/proc/sys/kernel/thread-max ،

max_user_process (ulimit-u) ،

/proc/sys/vm/max_map_count.

لخص

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