उच्च प्रदर्शन और मूल विभाजन: टाइमस्केलडीबी समर्थन के साथ ज़ैबिक्स

ज़ैबिक्स एक निगरानी प्रणाली है। किसी भी अन्य प्रणाली की तरह, यह सभी निगरानी प्रणालियों की तीन मुख्य समस्याओं का सामना करती है: डेटा एकत्र करना और संसाधित करना, इतिहास संग्रहीत करना और उसे साफ करना।

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

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

TimescaleDB कैसे काम करता है, यह नियमित PostgreSQL की तुलना में क्या प्रदर्शन दे सकता है? टाइमस्केलडीबी डेटाबेस के लिए ज़ैबिक्स क्या भूमिका निभाता है? स्क्रैच से कैसे शुरू करें और PostgreSQL से कैसे माइग्रेट करें और किस कॉन्फ़िगरेशन का प्रदर्शन बेहतर है? इस सब के बारे में कटौती के तहत।

उत्पादकता चुनौतियाँ

प्रत्येक निगरानी प्रणाली को विशिष्ट प्रदर्शन चुनौतियों का सामना करना पड़ता है। मैं उनमें से तीन के बारे में बात करूंगा: डेटा संग्रह और प्रसंस्करण, भंडारण, और इतिहास समाशोधन।

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

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

इतिहास साफ़ करना. कभी-कभी ऐसा दिन आता है जब आपको मेट्रिक्स संग्रहीत करने की आवश्यकता नहीं होती है। आपको उस डेटा की आवश्यकता क्यों है जो 5 साल पहले, एक या दो महीने पहले एकत्र किया गया था: कुछ नोड्स हटा दिए गए हैं, कुछ होस्ट या मेट्रिक्स की अब आवश्यकता नहीं है क्योंकि वे पुराने हो चुके हैं और अब एकत्र नहीं किए जाते हैं। एक अच्छे मॉनिटरिंग सिस्टम को ऐतिहासिक डेटा को स्टोर करना चाहिए और समय-समय पर उसे डिलीट करना चाहिए ताकि डेटाबेस में वृद्धि न हो।

पुराने डेटा को साफ़ करना एक महत्वपूर्ण मुद्दा है जो डेटाबेस प्रदर्शन को बहुत प्रभावित करता है।

ज़ैबिक्स में कैशिंग

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

ज़ैबिक्स सर्वर की ओर से कैशिंग स्वयं है:

• कॉन्फ़िगरेशनकैश;
• वैल्यूकैश;
• हिस्ट्रीकैश;
• ट्रेंड कैश।

अधिक विस्तार से उन पर विचार करें।

कॉन्फ़िगरेशन कैश

यह मुख्य कैश है जहां हम मेट्रिक्स, होस्ट, डेटा आइटम, ट्रिगर्स - वह सब कुछ संग्रहीत करते हैं जो हमें प्रीप्रोसेसिंग और डेटा संग्रह के लिए चाहिए।

यह सब कॉन्फ़िगरेशन कैश में संग्रहीत किया जाता है ताकि डेटाबेस में अनावश्यक प्रश्न न बनें। सर्वर शुरू होने के बाद, हम इस कैश को अपडेट करते हैं, कॉन्फ़िगरेशन बनाते हैं और समय-समय पर अपडेट करते हैं।

डेटा संग्रह

आरेख काफी बड़ा है, लेकिन इसमें मुख्य बात यह है कलेक्टरों. ये विभिन्न "पोलर्स" हैं - असेंबली प्रक्रियाएं। वे विभिन्न प्रकार की असेंबली के लिए जिम्मेदार हैं: वे एसएनएमपी, आईपीएमआई के माध्यम से डेटा एकत्र करते हैं, और इसे प्रीप्रोसेसिंग में स्थानांतरित करते हैं।

संग्राहकों को नारंगी रंग में रेखांकित किया गया है।

ज़ैबिक्स ने एकत्रीकरण आइटम की गणना की है जो चेक एकत्र करने के लिए आवश्यक हैं। यदि हमारे पास वे हैं, तो हम उनके लिए सीधे वैल्यू कैश से डेटा प्राप्त करते हैं।

प्रीप्रोसेसिंग हिस्ट्री कैश

