Java-buildpack: من المستحيل تشغيل تطبيقات Spring Boot ذات التكوين الافتراضي و <512M

من الممكن أن تعمل بأقل من 512 ميجا عن طريق تكوين حاسبة الذاكرة.
البيان التالي يعمل بالنسبة لي (التمهيد الربيعي + webflux).

applications:
- name: myapp
  path: target/myapp-0.0.1-SNAPSHOT.jar
  memory: 256m
  env:
    JAVA_OPTS: '-XX:ReservedCodeCacheSize=32M -XX:MaxDirectMemorySize=32M'
    JBP_CONFIG_OPEN_JDK_JRE: '[memory_calculator: {stack_threads: 30}, jre: {version: 11.+}]'

يعمل تطبيق vanilla webflux فعليًا

أنا من أشد المعجبين بآلة حاسبة الذاكرة نظرًا لأن معظم المطورين يهتمون فقط بحجم الكومة والحصول على OOME غير متوقع (مثل Metaspace) لكنني أوافق على أنه يمكننا تحسينه.
سيكون حجم الخيط الافتراضي (300؟) في الآلة الحاسبة كبيرًا جدًا بالنسبة لـ webflux على الأقل.

بالنسبة للمبتدئين ، من الصعب جدًا إيجاد طريقة لتخصيص حجم الذاكرة.
أمثلة التكوين حسب حالة الاستخدام في README ستكون مفيدة للغاية.

making لقد قمت بتحديث عنوان هذه المشكلة

عدد المواضيع التي ذكرتها لتطبيق WebFlux هو بالفعل نقطة مثيرة للاهتمام للغاية ، يمكن أن توفر حزمة البناء قيمة إضافية من خلال اكتشاف نوع التطبيق. قد يكون الأمر صعبًا نظرًا لأن بعض تطبيقات MVC يمكنها استخدام Reactive WebClient ، لكنني متأكد من أنه يمكننا القيام بشيء أكثر ذكاءً ودقة.

يبرز تكوين الذاكرة المخصصة الخاص بك IMO أن هناك خطأ ما في آلية التكوين التلقائي. كما هو موضح في https://github.com/cloudfoundry/java-buildpack-memory-calculator/issues/24 ، إذا قمت بتحديد عدد الفئات (بين 8000 و 10000) بشكل فعال بواسطة تطبيقات التمهيد ، فإن المعلمة التي تم إنشاؤها هي -XX:ReservedCodeCacheSize=240M ، حيث تحدد -XX:ReservedCodeCacheSize=32M . هذا الاختلاف ضخم حقًا ، فهل يمكننا تخمين أكثر تعليماً؟

أيضًا 8000 أو 10000 عبارة عن عدد من المصنفات المستخدمة بشكل فعال بواسطة تطبيقات التمهيد. إذا كانت حزمة الإنشاء تحسب ذلك من عدد الفئات في التطبيق + التبعيات ، فأنا أميل إلى الاعتقاد بأن عدد الفئات المحددة لآلة حاسبة الذاكرة سيكون مرتفعًا بشكل مصطنع (ما زلت بحاجة إلى التحقق من القيمة التي تم تخمينها حاليًا ولكن حزمة الإنشاء) نظرًا لطبيعة JAR إطار الربيع.

أتساءل أيضًا عما إذا كنا نستفيد من خيارات ذاكرة الحاوية الجديدة المتوفرة في أحدث إصدار من Java 8 و Java 11. وهي مصممة لـ Docker ولكن أعتقد أنه يمكننا الاستفادة أيضًا من هذا في Cloud Foundry. هل Java runtime على علم بأننا نعمل في حاويات على الرغم من عدم استخدام CF لـ Docker؟ هل نستفيد من خيارات مثل -XX:InitialRAMPercentage أو -XX:MaxRAMPercentage أو -XX:MinRAMPercentage ؟

إنها مشكلة صعبةsdeleuze. هل تستخدم java-buildpack الإعدادات الافتراضية لـ java ، التي نفترض أن بعض الأفكار قد تم إجراؤها في إعداد java ، مما يسمح للتطبيقات بالعمل ، افتراضيًا ، مثلما تفعل عندما لا تعمل في CF؟ أو هل يغير java-buildpack الإعدادات الافتراضية لجعل التجربة الأولية أفضل ولكن بعد ذلك يترك المستخدمين يبحثون عن إجابات عندما لا يعمل التطبيق كما هو متوقع وليس في CF؟

اليوم ، اختارت java-buildpack استخدام إعدادات Java و tomcat الافتراضية التي تثق في هذه القيم كتطبيق نموذجي اليوم. أنا شخصياً أحب هذا النهج أكثر من تغيير الإعدادات الافتراضية لجافا التي قد تؤثر على التطبيق بطرق غير مرئية / واضحة جدًا للمستخدم.

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

كملاحظة جانبية ، هذا هو تكوين JAVA_OPTS و jre الذي قمت بتعيينه لتطبيقاتي التي أحتاج إلى أن تكون مستقرة مع ذاكرة منخفضة والسرعة ليست عاملاً.

• قمت بتعيين MaxMetaSize على اكتشاف من خلال التنميط.
  JAVA_OPTS

-Xss256K -Xms1M -XX:+UseSerialGC -Djava.compiler=none -XX:ReservedCodeCacheSize=2496k -XX:MaxDirectMemorySize=1M

تكوين jre

  stack_threads: 20