HBase के लिए जावा कचरा संग्रह ट्यूनिंग

इंटेल जावा प्रदर्शन आर्किटेक्ट एरिक काज़मारेक (मूल रूप से यहां प्रकाशित) की यह अतिथि पोस्ट 100% YCSB रीड्स पर ध्यान केंद्रित करते हुए Apache HBase के लिए जावा कचरा संग्रह (GC) को ट्यून करने का तरीका बताती है।

Apache HBase एक Apache ओपन सोर्स प्रोजेक्ट है जो NoSQL डेटा स्टोरेज की पेशकश करता है। अक्सर एचडीएफएस के साथ प्रयोग किया जाता है, एचबीएएस का व्यापक रूप से दुनिया भर में उपयोग किया जाता है। प्रसिद्ध उपयोगकर्ताओं में फेसबुक, ट्विटर, याहू और बहुत कुछ शामिल हैं। डेवलपर के दृष्टिकोण से, HBase एक "वितरित, संस्करणबद्ध, गैर-संबंधपरक डेटाबेस है जिसे Google के बिगटेबल, संरचित डेटा के लिए एक वितरित भंडारण प्रणाली के बाद तैयार किया गया है"। HBase या तो स्केलिंग (यानी, बड़े सर्वर पर परिनियोजन) या स्केलिंग आउट (यानी, अधिक सर्वर पर परिनियोजन) द्वारा बहुत उच्च थ्रूपुट को आसानी से संभाल सकता है।

उपयोगकर्ता के दृष्टिकोण से, प्रत्येक एकल क्वेरी के लिए विलंबता बहुत मायने रखती है। जब हम HBase वर्कलोड का परीक्षण, ट्यून और अनुकूलन करने के लिए उपयोगकर्ताओं के साथ काम करते हैं, तो अब हमें एक महत्वपूर्ण संख्या का सामना करना पड़ता है जो वास्तव में 99वां प्रतिशत ऑपरेशन विलंबता चाहते हैं। इसका मतलब है कि एक राउंड-ट्रिप, क्लाइंट अनुरोध से क्लाइंट को वापस प्रतिक्रिया तक, सभी 100 मिलीसेकंड के भीतर।

विलंबता में भिन्नता के लिए कई कारक योगदान करते हैं। सबसे विनाशकारी और अप्रत्याशित विलंबता घुसपैठियों में से एक है जावा वर्चुअल मशीन (जेवीएम) का "स्टॉप द वर्ल्ड" कचरा संग्रहण (मेमोरी क्लीन-अप) के लिए रुकता है।

इसे संबोधित करने के लिए, हमने Oracle jdk7u21 और jdk7u60 G1 (कचरा 1st) कलेक्टर का उपयोग करके कुछ प्रयोग करने की कोशिश की। हमने जिस सर्वर सिस्टम का उपयोग किया वह हाइपर-थ्रेडिंग (40 लॉजिकल प्रोसेसर) के साथ Intel Xeon Ivy-bridge EP प्रोसेसर पर आधारित था। इसमें स्थानीय भंडारण के रूप में 256GB DDR3-1600 RAM और तीन 400GB SSD थे। इस छोटे से सेटअप में एक मास्टर और एक दास होता है, जो एक नोड पर उचित रूप से लोड किए गए लोड के साथ कॉन्फ़िगर किया जाता है। हमने HFile भंडारण के लिए HBase संस्करण 0.98.1 और स्थानीय फाइल सिस्टम का उपयोग किया। HBase परीक्षण तालिका को 400 मिलियन पंक्तियों के रूप में कॉन्फ़िगर किया गया था, और इसका आकार 580GB था। हमने डिफ़ॉल्ट HBase हीप रणनीति का उपयोग किया:ब्लॉक कैश के लिए 40%, मेमस्टोर के लिए 40%। YCSB का उपयोग HBase सर्वर को अनुरोध भेजने वाले 600 वर्क थ्रेड्स को चलाने के लिए किया गया था।

निम्न चार्ट दिखाता है कि jdk7u21 -XX:+UseG1GC -Xms100g -Xmx100g -XX:MaxGCPauseMillis=100 का उपयोग करके एक घंटे के लिए 100% पढ़ा जा रहा है। . हमने कचरा संग्रहकर्ता को उपयोग करने के लिए निर्दिष्ट किया, ढेर का आकार, और वांछित कचरा संग्रह (जीसी) "दुनिया को रोकें" विराम समय।