सभी संग्राहक नौकरियां प्राप्त करने के लिए कॉन्फ़िगरेशन कैश का उपयोग करते हैं। फिर वे उन्हें प्रीप्रोसेसिंग में स्थानांतरित कर देते हैं।

प्रीप्रोसेसिंग, प्रीप्रोसेसिंग चरण प्राप्त करने के लिए कॉन्फ़िगरेशन कैश का उपयोग करता है। यह इस डेटा को विभिन्न तरीकों से प्रोसेस करता है।

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

नोट: प्रीप्रोसेसिंग काफी कठिन ऑपरेशन है। v 4.2 के साथ इसे प्रॉक्सी में ले जाया गया है। यदि आपके पास बड़ी संख्या में डेटा तत्वों और संग्रह आवृत्ति के साथ एक बहुत बड़ा ज़ैबिक्स है, तो यह काम को बहुत आसान बना देता है।

वैल्यू कैश, इतिहास और रुझान कैश

हिस्ट्री सिंकर मुख्य प्रक्रिया है जो प्रत्येक डेटा तत्व, यानी प्रत्येक मान को परमाणु रूप से संसाधित करती है।

हिस्ट्री सिंकर हिस्ट्री कैश से मान लेता है और गणना के लिए ट्रिगर्स की उपस्थिति के लिए कॉन्फ़िगरेशन की जांच करता है। यदि वे मौजूद हैं, तो यह गणना करता है।

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

हिस्ट्री सिंकर सभी डेटा को डेटाबेस में लिखता है, और यह डिस्क पर लिखता है। प्रसंस्करण प्रक्रिया यहीं समाप्त होती है.

डेटाबेस में कैशिंग

जब आप घटनाओं पर ग्राफ़ या रिपोर्ट देखना चाहते हैं तो डेटाबेस पक्ष में विभिन्न कैश होते हैं:

• Innodb_buffer_pool MySQL पक्ष पर;
• shared_buffers PostgreSQL पक्ष पर;
• effective_cache_size ओरेकल की ओर;
• shared_pool DB2 पक्ष पर.

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

डेटाबेस प्रदर्शन महत्वपूर्ण है

ज़ैबिक्स सर्वर लगातार डेटा एकत्र करता है और उसे लिखता है। पुनः आरंभ करने पर, यह वैल्यू कैश को भरने के लिए इतिहास से भी पढ़ता है। स्क्रिप्ट और रिपोर्ट का उपयोग करता है ज़ैबिक्स एपीआई, जो एक वेब इंटरफ़ेस पर बनाया गया है। ज़ैबिक्स एपीआई डेटाबेस तक पहुंचता है और ग्राफ़, रिपोर्ट, इवेंट सूचियों और नवीनतम मुद्दों के लिए आवश्यक डेटा पुनर्प्राप्त करता है।

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

घरबारी

ज़ैबिक्स में तीसरी प्रदर्शन चुनौती हाउसकीपर का उपयोग करके इतिहास को साफ़ करना है। यह सभी सेटिंग्स का पालन करता है - डेटा तत्व इंगित करते हैं कि दिनों में परिवर्तन (रुझान) की गतिशीलता को कितने समय तक संग्रहीत करना है।

हम तुरंत TrendsCache की गणना करते हैं। जब डेटा आता है, तो हम इसे एक घंटे के लिए एकत्र करते हैं और प्रवृत्ति परिवर्तनों की गतिशीलता के लिए इसे तालिकाओं में रिकॉर्ड करते हैं।

हाउसकीपर सामान्य "चयन" का उपयोग करके डेटाबेस से जानकारी प्रारंभ और हटाता है। यह हमेशा प्रभावी नहीं होता है, जैसा कि आंतरिक प्रक्रियाओं के प्रदर्शन ग्राफ़ से देखा जा सकता है।

लाल ग्राफ दिखाता है कि हिस्ट्री सिंकर लगातार व्यस्त है। शीर्ष पर नारंगी ग्राफ हाउसकीपर है, जो लगातार चल रहा है। वह डेटाबेस द्वारा उसके द्वारा निर्दिष्ट सभी पंक्तियों को हटाने की प्रतीक्षा करता है।

