PaaS में वर्टिकल स्केलिंग के बारे में पूरी सच्चाई और साझा होस्टिंग के लिए आप ओवरपे क्यों करते हैं

जैसा कि आप जानते हैं, एप्लिकेशन हमेशा समान मात्रा में संसाधनों का उपयोग नहीं करता है, लेकिन स्वचालित ऊर्ध्वाधर स्केलिंग फ़ंक्शन के लिए धन्यवाद, जेलेस्टिक में एप्लिकेशन परिवर्तनों के लिए कंटेनर का आकार। तदनुसार, उपयोगकर्ता को आरक्षित संसाधनों के लिए ओवरपे करने की आवश्यकता नहीं है जो उपयोग नहीं किए जाते हैं, जैसा कि अन्य पासा के साथ होता है। वास्तव में, पूरे होस्टिंग उद्योग का व्यवसाय मॉडल और पीएएएस समाधानों की पुरानी पीढ़ी "ओवरसेलिंग" पर आधारित है। इस प्रकार, संसाधनों की वास्तविक खपत के लिए उचित भुगतान का महत्व स्पष्ट है।

यह स्पष्ट है कि उस समय जब JVM विकसित हो रहा था, कोई भी बादलों या वर्चुअलाइजेशन के बारे में नहीं जानता था, और इसके अलावा, कोई भी PaaS में घनत्व के बारे में नहीं सोचता था। आज, वर्चुअलाइजेशन ने होस्टिंग उद्योग में खेल को बदल दिया है, और यह क्रांति जारी रहेगी। अब हम संसाधनों का अधिक कुशलता से उपयोग कर सकते हैं। ओरेकल में जेवीएम के मुख्य वास्तुकारों में से एक, माइकल विडस्टेंड ने पुष्टि की है कि जेवीएम को पैस के लिए बिल्कुल भी डिज़ाइन नहीं किया गया है, लेकिन ओरेकल इसे बदलने की पूरी कोशिश कर रहा है। इसके अलावा, आईबीएम के लोग उसी दिशा में आगे बढ़ रहे हैं। JVM डायनामिक व्यवहार पर कुछ नोट्स IBM JavaOne कीनोट 2012 हाइलाइट्स में पाए जा सकते हैं।

ईमानदारी से, कई तकनीकी सीमाओं के कारण ऊर्ध्वाधर स्केलिंग का "आविष्कार" करना आसान नहीं था। इन सीमाओं में से एक का सीधा संबंध जेवीएम से है। इस लेख में, हम कुछ जानकारी साझा करना चाहेंगे जो वर्टिकल स्केलिंग और उपरोक्त सीमाओं को समझने के लिए उपयोगी हो सकती हैं।

शुरू करने के लिए, हमने एक एप्लिकेशन बनाया जो स्वयं संसाधनों की खपत को नियंत्रित करता था और एपीआई के माध्यम से, जब यह ऊपरी सीमा तक पहुंच गया, तो इसने सीमा को बढ़ाने के लिए बुनियादी ढांचे को कमान दी, और इसके विपरीत, जब संसाधनों की आवश्यकता नहीं थी, तो उन्हें वापस लेने की आज्ञा दी। इस तरह के एक एल्गोरिथ्म ने काफी अच्छी तरह से काम किया, लेकिन परीक्षण के दौरान एक और बारीकियों का पता चला: जावा स्केलिंग के साथ बहुत अच्छी तरह से काम नहीं करता है, क्योंकि यह थोड़ी मात्रा में स्मृति के साथ शुरू हो सकता है, फिर आवश्यक होने पर अतिरिक्त संसाधन ले सकता है, लेकिन यह उन्हें ओसी में वापस नहीं करता है । यह विशेष रूप से JVM इंजीनियरों द्वारा डिज़ाइन किया गया है ताकि अगली बार इसकी आवश्यकता होने पर मेमोरी प्राप्त करने की प्रक्रिया को तेज किया जा सके। बेशक, यह हमारे क्लाउड मॉडल के लिए स्वीकार्य नहीं है।

तब हमने प्रयोगों का सिलसिला चलाया कि जावा कैसे व्यवहार करता है, या कचरा बीनने वाले, जैसे: सीरियल, समानांतर, समवर्ती मार्क स्वीप और जी 1।

कचरा संग्रहण कैसे काम करता है