चित्र 1:GC ठहराव समय में जंगली झूले

इस मामले में, हमें बेतहाशा झूलते हुए जीसी पॉज़ मिले। 17.5 सेकंड तक पहुंचने वाले शुरुआती स्पाइक के बाद GC पॉज़ की सीमा 7 मिलीसेकंड से लेकर 5 पूर्ण सेकंड तक थी।

निम्न चार्ट स्थिर अवस्था के दौरान अधिक विवरण दिखाता है:

चित्र 2:स्थिर अवस्था के दौरान GC विराम विवरण

चित्र 2 हमें बताता है कि जीसी विराम वास्तव में तीन अलग-अलग समूहों में आता है:(1) 1 से 1.5 सेकंड के बीच; (2) 0.007 सेकंड से 0.5 सेकंड के बीच; (3) 1.5 सेकंड से 5 सेकंड के बीच स्पाइक्स। यह बहुत अजीब था, इसलिए हमने यह देखने के लिए हाल ही में जारी किए गए jdk7u60 का परीक्षण किया कि क्या डेटा कोई भिन्न होगा:

हमने ठीक उसी JVM पैरामीटर का उपयोग करके समान 100% रीड टेस्ट चलाए:-XX:+UseG1GC -Xms100g -Xmx100g -XX:MaxGCPauseMillis=100 ।

चित्र 3:पॉज़ टाइम स्पाइक्स को संभालने में काफी सुधार हुआ है

Jdk7u60 ने डाउन स्टेज के दौरान शुरुआती स्पाइक के बाद पॉज़ टाइम स्पाइक्स को संभालने के लिए G1 की क्षमता में बहुत सुधार किया। Jdk7u60 ने एक घंटे की दौड़ के दौरान 1029 युवा और मिश्रित GCs बनाए। जीसी हर 3.5 सेकंड में हुआ। Jdk7u21 ने प्रत्येक 12.6 सेकंड में प्रत्येक GC के साथ 286 GC बनाए। Jdk7u60 बिना किसी बड़े उछाल के 0.302 से 1 सेकंड के बीच के विराम समय को प्रबंधित करने में सक्षम था।

नीचे दिया गया चित्र 4 हमें स्थिर अवस्था के दौरान 150 GC विरामों पर करीब से नज़र डालता है:

चित्र 4:बेहतर है, लेकिन पर्याप्त नहीं है

स्थिर अवस्था के दौरान, jdk7u60 औसत ठहराव समय को लगभग 369 मिलीसेकंड के आसपास रखने में सक्षम था। यह jdk7u21 से काफी बेहतर था, लेकिन यह अभी भी –Xx:MaxGCPauseMillis=100 द्वारा दिए गए 100 मिलीसेकंड की हमारी आवश्यकता को पूरा नहीं करता था। ।

यह निर्धारित करने के लिए कि हम अपना 100 मिलियन सेकंड का ठहराव समय प्राप्त करने के लिए और क्या कर सकते हैं, हमें JVM के मेमोरी प्रबंधन और G1 (कचरा पहले) कचरा संग्रहकर्ता के व्यवहार के बारे में अधिक समझने की आवश्यकता है। निम्नलिखित आंकड़े दिखाते हैं कि G1 यंग जेन संग्रह पर कैसे काम करता है।

चित्र 5:चार्ली हंट और मोनिका बेकविथ द्वारा 2012 JavaOne प्रस्तुति से स्लाइड:"G1 कचरा कलेक्टर प्रदर्शन ट्यूनिंग"

जब जेवीएम शुरू होता है, जेवीएम लॉन्चिंग पैरामीटर के आधार पर, यह ऑपरेटिंग सिस्टम को जेवीएम के ढेर को होस्ट करने के लिए एक बड़ा निरंतर मेमोरी खंड आवंटित करने के लिए कहता है। उस मेमोरी चंक को JVM द्वारा क्षेत्रों में विभाजित किया जाता है।

चित्र 6:चार्ली हंट और मोनिका बेकविथ की 2012 JavaOne प्रस्तुति से स्लाइड:"G1 कचरा कलेक्टर प्रदर्शन ट्यूनिंग"