आपको हाउसकीपर को कब अक्षम करना चाहिए? उदाहरण के लिए, एक "आइटम आईडी" है और आपको एक निश्चित समय के भीतर अंतिम 5 हजार पंक्तियों को हटाना होगा। बेशक, यह सूचकांक द्वारा होता है. लेकिन आमतौर पर डेटासेट बहुत बड़ा होता है, और डेटाबेस अभी भी डिस्क से पढ़ता है और इसे कैश में डालता है। यह डेटाबेस के लिए हमेशा एक बहुत महंगा ऑपरेशन होता है और, डेटाबेस के आकार के आधार पर, प्रदर्शन संबंधी समस्याएं पैदा हो सकती हैं।

हाउसकीपर को अक्षम करना आसान है। वेब इंटरफ़ेस में हाउसकीपर के लिए "प्रशासन सामान्य" में एक सेटिंग है। हम आंतरिक प्रवृत्ति इतिहास के लिए आंतरिक हाउसकीपिंग को अक्षम कर देते हैं और यह अब इसका प्रबंधन नहीं करता है।

हाउसकीपर को बंद कर दिया गया, ग्राफ़ समतल हो गए - इस मामले में क्या समस्याएं हो सकती हैं और तीसरी प्रदर्शन चुनौती को हल करने में क्या मदद मिल सकती है?

बँटवारा - बँटवारा या बँटवारा

आमतौर पर, मेरे द्वारा सूचीबद्ध प्रत्येक रिलेशनल डेटाबेस पर विभाजन को एक अलग तरीके से कॉन्फ़िगर किया गया है। प्रत्येक की अपनी तकनीक है, लेकिन वे सामान्य रूप से समान हैं। नया विभाजन बनाने से अक्सर कुछ समस्याएँ उत्पन्न होती हैं।

आमतौर पर, विभाजन "सेटअप" के आधार पर कॉन्फ़िगर किए जाते हैं - एक दिन में बनाए गए डेटा की मात्रा। एक नियम के रूप में, विभाजन एक दिन में जारी किया जाता है, यह न्यूनतम है। नए बैच के रुझानों के लिए - 1 महीना।

यदि "सेटअप" बहुत बड़ा है तो मान बदल सकते हैं। यदि एक छोटा "सेटअप" 5 एनवीपीएस (प्रति सेकंड नए मान) तक है, एक मध्यम 000 से 5 तक है, तो एक बड़ा 000 एनवीपीएस से ऊपर है। ये बड़े और बहुत बड़े इंस्टॉलेशन हैं जिनके लिए डेटाबेस की सावधानीपूर्वक कॉन्फ़िगरेशन की आवश्यकता होती है।

बहुत बड़ी स्थापनाओं पर, एक दिन की अवधि इष्टतम नहीं हो सकती है। मैंने प्रतिदिन 40 जीबी या अधिक के MySQL विभाजन देखे हैं। यह डेटा की एक बहुत बड़ी मात्रा है जो समस्याएँ पैदा कर सकती है और इसे कम करने की आवश्यकता है।

विभाजन क्या देता है?

विभाजन तालिकाएँ. अक्सर ये डिस्क पर अलग-अलग फ़ाइलें होती हैं। क्वेरी योजना एक विभाजन को अधिक बेहतर ढंग से चुनती है। आमतौर पर विभाजन का उपयोग रेंज द्वारा किया जाता है - यह ज़ैबिक्स के लिए भी सच है। हम वहां "टाइमस्टैम्प" का उपयोग करते हैं - युग की शुरुआत से समय। ये हमारे लिए सामान्य संख्याएँ हैं। आप दिन की शुरुआत और अंत निर्धारित करते हैं - यह एक विभाजन है।

त्वरित निष्कासन - DELETE. हटाने के लिए पंक्तियों के चयन के बजाय एक फ़ाइल/उपसारणी का चयन किया जाता है।

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

अक्सर कई डेटाबेस को त्वरित भी किया जाता है INSERT - चाइल्ड टेबल में सम्मिलन।

टाइमस्केलडीबी

वी 4.2 के लिए, हमने अपना ध्यान टाइमस्केलडीबी की ओर लगाया। यह मूल इंटरफ़ेस के साथ PostgreSQL के लिए एक एक्सटेंशन है। रिलेशनल डेटाबेस के लाभों को खोए बिना, एक्सटेंशन समय श्रृंखला डेटा के साथ प्रभावी ढंग से काम करता है। TimescaleDB भी स्वचालित रूप से विभाजन करता है।

