المقايضة السريعة لخيارات Java -Xms و-Xmx

Question

نظرا لهذين الأمرين

أ:

$ java -Xms10G -Xmx10G myjavacode input.txt

ب:

$ java -Xms5G -Xmx5G myjavacode input.txt

لدي سؤالان:

1. بما أن الأمر A يحتفظ بذاكرة أكبر بمعلماته، فهل سيعمل A بشكل أسرع من B؟
2. كيف -Xmx و -Xms هل تؤثر على عملية التشغيل ومخرجات برنامجي؟

Answer 1

يعتمد ذلك على GC الذي تستخدمه Java لديك.قد تعمل أجهزة GC المتوازية بشكل أفضل على إعدادات الذاكرة الأكبر حجمًا - رغم أنني لست خبيرًا في ذلك.

بشكل عام، إذا كانت لديك ذاكرة أكبر، قل تكرار الحاجة إلى الحصول على GC-ed - فهناك مساحة كبيرة للقمامة.ومع ذلك، عندما يتعلق الأمر بـ GC، يجب أن يعمل GC على المزيد من الذاكرة - والتي بدورها قد تكون أبطأ.

Answer 2

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

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

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

Answer 3

لقد وجدت أنه في بعض الحالات يمكن أن يؤدي وجود مساحة كبيرة جدًا من الذاكرة إلى إبطاء البرنامج.

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

كان الحل هو إخراج الكائنات القديمة من الجلسة.

ستيوارت

Answer 4

1. يعتمد التخصيص دائمًا على نظام التشغيل لديك.إذا قمت بتخصيص قدر كبير جدًا من الذاكرة، فقد ينتهي بك الأمر إلى تحميل أجزاء في المبادلة، وهو أمر بطيء بالفعل.
2. يعتمد ما إذا كان برنامجك يعمل بشكل أبطأ أو أسرع على المراجع التي يجب على VM التعامل معها وتنظيفها.لا يتعين على GC مسح الذاكرة المخصصة للعثور على الكائنات المهجورة.إنه يعرف كائناته ومقدار الذاكرة التي يخصصها من خلال التعيين المرجعي.لذا فإن الكنس يعتمد فقط على حجم الأشياء الخاصة بك.إذا كان برنامجك يتصرف بنفس الطريقة في كلتا الحالتين، فيجب أن يكون تأثير الأداء الوحيد عند بدء تشغيل VM، عندما يحاول VM تخصيص الذاكرة التي يوفرها نظام التشغيل الخاص بك وإذا كنت تستخدم المبادلة (مما يؤدي مرة أخرى إلى 1.)

Answer 5

من الصعب أن نقول كيف سيؤثر تخصيص الذاكرة على سرعتك.يعتمد ذلك على خوارزمية جمع البيانات المهملة التي يستخدمها JVM.على سبيل المثال، إذا كان مجمع البيانات المهملة الخاص بك يحتاج إلى التوقف مؤقتًا للقيام بتجميع كامل، فإذا كان لديك 10 ذاكرة إضافية عما تحتاجه بالفعل، فسيكون لدى المجمع 10 بيانات غير مرغوب فيها لتنظيفها.

إذا كنت تستخدم Java 6، فيمكنك استخدام jconsole (في دليل bin الخاص بـ jdk) لإرفاق العملية الخاصة بك ومراقبة كيفية تصرف المجمع.بشكل عام، يكون المجمعون أذكياء للغاية ولن تحتاج إلى إجراء أي ضبط، ولكن إذا كانت لديك حاجة، فهناك العديد من الخيارات التي يمكنك استخدامها لضبط عملية التجميع بشكل أكبر.

Answer 6

> C:\java -X

-Xmixed           mixed mode execution (default)
-Xint             interpreted mode execution only
-Xbootclasspath:<directories and zip/jar files separated by ;>
                  set search path for bootstrap classes and resources
-Xbootclasspath/a:<directories and zip/jar files separated by ;>
                  append to end of bootstrap class path
-Xbootclasspath/p:<directories and zip/jar files separated by ;>
                  prepend in front of bootstrap class path
-Xnoclassgc       disable class garbage collection
-Xincgc           enable incremental garbage collection
-Xloggc:<file>    log GC status to a file with time stamps
-Xbatch           disable background compilation
-Xms<size>        set initial Java heap size
-Xmx<size>        set maximum Java heap size
-Xss<size>        set java thread stack size
-Xprof            output cpu profiling data
-Xfuture          enable strictest checks, anticipating future default
-Xrs              reduce use of OS signals by Java/VM (see documentation)
-Xcheck:jni       perform additional checks for JNI functions
-Xshare:off       do not attempt to use shared class data
-Xshare:auto      use shared class data if possible (default)
-Xshare:on        require using shared class data, otherwise fail.

ال -X الخيارات غير قياسية وقابلة للتغيير دون إشعار.

(نسخ ولصق)

Answer 7

كان هذا هو السؤال الذي طرحته دائمًا عندما كنت أعمل على أحد تطبيقاتي والذي أدى إلى إنشاء عدد هائل من سلاسل الرسائل لكل طلب.

إذن هذا سؤال جيد حقًا، وهناك جانبان لهذا السؤال:
1.ما إذا كان يجب أن تكون قيمة Xms وXmx هي نفسها أم لا
- تشير معظم مواقع الويب وحتى مستندات Oracle إلى أن الأمر نفسه.ومع ذلك، أقترح أن يكون هناك حوالي 10-20% من المخزن المؤقت بين تلك القيم لإعطاء خيار تغيير حجم الكومة لتطبيقك في حالة حدوث ارتفاع مفاجئ في حركة المرور أو تسرب عرضي للذاكرة.

2.ما إذا كان يجب أن أبدأ تطبيقي بحجم كومة أقل
- إذن هذا هو الأمر - بغض النظر عن GC Algo الذي تستخدمه (حتى G1)، فإن الكومة الكبيرة تحتوي دائمًا على بعض المقايضة.الهدف هو تحديد سلوك تطبيقك بالنسبة لحجم الكومة الذي يمكنك السماح لـ GC الخاص بك بإيقافه مؤقتًا من حيث زمن الوصول والإنتاجية.
- على سبيل المثال، إذا كان التطبيق الخاص بك يحتوي على الكثير من سلاسل الرسائل (يحتوي كل مؤشر ترابط على مكدس سعة 1 ميجابايت في الذاكرة الأصلية وليس في الكومة) ولكنه لا يشغل مساحة كائن كبيرة، فأنا أقترح أن يكون لديك قيمة أقل لـ Xms.
- إذا قام تطبيقك بإنشاء الكثير من الكائنات مع عدد متزايد من سلاسل الرسائل، فحدد قيمة Xms التي يمكنك تعيينها لتحمل توقفات STW هذه.وهذا يعني تحديد الحد الأقصى لوقت الاستجابة لطلباتك الواردة التي يمكنك تحملها وضبط الحد الأدنى لحجم الكومة.