Java-buildpack: डिफ़ॉल्ट कॉन्फ़िगरेशन और <512M . के साथ स्प्रिंग बूट एप्लिकेशन चलाना असंभव है

मेमोरी कैलकुलेटर को कॉन्फ़िगर करके 512M से कम के साथ चलाना संभव है।
मेरे लिए निम्नलिखित मेनिफेस्ट काम करता है (स्प्रिंग बूट + वेबफ्लक्स)।

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.+}]'

एक वेनिला वेबफ्लक्स ऐप वास्तव में केवल 60 एमबी रैम के साथ चलता है।

मैं मेमोरी कैलकुलेटर का बहुत बड़ा प्रशंसक हूं क्योंकि अधिकांश डेवलपर्स केवल ढेर के आकार की परवाह करते हैं और एक अप्रत्याशित OOME (जैसे मेटास्पेस) प्राप्त करते हैं, लेकिन मैं मानता हूं कि हम इसे सुधार सकते हैं।
कैलकुलेटर में डिफ़ॉल्ट थ्रेड आकार (300?) कम से कम वेबफ्लक्स के लिए बहुत बड़ा होगा।

शुरुआती लोगों के लिए, स्मृति आकार को अनुकूलित करने का तरीका खोजना बहुत कठिन है।
रीडमे में यूज़केस द्वारा कॉन्फ़िगरेशन उदाहरण बहुत मददगार होंगे।

@ मेकिंग मैंने इस मुद्दे के शीर्षक को और अधिक स्पष्ट करने के लिए अद्यतन किया है कि यह डिफ़ॉल्ट कॉन्फ़िगरेशन (कम से कम) बूट अनुप्रयोगों के लिए उप-इष्टतम होने के बारे में है। 256M और कस्टम कॉन्फ़िगरेशन के साथ बूट एप्लिकेशन चलाना पूरी तरह से संभव है, लेकिन डिफ़ॉल्ट मेमोरी कॉन्फ़िगरेशन मुझे सटीक से बहुत दूर लगता है और यहीं मैं चाहता हूं कि हम कुछ प्रगति करें, क्योंकि यह बहुत सारे उपयोगकर्ताओं को प्रभावित करता है।

WebFlux एप्लिकेशन के लिए आपके द्वारा उल्लिखित थ्रेड्स की संख्या वास्तव में एक बहुत ही दिलचस्प बिंदु है, बिल्ड पैक यह पता लगाकर अतिरिक्त अतिरिक्त मूल्य प्रदान कर सकता है कि यह किस प्रकार का ऐप है। यह मुश्किल हो सकता है क्योंकि कुछ एमवीसी अनुप्रयोग प्रतिक्रियाशील WebClient उपयोग कर सकते हैं, लेकिन मुझे यकीन है कि हम कुछ और चालाक और सटीक कर सकते हैं।

आपका कस्टम मेमोरी कॉन्फ़िगरेशन IMO को हाइलाइट करता है कि स्वचालित कॉन्फ़िगरेशन तंत्र में कुछ गड़बड़ है। जैसा कि https://github.com/cloudfoundry/java-buildpack-memory-calculator/issues/24 में बताया गया है, अगर मैं स्पष्ट रूप से बूट ऐप्स द्वारा प्रभावी रूप से उपयोग की जाने वाली कक्षाओं की संख्या (8000 और 10000 के बीच) निर्दिष्ट करता हूं, तो उत्पन्न पैरामीटर -XX:ReservedCodeCacheSize=240M , जहां आप -XX:ReservedCodeCacheSize=32M निर्दिष्ट करते हैं। यह अंतर वास्तव में बहुत बड़ा है, क्या हम अधिक शिक्षित अनुमान लगा सकते हैं?

इसके अलावा 8000 या 10000 बूट ऐप्स द्वारा प्रभावी ढंग से उपयोग किए जाने वाले वर्गीकृत की संख्या हैं। यदि बिल्ड पैक यह गणना कर रहा है कि ऐप + निर्भरता में कक्षाओं की संख्या से, मुझे लगता है कि मेमोरी कैलकुलेटर के लिए निर्दिष्ट कक्षाओं की संख्या कृत्रिम रूप से अधिक होगी (मुझे अभी भी वर्तमान में अनुमानित मूल्य की जांच करने की आवश्यकता है लेकिन बिल्ड पैक) स्प्रिंग फ्रेमवर्क जार की प्रकृति के कारण।