TimescaleDB की एक अवधारणा है हाइपरटेबल (हाइपरटेबल) जो आप बनाते हैं। इसमें है चंक्स -विभाजन. खंड स्वचालित रूप से प्रबंधित हाइपरटेबल टुकड़े होते हैं जो अन्य टुकड़ों को प्रभावित नहीं करते हैं। प्रत्येक भाग की अपनी समय सीमा होती है।

टाइमस्केलडीबी बनाम पोस्टग्रेएसक्यूएल

TimescaleDB वास्तव में कुशलता से काम करता है। एक्सटेंशन के निर्माताओं का दावा है कि वे विशेष रूप से inserts में अधिक सही क्वेरी प्रोसेसिंग एल्गोरिदम का उपयोग करते हैं। जैसे-जैसे डेटासेट सम्मिलित आकार बढ़ता है, एल्गोरिदम निरंतर प्रदर्शन बनाए रखता है।

200 मिलियन पंक्तियों के बाद, PostgreSQL आमतौर पर काफी शिथिल होना शुरू हो जाता है और 0 पर प्रदर्शन खो देता है। TimescaleDB आपको किसी भी मात्रा में डेटा के लिए कुशलतापूर्वक "इन्सर्ट" डालने की अनुमति देता है।

स्थापना

किसी भी पैकेज के लिए TimescaleDB इंस्टॉल करना काफी आसान है। में प्रलेखन सब कुछ विस्तार से वर्णित है - यह आधिकारिक PostgreSQL पैकेज पर निर्भर करता है। TimescaleDB को मैन्युअल रूप से भी बनाया और संकलित किया जा सकता है।

ज़ैबिक्स डेटाबेस के लिए हम बस एक्सटेंशन को सक्रिय करते हैं:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

आप सक्रिय करें extension और इसे ज़ैबिक्स डेटाबेस के लिए बनाएं। अंतिम चरण हाइपरटेबल बनाना है।

इतिहास तालिकाओं को TimescaleDB में स्थानांतरित किया जा रहा है

इसके लिए एक खास फंक्शन है create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

फ़ंक्शन के तीन पैरामीटर हैं. पहला - डेटाबेस में तालिका, जिसके लिए आपको एक हाइपरटेबल बनाने की आवश्यकता है। दूसरा - क्षेत्र, जिसके अनुसार आपको बनाने की आवश्यकता है chunk_time_interval - उपयोग किए जाने वाले विभाजन खंडों का अंतराल। मेरे मामले में, अंतराल एक दिन है - 86।

तीसरा पैरामीटर - migrate_data. यदि आप सेट करते हैं true, फिर सभी मौजूदा डेटा को पूर्व-निर्मित खंडों में स्थानांतरित कर दिया जाता है। मैंने स्वयं इसका प्रयोग किया migrate_data. मेरे पास लगभग 1 टीबी थी, जिसमें एक घंटे से अधिक का समय लगा। यहां तक ​​कि कुछ मामलों में, परीक्षण के दौरान, मैंने उन चरित्र प्रकारों का ऐतिहासिक डेटा हटा दिया जो भंडारण के लिए आवश्यक नहीं थे, ताकि उन्हें स्थानांतरित न किया जा सके।

अंतिम चरण - UPDATE: में db_extension रखना timescaledbताकि डेटाबेस समझ सके कि यह एक्सटेंशन मौजूद है। ज़ैबिक्स इसे सक्रिय करता है और डेटाबेस में सिंटैक्स और क्वेरीज़ का सही ढंग से उपयोग करता है - वे सुविधाएँ जो टाइमस्केलडीबी के लिए आवश्यक हैं।

हार्डवेयर की समाकृति

मैंने दो सर्वरों का उपयोग किया. पहला - वीएमवेयर मशीन. यह काफी छोटा है: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz प्रोसेसर, 16 GB RAM और एक 200 GB SSD।

मैंने इस पर डेबियन 10.8-10.8.pgdg1+90 OS और xfs फ़ाइल सिस्टम के साथ PostgreSQL 1 स्थापित किया। मैंने इस विशेष डेटाबेस का उपयोग करने के लिए सब कुछ न्यूनतम रूप से कॉन्फ़िगर किया है, ज़ैबिक्स स्वयं जो उपयोग करेगा उसे छोड़कर।

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