जावा में, नए ऑपरेटर का उपयोग करके वस्तुओं का गतिशील आवंटन प्राप्त किया जाता है। ऑब्जेक्ट, जैसे ही इसे बनाया जाता है, मेमोरी का हिस्सा उपयोग करता है, और मेमोरी तब तक आरक्षित रहती है जब तक कि ऑब्जेक्ट तक कोई पहुंच न हो। मामले में जब ऑब्जेक्ट एक्सेस नहीं किया जाता है, तो यह माना जाता है कि अब इसकी आवश्यकता नहीं है, और इसके द्वारा कब्जा की गई मेमोरी को मुक्त किया जा सकता है। स्वयं ऑब्जेक्ट को नष्ट करने की कोई स्पष्ट आवश्यकता नहीं है, क्योंकि जावा स्वचालित रूप से इसे मेमोरी में स्थानांतरित कर सकता है। कचरा संग्रहण केवल वह विधि है जो इस समस्या को हल करती है। प्रोग्राम जो अनावश्यक मेमोरी क्षेत्रों को समय पर रिलीज नहीं करते हैं, वे मुक्त मेमोरी की मात्रा में अनियंत्रित कमी का कारण बन सकते हैं - तथाकथित "मेमोरी मेमोरी"। जावा में, कचरा संग्रह स्वचालित रूप से पूरे कार्यक्रम के जीवन चक्र में होता है, स्मृति को मुक्त करने की आवश्यकता को समाप्त करता है और इस प्रकार लीक को रोकता है। जावा में कचरा संग्रह के बारे में अधिक जानकारी के लिए, जावा एंटरप्राइज परफॉर्मेंस बुक या Javarevisted ब्लॉग देखें।

सीरियल कचरा कलेक्टर (-XX: + UseSerialGC)

शुरुआत करते हैं सीरियल से। यह सभी कचरा संग्रह करने के लिए एक एकल धागे का उपयोग करता है। यह एकल-प्रोसेसर मशीनों के लिए सबसे उपयुक्त है, कभी-कभी यह मल्टीप्रोसेसर के लिए उपयोगी हो सकता है, जो छोटे डेटा सेट (लगभग 100 एमबी तक) के साथ एप्लिकेशन चलाते हैं।

इस कचरा संग्रहकर्ता ने स्केलिंग के बारे में बहुत अच्छा परिणाम दिखाया। हमें पता चला कि इसमें कॉम्पैक्टीकरण गुण हैं, अर्थात्, हम कह सकते हैं कि यह मेमोरी डीफ़्रैग्मेन्टेशन करता है, और अप्रयुक्त संसाधनों को ओएस पर लौटाता है।
आइए इसे फिर से देखें जेवीएम 6 और जेवीएम 7 पर सीरियल कचरा कलेक्टर का परीक्षण।

जावा 6

अधिक सटीक रूप से, हम जावा संस्करण 1.6.0_27 का परीक्षण करेंगे।

हम विजुअल JavaVM उपयोगिता लॉन्च करते हैं, जो कंप्यूटर पर चलने वाली सभी जावा प्रक्रियाओं की निगरानी करना संभव बनाता है, साथ ही यह निगरानी करता है कि ये प्रक्रियाएं मेमोरी की कितनी खपत करती हैं।

परीक्षण के लिए, हम एक ऐसे प्रोग्राम का उपयोग करेंगे जो डायनामिक रूप से आवंटित करता है और मेमोरी को अनंत लूप में मुक्त करता है:

पब्लिक क्लास मेमोरीलेक {
सार्वजनिक स्थैतिक शून्य मुख्य ( स्ट्रिंग [ ] args ) {
प्रणाली। बाहर । प्रिंट्लन ( "स्टार्ट ...." ) ;
जबकि ( सच्चा ) {
प्रणाली। बाहर । Println ( "अगला लूप ..." ) ;
कोशिश करो {
int count = 1000 * 1024 ;
बाइट [ ] सरणी = नई बाइट [ 1024 * गिनती ] ;

थ्रेड। नींद ( 5000 ) ;
सरणी = अशक्त ;
प्रणाली। जीसी ( ) ;
प्रणाली। जीसी ( ) ;
थ्रेड। नींद ( 5000 ) ;
} कैच ( इंटरप्टेड एक्ससेप्शन पूर्व ) {
}
}
}
}

निम्नलिखित मापदंडों के साथ JVM चलाएं:

-XX: + UseSerialGC -Xmx1024m -Xmn64m -Xms128m -Xminf0.1 -Xmaxf0.3 , जहाँ

-XX: + UseSerialGC - कचरा कलेक्टर सीरियल का उपयोग करें;
-Xmx1024m - रैम का अधिकतम उपयोग - 1024 एमबी;
-Xmn64m - 64 एमबी के बराबर हीप कदम;
-Xms128m - 128 एमबी के बराबर हीप का न्यूनतम मूल्य;
-Xminf0.1 - यह पैरामीटर हीप में न्यूनतम मुक्त स्थान को परिभाषित करता है और कचरा संग्रह के बाद कम से कम 10% मुक्त स्थान नहीं होने पर जेवीएम को इसका विस्तार करने का निर्देश देता है;
-Xmaxf0.3 - यह पैरामीटर निर्धारित करता है कि कितना ढेर विस्तारित है और जेवीएम को निर्देश देता है कि यदि खाली स्थान की मात्रा 30% से अधिक हो।

डिफ़ॉल्ट रूप से, Xminf और Xmaxf के मूल्य क्रमशः 0.3 और 0.6 हैं, लेकिन प्रयोग के लिए हमने ऊर्ध्वाधर स्केलिंग के आयाम को बढ़ाने के लिए इन सीमाओं को काफी कम कर दिया।