मैं यह भी सोच रहा हूं कि क्या हम नवीनतम जावा 8 और जावा 11 में उपलब्ध नए कंटेनर मेमोरी विकल्पों का लाभ उठाते हैं। वे डॉकर के लिए डिज़ाइन किए गए हैं लेकिन मुझे लगता है कि हम क्लाउड फाउंड्री में भी इसका लाभ उठा सकते हैं। क्या जावा रनटाइम इस बात से अवगत है कि सीएफ डॉकर का उपयोग नहीं करने के बावजूद हम कंटेनरों में चल रहे हैं? क्या हम -XX:InitialRAMPercentage , -XX:MaxRAMPercentage या -XX:MinRAMPercentage जैसे विकल्पों का लाभ उठाते हैं?

यह एक मुश्किल समस्या है @sdeleuze। क्या जावा-बिल्डपैक जावा डिफ़ॉल्ट का उपयोग करता है, कि हम मानते हैं कि कुछ विचार जावा सेटिंग में चले गए, अनुप्रयोगों को डिफ़ॉल्ट रूप से कार्य करने की इजाजत देता है, जैसे वे सीएफ में नहीं चलते हैं? या जावा-बिल्डपैक प्रारंभिक अनुभव को बेहतर बनाने के लिए डिफ़ॉल्ट रूप से बदलता है लेकिन फिर उपयोगकर्ताओं को उत्तरों की तलाश में छोड़ देता है जब एप्लिकेशन सीएफ में अपेक्षित रूप से नहीं चलता है?

आज जावा-बिल्डपैक ने जावा और टॉमकैट डिफॉल्ट्स का उपयोग करना चुना है जो आज एक विशिष्ट एप्लिकेशन के रूप में उन मूल्यों पर भरोसा करते हैं। मैं व्यक्तिगत रूप से उस दृष्टिकोण को जावा डिफॉल्ट्स को बदलने से अधिक पसंद करता हूं जो एप्लिकेशन को उन तरीकों से प्रभावित कर सकता है जो उपयोगकर्ता के लिए बहुत दृश्यमान/स्पष्ट नहीं हैं।

जहां तक ​​​​नई संपत्तियों की बात है, RAMPercentage गुणों के बारे में मेरी समझ यह है कि वे उपलब्ध राम के प्रतिशत के आधार पर स्वचालित रूप से ढेर मान सेट करते हैं। कोड कैश आकार, थ्रेड स्टैक आकार, मेटास्पेस, जीसी मेमोरी ओवरहेड इत्यादि जैसी गैर ढेर मेमोरी आवश्यकताओं के लिए कोई विचार नहीं है। उपयोगकर्ता के लिए यह अनुमान लगाने के लिए कि उनके आवेदन को कितनी गैर ढेर मेमोरी की आवश्यकता है, यह काम अभी भी एक अभ्यास के रूप में छोड़ दिया गया है। मैं एक ऐसे दिन की प्रतीक्षा कर रहा हूं जब जावा एक कंटेनर की मेमोरी बाधाओं के भीतर एक एप्लिकेशन को रखने के लिए सभी मेमोरी पूल को ठीक से प्रबंधित कर सके। लेकिन मुझे संदेह है कि हम अभी भी इससे बहुत दूर हैं।

एक साइड नोट के रूप में यह JAVA_OPTS और jre कॉन्फ़िगरेशन है जिसे मैंने अपने अनुप्रयोगों के लिए सेट किया है जिसे मुझे कम मेमोरी के साथ स्थिर रहने की आवश्यकता है और गति एक कारक नहीं है।

• मैंने MaxMetaSize को प्रोफाइलिंग के माध्यम से खोजे गए पर सेट किया है।
  जावा_ओपीटीएस

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

जेआरई विन्यास

  stack_threads: 20