प्रारंभ में कॉन्फ़िगरेशन शामिल था 5 तत्व प्रति होस्ट डेटा. लगभग हर तत्व में वास्तविक इंस्टॉलेशन के समान बनाने के लिए एक ट्रिगर होता था। कुछ मामलों में एक से अधिक ट्रिगर थे। एक नेटवर्क नोड के लिए वहाँ थे 3-000 ट्रिगर.

डेटा आइटम अद्यतन अंतराल - 4-7 सेकंड. मैंने न केवल 50 एजेंटों का उपयोग करके, बल्कि और अधिक जोड़कर लोड को नियंत्रित किया। इसके अलावा, डेटा तत्वों का उपयोग करके, मैंने लोड को गतिशील रूप से समायोजित किया और अद्यतन अंतराल को 4 एस तक कम कर दिया।

पोस्टग्रेएसक्यूएल। 35 एन.वी.पी.एस

इस हार्डवेयर पर मेरा पहला रन शुद्ध PostgreSQL पर था - प्रति सेकंड 35 हजार मान। जैसा कि आप देख सकते हैं, डेटा डालने में एक सेकंड का समय लगता है - सब कुछ अच्छा और तेज़ है। एकमात्र बात यह है कि 200 जीबी एसएसडी डिस्क जल्दी भर जाती है।

यह एक मानक ज़ैबिक्स सर्वर प्रदर्शन डैशबोर्ड है।

पहला नीला ग्राफ़ प्रति सेकंड मानों की संख्या है। दाईं ओर दूसरा ग्राफ़ बिल्ड प्रक्रियाओं को लोड करना है। तीसरा आंतरिक निर्माण प्रक्रियाओं को लोड कर रहा है: हिस्ट्री सिंकर्स और हाउसकीपर, जो काफी समय से यहां चल रहा है।

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

पोस्टग्रेएसक्यूएल। 50 एन.वी.पी.एस

फिर मैंने उसी हार्डवेयर पर लोड को 50 हजार मान प्रति सेकंड तक बढ़ा दिया।

हाउसकीपर से लोड करते समय 10 हजार मान डालने में 2-3 सेकंड का समय लगा।

हाउसकीपर पहले से ही काम में हस्तक्षेप करना शुरू कर रहा है।

तीसरे ग्राफ़ से पता चलता है कि, सामान्य तौर पर, ट्रैपर्स और हिस्ट्री सिंचर्स पर भार अभी भी 60% है। चौथे ग्राफ़ में, हाउसकीपर ऑपरेशन के दौरान हिस्ट्री कैश पहले से ही काफी सक्रिय रूप से भरना शुरू कर रहा है। यह 20% भरा हुआ है, जो लगभग 0,5 जीबी है।

पोस्टग्रेएसक्यूएल। 80 एन.वी.पी.एस

फिर मैंने लोड बढ़ाकर 80 हजार मान प्रति सेकंड कर दिया। ये लगभग 400 हजार डेटा तत्व और 280 हजार ट्रिगर हैं।

तीस हिस्ट्री सिंचर्स की लोडिंग लागत पहले से ही काफी अधिक है।

मैंने विभिन्न पैरामीटर भी बढ़ाए: इतिहास सिंकर्स, कैश।

मेरे हार्डवेयर पर, हिस्ट्री सिंकर्स की लोडिंग अधिकतम तक बढ़ गई। हिस्ट्रीकैश जल्दी से डेटा से भर गया - प्रसंस्करण के लिए डेटा बफर में जमा हो गया था।

इस पूरे समय मैंने देखा कि प्रोसेसर, रैम और अन्य सिस्टम मापदंडों का उपयोग कैसे किया गया, और पाया कि डिस्क का उपयोग अपने अधिकतम स्तर पर था।

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

दूसरा सर्वर

मैंने दूसरा सर्वर लिया, जिसमें पहले से ही 48 प्रोसेसर और 128 जीबी रैम थी। मैंने इसे ट्यून किया - इसे 60 हिस्ट्री सिंकर पर सेट किया, और स्वीकार्य प्रदर्शन हासिल किया।

वास्तव में, यह पहले से ही उत्पादकता की सीमा है जहां कुछ करने की आवश्यकता है।

टाइमस्केलडीबी। 80 एन.वी.पी.एस

