उच्च प्रदर्शन और देशी विभाजन: TimescaleDB समर्थन के साथ Zabbix

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

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



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

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

प्रदर्शन की चुनौतियां

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

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

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

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

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

जैबिक्स कैशिंग

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

Zabbix सर्वर के किनारे पर ही कैशिंग है:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache।

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

ConfigurationCache

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



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

डेटा संग्रह

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

संग्राहक नारंगी रंग के होते हैं।

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

Preprocessing HistoryCache

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



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

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

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

ValueCache, इतिहास और रुझान कैश

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

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

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

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

डीबी कैशिंग

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

• MySQL की ओर से Innodb_buffer_pool ;
• PostgreSQL की ओर से shared_buffers किए गए shared_buffers ;
• Oracle की ओर से प्रभावी_चेचे_ आकार;
• DB2 की ओर shared_pool किया गया।

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

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

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



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

हाउसकीपर

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

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

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



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

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



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

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

विभाजन - विभाजन या विभाजन

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

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

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

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

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

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

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

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

अक्सर, कई डेटाबेस भी चाइल्ड टेबल में INSERT आवेषण को गति देते हैं।

TimescaleDB

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

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

TimescaleDB बनाम PostgreSQL

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



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

स्थापना

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

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

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

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

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,400।

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

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

लोहे का विन्यास

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

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

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

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

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

PostgreSQL। 35,000 एनवीपीएस

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



यह मानक Zabbix सर्वर प्रदर्शन डैशबोर्ड है।



पहला नीला ग्राफ प्रति सेकंड मानों की संख्या है। दाईं ओर दूसरा ग्राफ विधानसभा प्रक्रियाओं का लोडिंग है। तीसरा आंतरिक विधानसभा प्रक्रियाओं को लोड कर रहा है: इतिहास सिंकर्स और हाउसकीपर, जो यहां कुछ समय से चल रहा है।

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

PostgreSQL। 50,000 एनवीपीएस

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



हाउसकीपर से लोड करते समय, 2-3 एस के लिए 10 हजार मान दर्ज किए गए थे।


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

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

PostgreSQL। 80,000 एनवीपीएस

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


तीस हिस्ट्री सिंकर्स लोड करने के लिए इंसर्ट पहले से ही काफी ज्यादा है।

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



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

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



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

दूसरा सर्वर

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



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

TimescaleDB। 80,000 एनवीपीएस

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



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

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

तदनुसार, डेटा आपको समय पर वितरित किया जाएगा।

TimescaleDB। 120,000 एनवीपीएस

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



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



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

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

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

निष्कर्ष

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

TimescaleDB कॉन्फ़िगर करना आसान है, एक प्रदर्शन को बढ़ावा देता है, Zabbix के साथ अच्छी तरह से काम करता है और PostgreSQL पर फायदे हैं ।

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

हम कहते हैं कि "उच्च प्रदर्शन" - हमारा मतलब है HighLoad ++ । उन तकनीकों और प्रथाओं से परिचित होने की प्रतीक्षा कर रहे हैं जो बहुत ही संक्षेप में लाखों उपयोगकर्ताओं की सेवा करने की अनुमति देती हैं। हमने पहले ही 7 और 8 नवंबर के लिए रिपोर्ट की एक सूची तैयार की है, लेकिन अभी भी mitaps की पेशकश की जा सकती है।

हमारे न्यूज़लेटर और टेलीग्राम की सदस्यता लें, जिसमें हम आगामी सम्मेलन के चिप्स को प्रकट करते हैं, और सीखते हैं कि इसका सबसे अधिक लाभ कैसे प्राप्त करें।