जैसा कि चित्र 6 दिखाता है, प्रत्येक ऑब्जेक्ट जिसे जावा प्रोग्राम जावा एपीआई का उपयोग करके आवंटित करता है, पहले बाईं ओर युवा पीढ़ी में ईडन स्पेस में आता है। कुछ समय बाद, ईडन भर जाता है, और एक युवा पीढ़ी जीसी चालू हो जाती है। जिन वस्तुओं को अभी भी संदर्भित किया जाता है (यानी, "जीवित") को उत्तरजीवी स्थान पर कॉपी किया जाता है। जब ऑब्जेक्ट युवा पीढ़ी में कई GCs से बचे रहते हैं, तो उन्हें पुरानी पीढ़ी के स्थान पर पदोन्नत किया जाता है।

जब यंग जीसी होता है, तो लाइव ऑब्जेक्ट को सुरक्षित रूप से चिह्नित और कॉपी करने के लिए जावा एप्लिकेशन के थ्रेड्स को रोक दिया जाता है। ये स्टॉप कुख्यात "स्टॉप-द-वर्ल्ड" जीसी पॉज़ हैं, जो पॉज़ खत्म होने तक एप्लिकेशन को गैर-प्रतिक्रिया देते हैं।

चित्र 7:चार्ली हंट और मोनिका बेकविथ की 2012 JavaOne प्रस्तुति से स्लाइड:"G1 कचरा कलेक्टर प्रदर्शन ट्यूनिंग"

पुरानी पीढ़ी में भी भीड़ हो सकती है। एक निश्चित स्तर पर—-XX:InitiatingHeapOccupancyPercent=? द्वारा नियंत्रित जहां डिफ़ॉल्ट कुल ढेर का 45% है-एक मिश्रित जीसी ट्रिगर होता है। यह यंग जेन और ओल्ड जेन दोनों को इकट्ठा करता है। मिक्स्ड GC पॉज़ इस बात से नियंत्रित होते हैं कि मिक्स्ड GC होने पर यंग जीन को क्लीन-अप होने में कितना समय लगता है।

इसलिए हम G1 में देख सकते हैं कि "दुनिया को रोकें" GC पॉज़ इस बात पर हावी हैं कि G1 कितनी तेजी से ईडन स्पेस से लाइव ऑब्जेक्ट्स को चिह्नित और कॉपी कर सकता है। इसे ध्यान में रखते हुए, हम विश्लेषण करेंगे कि कैसे HBase मेमोरी आवंटन पैटर्न G1 GC को ट्यून करने में हमारी मदद करेगा ताकि हम अपना 100 मिलीसेकंड का वांछित विराम प्राप्त कर सकें।

HBase में, दो इन-मेमोरी संरचनाएं हैं जो इसके अधिकांश ढेर का उपभोग करती हैं:BlockCache , पढ़ने के संचालन के लिए HBase फ़ाइल ब्लॉक को कैश करना, और नवीनतम अपडेट को मेमस्टोर कैशिंग करना।

चित्र 8:HBase में, दो इन-मेमोरी संरचनाएं इसके अधिकांश ढेर का उपभोग करती हैं।

HBase के BlockCache . का डिफ़ॉल्ट कार्यान्वयन LruBlockCache है , जो सभी HBase ब्लॉकों को होस्ट करने के लिए बस एक बड़े बाइट सरणी का उपयोग करता है। जब ब्लॉक "बेदखल" होते हैं, तो उस ब्लॉक के जावा ऑब्जेक्ट का संदर्भ हटा दिया जाता है, जिससे जीसी मेमोरी को स्थानांतरित कर सकता है।

LruBlockCache बनाने वाली नई वस्तुएं और Memstore सबसे पहले यंग जनरेशन के ईडन स्पेस में जाएं। यदि वे लंबे समय तक जीवित रहते हैं (अर्थात, यदि उन्हें LruBlockCache से बेदखल नहीं किया जाता है या मेमस्टोर से हटा दिया गया), फिर जीसी की कई युवा पीढ़ियों के बाद, वे जावा हीप की पुरानी पीढ़ी के लिए अपना रास्ता बनाते हैं। जब पुरानी पीढ़ी का खाली स्थान किसी दिए गए threshOld . से कम हो (InitiatingHeapOccupancyPercent शुरू करने के लिए), मिश्रित जीसी पुरानी पीढ़ी में कुछ मृत वस्तुओं को शामिल करता है और हटाता है, युवा पीढ़ी से जीवित वस्तुओं की प्रतिलिपि बनाता है, और युवा पीढ़ी के ईडन और पुरानी पीढ़ी के HeapOccupancyPercent की पुनर्गणना करता है। . आखिरकार, जब HeapOccupancyPercent एक निश्चित स्तर तक पहुँचता है, एक FULL GC होता है, जो विशाल "दुनिया को रोकें" बनाता है GC पुराने जीन के अंदर सभी मृत वस्तुओं को साफ करने के लिए रुक जाता है।