परिणामस्वरूप, हमारे कार्यक्रम को निष्पादित करने की एक अलग प्रक्रिया के अनुसार, हम देखते हैं कि मेमोरी गतिशील रूप से भरी हुई है और मुक्त हो गई है:



आइए यह भी सुनिश्चित करें कि कुल मेमोरी के ग्राफ पर एक नज़र डालें ताकि कोई लीक न हो:



जावा 7

हम jdk संस्करण 1.7.0_03 का परीक्षण करेंगे

हम उसी प्रोग्राम का उपयोग करते हैं और जेवीएम के लिए समान पैरामीटर सेट करते हैं। जैसा कि आप JDK 7 के साथ देख सकते हैं, सब कुछ भी सहज है:


एक अच्छा परिणाम, लेकिन, दुर्भाग्य से, जैसा कि हमने ऊपर उल्लेख किया है, यह कचरा कलेक्टर केवल एकल-प्रोसेसर मशीनों और छोटी मात्रा में मेमोरी के साथ काम करता है, जो कार्य करने के लिए बड़े, भारी अनुप्रयोगों के लिए पर्याप्त नहीं है।

समानांतर कचरा कलेक्टर (-XX: + UseParallelGC)

समानांतर समानांतर में छोटे कचरा संग्रह का काम कर सकता है, जो संसाधन और समय की खपत को काफी कम कर सकता है। यह बहु-प्रोसेसर और बहु-थ्रेडेड मशीनों पर चलने वाले मध्यम और बड़े डेटासेट अनुप्रयोगों के लिए उपयोगी है।

चलो समानांतर कचरा कलेक्टर के लिए हमारे प्रयोग को दोहराएं।

जावा 6 के लिए कुल मेमोरी उपयोग पर परिणाम:


और जावा 7 के लिए :


समानांतर, निश्चित रूप से, सीरियल पर कई फायदे हैं, उदाहरण के लिए: यह बहु-थ्रेडेड अनुप्रयोगों, बहु-प्रोसेसर मशीनों के साथ काम कर सकता है, जल्दी से बड़ी मात्रा में स्मृति के साथ मुकाबला करता है। लेकिन, अफसोस, जैसा कि हम रेखांकन में देखते हैं, यह अप्रयुक्त संसाधनों को ऑपरेटिंग सिस्टम में वापस नहीं करता है।

समवर्ती मार्क स्वीप कचरा कलेक्टर (-XX: + UseConcMarkSweepGC)

समवर्ती मार्क स्वीप अधिकांश काम करता है जबकि आवेदन अभी भी चल रहा है। यह कचरा संग्रहण के लिए ठहराव को काफी कम कर सकता है। यह मध्यम और बड़े डेटा सेट के साथ अनुप्रयोगों के लिए डिज़ाइन किया गया है जिसके लिए समग्र थ्रूपुट की तुलना में प्रतिक्रिया समय अधिक महत्वपूर्ण है।

समवर्ती मार्क स्वीप के लिए फिर से प्रक्रिया दोहराएं।

और फिर, स्थिति पिछले एक के समान है:

जावा 6 :



जावा 7 :

G1 कचरा कलेक्टर (-XX: + UseG1GC)

और फिर G1 दिखाई देता है, जिसमें समानांतर और समवर्ती मार्क स्वीप के सभी फायदे हैं, और हमारी सभी आवश्यकताओं को पूरा करता है।

हमने इसका परीक्षण करना शुरू किया, और यह पता चला कि जी 1 के लंबे समय तक संचालन के साथ, एक स्थिर मेमोरी रिसाव स्थिरांक मनाया जाता है।

जावा 6 :


बेशक, हमने इस समस्या को ओरेकल प्रतिनिधियों को संबोधित किया। सेंट पीटर्सबर्ग के ओरेकल कर्मचारी इवान क्रायलोव और व्लादिमीर इवानोव ने हमारे अनुरोध का तुरंत जवाब दिया और परिणामस्वरूप, यह समस्या जेवीएम 7 में तय की गई। आइए देखें:



जैसा कि आप देख सकते हैं, जावा 7 में सब कुछ ठीक है, उन्नत जी 1 ने अपने मिशन को पूरी तरह से पूरा किया।

जैसा कि आप जानते हैं, संसाधनों के उपयोग पर भुगतान करने की क्षमता प्रत्येक ग्राहक और कंपनी के लिए एक बहुत महत्वपूर्ण कारक है। किसी को ओवरपे नहीं करना चाहिए। हालांकि, कई और अवरोधक हैं जो इस दिशा में तेजी से विकास को रोकते हैं। हम होस्टिंग उद्योग में क्रांति जारी रखने के लिए अपनी पूरी कोशिश करेंगे।

नीचे दिए गए वीडियो में बताया गया है कि Jelastic में स्वचालित जूमिंग कैसे काम करता है:



* अज्ञात कारणों से, जी 1 में मेमोरी लीक पर हमारी रिपोर्ट में आधिकारिक बग को ओरेकल डेटाबेस से हटा दिया गया था। इस बग के बारे में अधिक जानकारी यहां पाई जा सकती है ।