मेरा मुख्य कार्य ज़ैबिक्स लोड के विरुद्ध टाइमस्केलडीबी की क्षमताओं का परीक्षण करना है। प्रति सेकंड 80 हजार मान बहुत हैं, मेट्रिक्स एकत्र करने की आवृत्ति (निश्चित रूप से यैंडेक्स को छोड़कर) और एक काफी बड़ा "सेटअप"।

प्रत्येक ग्राफ़ में गिरावट होती है - यह सटीक रूप से डेटा माइग्रेशन है। ज़ैबिक्स सर्वर में विफलताओं के बाद, हिस्ट्री सिंकर की लोडिंग प्रोफ़ाइल में बहुत बदलाव आया - यह तीन बार गिरा।

TimescaleDB आपको लगभग 3 गुना तेजी से डेटा डालने और कम हिस्ट्री कैश का उपयोग करने की अनुमति देता है।

तदनुसार, आपको समय पर डेटा प्राप्त होगा।

टाइमस्केलडीबी। 120 एन.वी.पी.एस

फिर मैंने डेटा तत्वों की संख्या बढ़ाकर 500 हजार कर दी। मुख्य कार्य टाइमस्केलडीबी की क्षमताओं का परीक्षण करना था - मुझे प्रति सेकंड 125 हजार मानों का परिकलित मान प्राप्त हुआ।

यह एक कार्यशील "सेटअप" है जो लंबे समय तक कार्य कर सकता है। लेकिन चूंकि मेरी डिस्क केवल 1,5 टीबी की थी, इसलिए मैंने इसे कुछ दिनों में भर दिया।

सबसे महत्वपूर्ण बात यह है कि उसी समय नए TimescaleDB विभाजन बनाए गए।

यह प्रदर्शन के लिए पूरी तरह से ध्यान देने योग्य नहीं है। उदाहरण के लिए, जब MySQL में विभाजन बनाए जाते हैं, तो सब कुछ अलग होता है। यह आमतौर पर रात में होता है क्योंकि यह सामान्य प्रविष्टि को अवरुद्ध करता है, तालिकाओं के साथ काम करता है और सेवा में गिरावट पैदा कर सकता है। TimescaleDB के मामले में ऐसा नहीं है।

उदाहरण के तौर पर, मैं समुदाय के कई लोगों का एक ग्राफ़ दिखाऊंगा। चित्र में, TimescaleDB सक्षम है, जिसके कारण प्रोसेसर पर io.weight का उपयोग करने का भार कम हो गया है। आंतरिक प्रक्रिया तत्वों का उपयोग भी कम हो गया। इसके अलावा, यह साधारण पैनकेक डिस्क पर एक साधारण वर्चुअल मशीन है, एसएसडी नहीं।

निष्कर्ष

TimescaleDB छोटे "सेटअप" के लिए एक अच्छा समाधान है, जो डिस्क के प्रदर्शन को प्रभावित करता है। यह आपको तब तक अच्छी तरह से काम करना जारी रखने की अनुमति देगा जब तक कि डेटाबेस जल्द से जल्द हार्डवेयर में स्थानांतरित न हो जाए।

TimescaleDB को कॉन्फ़िगर करना आसान है, प्रदर्शन लाभ देता है, Zabbix के साथ अच्छा काम करता है PostgreSQL पर इसके लाभ हैं.

यदि आप PostgreSQL का उपयोग करते हैं और इसे बदलने की योजना नहीं बनाते हैं, तो मैं अनुशंसा करता हूं Zabbix के संयोजन में TimescaleDB एक्सटेंशन के साथ PostgreSQL का उपयोग करें. यह समाधान मध्यम "सेटअप" तक प्रभावी ढंग से काम करता है।

जब हम "उच्च प्रदर्शन" कहते हैं तो हमारा मतलब होता है HighLoad ++. आपको उन प्रौद्योगिकियों और प्रथाओं के बारे में जानने के लिए अधिक समय तक इंतजार नहीं करना पड़ेगा जो सेवाओं को लाखों उपयोगकर्ताओं की सेवा करने में सक्षम बनाती हैं। सूची रिपोर्टों 7 और 8 नवंबर के लिए हम पहले ही संकलन कर चुके हैं, लेकिन यहां मीट और अधिक सुझाव दिया जा सकता है.

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

स्रोत: www.habr.com