"-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy द्वारा निर्मित GC लॉग का अध्ययन करने के बाद “, हमने देखा HeapOccupancyPercent HBase 100% रीड के दौरान पूर्ण GC को प्रेरित करने के लिए कभी भी इतना बड़ा नहीं हुआ। हमने जो GC पॉज़ देखे उनमें यंग जेन "स्टॉप द वर्ल्ड" पॉज़ और समय के साथ बढ़ते संदर्भ प्रसंस्करण का बोलबाला था।

उस विश्लेषण को पूरा करने पर, हमने डिफ़ॉल्ट G1 GC सेटिंग में परिवर्तनों के तीन समूह बनाए:

1. -XX:+ParallelRefProcEnabled जब यह ध्वज चालू होता है, तो GC यंग और मिश्रित GC के दौरान बढ़ते संदर्भों को संसाधित करने के लिए कई थ्रेड्स का उपयोग करता है। HBase के लिए इस ध्वज के साथ, GC टिप्पणी करने का समय 75% कम हो जाता है, और समग्र GC विराम समय 30% कम हो जाता है।
2. Set -XX:-ResizePLAB and -XX:ParallelGCThreads=8+(logical processors-8)(5/8) युवा संग्रह के दौरान प्रचार स्थानीय आवंटन बफ़र्स (PLABs) का उपयोग किया जाता है। एकाधिक धागे का उपयोग किया जाता है। प्रत्येक थ्रेड को उत्तरजीवी या पुराने स्थान में कॉपी की जा रही वस्तुओं के लिए स्थान आवंटित करने की आवश्यकता हो सकती है। PLABs को साझा डेटा संरचनाओं के लिए थ्रेड्स की प्रतिस्पर्धा से बचने के लिए आवश्यक है जो मुक्त मेमोरी का प्रबंधन करते हैं। प्रत्येक जीसी थ्रेड में उत्तरजीविता स्थान के लिए एक PLAB और पुराने स्थान के लिए एक होता है। हम जीसी थ्रेड्स के बीच बड़ी संचार लागत, साथ ही प्रत्येक जीसी के दौरान भिन्नताओं से बचने के लिए पीएलएबी का आकार बदलना बंद करना चाहते हैं। हम जीसी थ्रेड्स की संख्या को 8+ (लॉजिकल प्रोसेसर -8) द्वारा गणना किए गए आकार के रूप में तय करना चाहते हैं। 5/8)। यह सूत्र हाल ही में Oracle द्वारा अनुशंसित किया गया था। दोनों सेटिंग्स के साथ, हम रन के दौरान आसान GC पॉज़ देखने में सक्षम हैं।
3. बदलें -XX:G1NewSizePercent -XX:+PrintGCDetails and -XX:+PrintAdaptiveSizePolicy के आउटपुट के आधार पर 100GB हीप के लिए डिफ़ॉल्ट 5 से 1 , हमने देखा कि हमारे वांछित 100GC ठहराव समय को पूरा करने में G1 की विफलता का कारण ईडन को संसाधित करने में लगने वाला समय था। दूसरे शब्दों में, G1 ने हमारे परीक्षणों के दौरान 5GB ईडन को खाली करने में औसतन 369 मिलीसेकंड का समय लिया। इसके बाद हमने -XX:G1NewSizePercent=
का उपयोग करके ईडन का आकार बदल दिया। फ़्लैग 5 से नीचे 1. इस बदलाव के साथ, हमने देखा कि GC पॉज़ टाइम घटकर 100 मिलीसेकंड हो गया है।

इस प्रयोग से, हमने पाया कि ईडन को साफ करने के लिए G1 की गति लगभग 1GB प्रति 100 मिलीसेकंड या हमारे द्वारा उपयोग किए गए HBase सेटअप के लिए 10GB प्रति सेकंड है।

उस गति के आधार पर, हम -XX:G1NewSizePercent=
सेट कर सकते हैं इसलिए ईडन का आकार लगभग 1GB रखा जा सकता है। उदाहरण के लिए:

• 32GB हीप, -XX:G1NewSizePercent=3
• 64GB हीप, -XX:G1NewSizePercent=2
• 100GB और उससे अधिक का ढेर, -XX:G1NewSizePercent=1
• तो HRegionserver के लिए हमारे अंतिम कमांड-लाइन विकल्प हैं:
  • -XX:+UseG1GC
  • -Xms100g -Xmx100g (हमारे परीक्षणों में उपयोग किए गए ढेर का आकार)
  • -XX:MaxGCPauseMillis=100 (परीक्षणों में वांछित GC ठहराव समय)
  • –XX:+ParallelRefProcEnabled
  • -XX:-ResizePLAB
  • -XX:ParallelGCThreads= 8+(40-8)(5/8)=28
  • -XX:G1NewSizePercent=1

1 घंटे के लिए 100% रीड ऑपरेशन चलाने के लिए जीसी पॉज़ टाइम चार्ट यहां दिया गया है:

चित्र 9:उच्चतम प्रारंभिक बसने वाले स्पाइक्स आधे से अधिक कम हो गए थे।

इस चार्ट में, उच्चतम प्रारंभिक बसने वाले स्पाइक्स को भी 3.792 सेकंड से घटाकर 1.684 सेकंड कर दिया गया था। सबसे शुरुआती स्पाइक्स 1 सेकंड से कम थे। निपटान के बाद, GC ठहराव समय को लगभग 100 मिलीसेकंड के आसपास रखने में सक्षम था।

नीचे दिया गया चार्ट स्थिर अवस्था के दौरान, ट्यूनिंग के साथ और बिना ट्यूनिंग के jdk7u60 रन की तुलना करता है:

चित्र 10:jdk7u60 स्थिर अवस्था के दौरान ट्यूनिंग के साथ और बिना ट्यूनिंग के चलता है।

ऊपर वर्णित सरल जीसी ट्यूनिंग, औसत 106 मिलीसेकंड और 7 मिलीसेकंड मानक विचलन के साथ आदर्श जीसी विराम समय, लगभग 100 मिलीसेकंड देता है।

सारांश

HBase एक प्रतिक्रिया-समय-महत्वपूर्ण अनुप्रयोग है जिसके लिए पूर्वानुमान योग्य और प्रबंधनीय होने के लिए GC ठहराव समय की आवश्यकता होती है। Oracle jdk7u60 के साथ, -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy द्वारा रिपोर्ट की गई GC जानकारी के आधार पर , हम GC पॉज़ टाइम को अपने वांछित 100 मिलीसेकंड तक ट्यून करने में सक्षम हैं।

Eric Kaczmarek Intel के सॉफ़्टवेयर समाधान समूह में जावा प्रदर्शन वास्तुकार है। वह इंटेल प्लेटफॉर्म के लिए बिग डेटा फ्रेमवर्क (Hadoop, HBase, Spark, Cassandra) को सक्षम और अनुकूलित करने के लिए Intel के प्रयास का नेतृत्व करता है।

प्रदर्शन परीक्षणों में उपयोग किए गए सॉफ़्टवेयर और वर्कलोड को केवल इंटेल माइक्रोप्रोसेसरों पर प्रदर्शन के लिए अनुकूलित किया गया हो सकता है। प्रदर्शन परीक्षण, जैसे कि SYSmark और MobileMark, को विशिष्ट कंप्यूटर सिस्टम, घटकों, सॉफ़्टवेयर, संचालन और कार्यों का उपयोग करके मापा जाता है। उन कारकों में से किसी भी परिवर्तन के कारण परिणाम भिन्न हो सकते हैं। अन्य उत्पादों के साथ संयुक्त होने पर उस उत्पाद के प्रदर्शन सहित, अपनी सोची-समझी खरीदारी का पूरी तरह से मूल्यांकन करने में आपकी सहायता करने के लिए आपको अन्य जानकारी और प्रदर्शन परीक्षणों से परामर्श लेना चाहिए।

इंटेल प्रोसेसर संख्या प्रदर्शन को नहीं दर्शाती हैं। प्रोसेसर संख्या प्रत्येक प्रोसेसर परिवार के भीतर सुविधाओं को अलग करती है। विभिन्न प्रोसेसर परिवारों में नहीं। यहां जाएं:http://www.intel.com/products/processor_number।

कॉपीराइट 2014 Intel Corp. Intel, Intel लोगो और Xeon, U.S. और/या अन्य देशों में Intel Corporation के ट्रेडमार्क हैं।