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

Zabbix एक निगरानी प्रणाली हो। कुनै पनि अन्य प्रणाली जस्तै, यसले सबै निगरानी प्रणालीहरूको तीन मुख्य समस्याहरूको सामना गर्दछ: डेटा सङ्कलन र प्रशोधन, इतिहास भण्डारण, र यसलाई सफा गर्ने।

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

Zabbix मा संग्रह र भण्डारण को समयमा ढिलाइ को समस्या क्यास द्वारा हल गरिन्छ: धेरै प्रकार को क्यास, डाटाबेस मा क्यासिंग। तेस्रो समस्या समाधान गर्न, क्यासिङ उपयुक्त छैन, त्यसैले Zabbix ले TimescaleDB प्रयोग गर्यो। उहाँले तपाईंलाई यसको बारेमा बताउनुहुनेछ एन्ड्री गुश्चिन - प्राविधिक सहयोग इन्जिनियर Zabbix SIA। Andrey 6 वर्ष भन्दा बढी समय देखि Zabbix समर्थन गर्दै आएको छ र प्रदर्शन संग प्रत्यक्ष अनुभव छ।

TimescaleDB कसरी काम गर्छ, यसले नियमित PostgreSQL को तुलनामा कस्तो प्रदर्शन दिन सक्छ? Zabbix ले TimescaleDB डाटाबेसको लागि के भूमिका खेल्छ? कसरी स्क्र्याचबाट सुरु गर्ने र कसरी PostgreSQL बाट माइग्रेट गर्ने र कुन कन्फिगरेसनमा राम्रो प्रदर्शन छ? काट अन्तर्गत यो सबै बारे।

उत्पादकता चुनौतीहरू

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

द्रुत डाटा संग्रह र प्रशोधन। राम्रो अनुगमन प्रणालीले तुरुन्तै सबै डाटा प्राप्त गर्नुपर्छ र ट्रिगर अभिव्यक्ति अनुसार यसको मापदण्ड अनुसार प्रशोधन गर्नुपर्छ। प्रशोधन पछि, प्रणालीले चाँडै यो डाटालाई पछि प्रयोगको लागि डाटाबेसमा बचत गर्नुपर्छ।

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

इतिहास खाली गर्दै। कहिलेकाहीँ त्यहाँ एक दिन आउँछ जब तपाइँ मेट्रिक्स भण्डारण गर्न आवश्यक छैन। तपाईलाई 5 वर्ष पहिले, एक वा दुई महिना पहिले सङ्कलन गरिएको डेटा किन चाहिन्छ: केही नोडहरू मेटाइएका छन्, केही होस्ट वा मेट्रिकहरू अब आवश्यक पर्दैन किनभने तिनीहरू पुरानो भएका छन् र अब सङ्कलन हुँदैनन्। एउटा राम्रो अनुगमन प्रणालीले ऐतिहासिक डाटा भण्डारण गर्नुपर्छ र डाटाबेस नबढोस् भनेर समय समयमा मेटाउनुपर्छ।

बासी डाटा सफा गर्नु एक महत्वपूर्ण मुद्दा हो जसले डाटाबेसको कार्यसम्पादनमा ठूलो प्रभाव पार्छ।

Zabbix मा क्यास गर्दै

Zabbix मा, पहिलो र दोस्रो कलहरू क्यासिङ प्रयोग गरेर समाधान गरिन्छ। RAM डाटा सङ्कलन र प्रक्रिया गर्न प्रयोग गरिन्छ। भण्डारणको लागि - ट्रिगरहरू, ग्राफहरू र गणना गरिएको डेटा तत्वहरूमा इतिहास। डाटाबेस पक्षमा आधारभूत चयनहरूको लागि केही क्यासिङ छ, उदाहरणका लागि, ग्राफहरू।

Zabbix सर्भरको छेउमा क्यासिङ आफै हो:

• कन्फिगरेसन क्यास;
• ValueCache;
• इतिहास क्यास;
• TrendsCache।

तिनीहरूलाई थप विवरणमा विचार गर्नुहोस्।

कन्फिगरेसन क्यास

यो मुख्य क्यास हो जहाँ हामी मेट्रिक्स, होस्टहरू, डाटा वस्तुहरू, ट्रिगरहरू भण्डार गर्छौं - हामीलाई प्रिप्रोसेसिङ र डाटा सङ्कलनका लागि आवश्यक पर्ने सबै कुरा।

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

तथ्यांक संकलन

रेखाचित्र धेरै ठूलो छ, तर यसमा मुख्य कुरा हो पिकर्स। यी विभिन्न "पोलरहरू" - विधानसभा प्रक्रियाहरू हुन्। तिनीहरू विभिन्न प्रकारका असेंबलीका लागि जिम्मेवार छन्: तिनीहरू SNMP, IPMI मार्फत डेटा सङ्कलन गर्छन्, र सबैलाई PreProcessing मा स्थानान्तरण गर्छन्।

कलेक्टरहरू सुन्तलामा उल्लिखित छन्।

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

पूर्व प्रशोधन इतिहास क्याच

सबै कलेक्टरहरूले कामहरू प्राप्त गर्न कन्फिगरेसन क्याच प्रयोग गर्छन्। त्यसपछि तिनीहरूले तिनीहरूलाई PreProcessing मा स्थानान्तरण।

प्रिप्रोसेसिङले प्रीप्रोसेसिङ चरणहरू प्राप्त गर्न कन्फिगरेसन क्याच प्रयोग गर्दछ। यसले यो डाटालाई विभिन्न तरिकामा प्रशोधन गर्छ।

प्रिप्रोसेसिङ प्रयोग गरेर डाटा प्रशोधन गरेपछि, हामी यसलाई प्रशोधनका लागि HistoryCache मा बचत गर्छौं। यसले डाटा सङ्कलन समाप्त गर्छ र हामी Zabbix मा मुख्य प्रक्रियामा जान्छौं - इतिहास सिङ्कर, किनकि यो एक अखंड वास्तुकला हो।

नोट: प्रिप्रोसेसिङ एकदमै गाह्रो अपरेशन हो। v 4.2 सँग यो प्रोक्सीमा सारिएको छ। यदि तपाईंसँग धेरै संख्यामा डाटा तत्वहरू र सङ्कलन फ्रिक्वेन्सीको साथ धेरै ठूलो Zabbix छ भने, यसले कामलाई धेरै सजिलो बनाउँछ।

ValueCache, इतिहास र प्रवृत्ति क्यास

इतिहास सिङ्कर मुख्य प्रक्रिया हो जसले प्रत्येक डेटा तत्वलाई परमाणु रूपमा प्रशोधन गर्छ, त्यो हो, प्रत्येक मान।

इतिहास सिङ्करले HistoryCache बाट मानहरू लिन्छ र गणनाको लागि ट्रिगरहरूको उपस्थितिको लागि कन्फिगरेसन जाँच गर्दछ। यदि तिनीहरू अवस्थित छन् भने, यसले गणना गर्दछ।

इतिहास सिङ्करले घटना सिर्जना गर्दछ, कन्फिगरेसन र रेकर्डहरू द्वारा आवश्यक भएमा अलर्टहरू सिर्जना गर्न एस्केलेसन। यदि त्यहाँ पछिको प्रशोधनका लागि ट्रिगरहरू छन् भने, त्यसपछि यसले यो मानलाई ValueCache मा भण्डार गर्दछ ताकि इतिहास तालिकामा पहुँच नहोस्। यसरी ValueCache डाटाले भरिएको छ जुन ट्रिगरहरू र गणना गरिएका तत्वहरू गणना गर्न आवश्यक छ।

इतिहास सिङ्करले सबै डाटा डाटाबेसमा लेख्छ, र यसले डिस्कमा लेख्छ। प्रशोधन प्रक्रिया यहाँ समाप्त हुन्छ।

डाटाबेसमा क्यास गर्दै

डाटाबेस साइडमा त्यहाँ विभिन्न क्यासहरू छन् जब तपाइँ घटनाहरूमा ग्राफहरू वा रिपोर्टहरू हेर्न चाहनुहुन्छ:

• Innodb_buffer_pool MySQL पक्षमा;
• shared_buffers PostgreSQL पक्षमा;
• effective_cache_size ओरेकल पक्षमा;
• shared_pool DB2 पक्षमा।

त्यहाँ धेरै अन्य क्यासहरू छन्, तर यी सबै डाटाबेसका लागि मुख्य हुन्। तिनीहरूले तपाईंलाई RAM मा डाटा भण्डारण गर्न अनुमति दिन्छ जुन प्राय: क्वेरीहरूको लागि आवश्यक हुन्छ। यसका लागि तिनीहरूसँग आफ्नै प्रविधिहरू छन्।

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

Zabbix सर्भरले निरन्तर डाटा सङ्कलन गर्दछ र यसलाई लेख्छ। पुन: सुरु गर्दा, यसले ValueCache भर्नको लागि इतिहासबाट पनि पढ्छ। स्क्रिप्ट र रिपोर्टहरू प्रयोग गर्दछ Zabbix API, जुन वेब इन्टरफेसमा निर्मित छ। Zabbix API ले डाटाबेस पहुँच गर्दछ र ग्राफ, रिपोर्ट, घटना सूची र नवीनतम मुद्दाहरूको लागि आवश्यक डाटा पुन: प्राप्त गर्दछ।

दृश्यका लागि - ग्राफाना। यो हाम्रा प्रयोगकर्ताहरू बीच लोकप्रिय समाधान हो। यसले सिधै Zabbix API मार्फत र डाटाबेसमा अनुरोधहरू पठाउन सक्छ, र डाटा प्राप्त गर्नको लागि निश्चित प्रतिस्पर्धा सिर्जना गर्दछ। तसर्थ, नतिजा र परीक्षणको छिटो डेलिभरीसँग मेल खाने डेटाबेसको राम्रो र राम्रो ट्युनिङ आवश्यक छ।

हाउसकिपरको

Zabbix मा तेस्रो प्रदर्शन चुनौती हाउसकीपर प्रयोग गरेर इतिहास क्लियरिङ हो। यसले सबै सेटिङहरू पछ्याउँछ - डेटा तत्वहरूले दिनहरूमा परिवर्तनहरूको गतिशीलता (प्रवृत्ति) कति लामो भण्डारण गर्ने संकेत गर्दछ।

हामी उडानमा TrendsCache गणना गर्छौं। जब डेटा आउँछ, हामी यसलाई एक घण्टाको लागि जम्मा गर्छौं र प्रवृत्ति परिवर्तनहरूको गतिशीलताको लागि तालिकाहरूमा रेकर्ड गर्छौं।

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

रातो ग्राफले इतिहास सिङ्कर निरन्तर व्यस्त रहेको देखाउँछ। शीर्षमा सुन्तला ग्राफ हाउसकीपर हो, जुन निरन्तर चलिरहेको छ। उसले निर्दिष्ट गरेको सबै पङ्क्तिहरू मेटाउनको लागि डेटाबेसको लागि पर्खन्छ।

तपाईले कहिले हाउसकीपरलाई असक्षम गर्नुपर्छ? उदाहरणका लागि, त्यहाँ एउटा "वस्तु ID" छ र तपाईंले निश्चित समय भित्र अन्तिम 5 हजार पङ्क्तिहरू मेटाउन आवश्यक छ। निस्सन्देह, यो सूचकांक द्वारा हुन्छ। तर सामान्यतया डाटासेट धेरै ठूलो छ, र डाटाबेस अझै पनि डिस्कबाट पढ्छ र क्यास मा राख्छ। यो सधैं डाटाबेस को लागी एक धेरै महँगो अपरेशन हो र, डाटाबेस को आकार मा निर्भर गर्दछ, प्रदर्शन समस्या को नेतृत्व गर्न सक्छ।

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

हाउसकीपर बन्द गरिएको थियो, रेखाचित्रहरू समतल गरियो - यस अवस्थामा के समस्या हुन सक्छ र तेस्रो कार्यसम्पादन चुनौती समाधान गर्न मद्दत गर्न सक्छ?

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

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

सामान्यतया, विभाजनहरू "सेटअप" को आधारमा कन्फिगर गरिन्छ - एक दिनमा सिर्जना गरिएको डेटाको मात्रा। एक नियमको रूपमा, विभाजन एक दिनमा जारी गरिएको छ, यो न्यूनतम हो। नयाँ ब्याच को प्रवृत्ति को लागी - 1 महिना।

यदि "सेटअप" धेरै ठूलो छ भने मानहरू परिवर्तन हुन सक्छ। यदि सानो "सेटअप" 5 nvps (नयाँ मान प्रति सेकेन्ड) सम्म छ भने, मध्यम 000 देखि 5 सम्म छ, त्यसपछि ठूलो 000 nvps माथि छ। यी ठूला र धेरै ठूला स्थापनाहरू हुन् जसलाई डाटाबेसको सावधानीपूर्वक कन्फिगरेसन आवश्यक पर्दछ।

धेरै ठूला स्थापनाहरूमा, एक दिनको अवधि इष्टतम नहुन सक्छ। मैले प्रति दिन 40 GB वा बढीको MySQL विभाजनहरू देखेको छु। यो डेटाको धेरै ठूलो मात्रा हो जसले समस्या निम्त्याउन सक्छ र कम गर्न आवश्यक छ।

विभाजनले के दिन्छ?

विभाजन तालिकाहरू। अक्सर यी डिस्कमा अलग फाइलहरू छन्। क्वेरी योजनाले अझ राम्रोसँग एउटा विभाजन चयन गर्छ। सामान्यतया विभाजन दायरा द्वारा प्रयोग गरिन्छ - यो Zabbix को लागि पनि सही छ। हामी त्यहाँ "टाइमस्ट्याम्प" प्रयोग गर्छौं - युगको सुरुदेखिको समय। यी हाम्रा लागि सामान्य संख्याहरू हुन्। तपाईंले दिनको सुरु र अन्त्य सेट गर्नुभयो - यो विभाजन हो।

द्रुत हटाउने - DELETE। मेटाउनका लागि पङ्क्तिहरूको चयनको सट्टा एउटा फाइल/सबटेबल चयन गरिएको छ।

महत्त्वपूर्ण रूपमा डाटा पुन: प्राप्ति गति SELECT - सम्पूर्ण तालिकाको सट्टा एक वा धेरै विभाजनहरू प्रयोग गर्दछ। यदि तपाइँ दुई दिन पुरानो डाटा पहुँच गर्दै हुनुहुन्छ भने, यो डाटाबेसबाट छिटो पुन: प्राप्त हुन्छ किनभने तपाइँ क्यासमा केवल एउटा फाइल लोड गर्न र यसलाई फिर्ता गर्न आवश्यक छ, ठूलो तालिका होइन।

प्रायः धेरै डाटाबेसहरू पनि द्रुत हुन्छन् INSERT - बच्चा तालिका मा सम्मिलन।

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

v 4.2 को लागि, हामीले हाम्रो ध्यान TimescaleDB मा फर्कायौं। यो नेटिभ इन्टरफेस भएको PostgreSQL को लागि विस्तार हो। एक्सटेन्सनले टाइम सीरीज डाटासँग प्रभावकारी रूपमा काम गर्दछ, रिलेशनल डाटाबेसका फाइदाहरू नगुमाईकन। TimescaleDB स्वचालित रूपमा विभाजन गर्दछ।

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

TimescaleDB बनाम PostgreSQL

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

200 मिलियन पङ्क्तिहरू पछि, PostgreSQL सामान्यतया महत्त्वपूर्ण रूपमा घट्न थाल्छ र 0 मा कार्यसम्पादन गुमाउँछ। TimescaleDB ले तपाईंलाई कुनै पनि डेटाको लागि कुशलतापूर्वक "इनसर्टहरू" सम्मिलित गर्न अनुमति दिन्छ।

सेटिङ

TimescaleDB स्थापना कुनै पनि प्याकेजको लागि एकदम सजिलो छ। IN कागजात सबै कुरा विस्तारमा वर्णन गरिएको छ - यो आधिकारिक 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।

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

अन्तिम चरण - UPDATE: at db_extension राख्नु timescaledbताकि डाटाबेसले बुझ्छ कि यो विस्तार अवस्थित छ। Zabbix ले यसलाई सक्रिय गर्दछ र डाटाबेसमा सिन्ट्याक्स र प्रश्नहरू सही रूपमा प्रयोग गर्दछ - ती सुविधाहरू जुन TimescaleDB को लागि आवश्यक छ।

हार्डवेयर कन्फिगरेसन

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

मैले PostgreSQL 10.8 स्थापना गरें Debian 10.8-1.pgdg90+1 OS र xfs फाइल प्रणालीको साथ। मैले यो विशेष डाटाबेस प्रयोग गर्नको लागि न्यूनतम रूपमा सबै कुरा कन्फिगर गरें, Zabbix ले प्रयोग गर्ने कुरा माइनस।

एउटै मेसिनमा Zabbix सर्भर थियो, PostgreSQL र लोड एजेन्टहरू। मसँग 50 सक्रिय एजेन्टहरू थिए जुन प्रयोग गरिरहेका थिए LoadableModuleधेरै छिटो फरक परिणामहरू उत्पन्न गर्न: संख्याहरू, तारहरू। मैले धेरै डाटाले डाटाबेस भरें।

सुरुमा कन्फिगरेसन समावेश छ 5 तत्वहरू प्रति होस्ट डेटा। लगभग हरेक तत्वले यसलाई वास्तविक स्थापनाहरू जस्तै बनाउन ट्रिगर समावेश गर्दछ। केही अवस्थामा त्यहाँ एक भन्दा बढी ट्रिगर थियो। एउटा नेटवर्क नोडको लागि त्यहाँ थिए 3-000 ट्रिगरहरू.

डाटा वस्तु अद्यावधिक अन्तराल - -०-4० सेकेन्ड। मैले 50 एजेन्टहरू मात्र होइन, तर थप थपेर लोड आफैंलाई विनियमित गरें। साथै, डाटा तत्वहरू प्रयोग गरेर, मैले गतिशील रूपमा लोड समायोजन गरें र अपडेट अन्तराललाई 4 सेकेन्डमा घटाए।

PostgreSQL। 35 nvps

यस हार्डवेयरमा मेरो पहिलो रन शुद्ध PostgreSQL मा थियो - 35 हजार मान प्रति सेकेन्ड। तपाईले देख्न सक्नुहुने रूपमा, डेटा सम्मिलित गर्न सेकेन्डको अंश लाग्छ - सबै कुरा राम्रो र छिटो छ। मात्र कुरा यो हो कि 200 GB SSD डिस्क चाँडै भरिन्छ।

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

पहिलो नीलो ग्राफ प्रति सेकेन्ड मानहरूको संख्या हो। दायाँमा दोस्रो ग्राफ निर्माण प्रक्रियाहरूको लोडिङ हो। तेस्रो आन्तरिक निर्माण प्रक्रियाहरू लोड गर्दैछ: इतिहास सिङ्करहरू र हाउसकीपर, जुन यहाँ केही समयदेखि चलिरहेको छ।

चौथो ग्राफले HistoryCache प्रयोग देखाउँछ। यो डाटाबेसमा सम्मिलित गर्नु अघि एक प्रकारको बफर हो। हरियो पाँचौं ग्राफले ValueCache प्रयोग देखाउँछ, त्यो हो, ट्रिगरहरूको लागि कति ValueCache हिट हुन्छ - यो प्रति सेकेन्ड धेरै हजार मानहरू हो।

PostgreSQL। 50 nvps

त्यसपछि मैले एउटै हार्डवेयरमा 50 हजार मान प्रति सेकेन्डमा लोड बढाएँ।

हाउसकीपरबाट लोड गर्दा, १० हजार मान घुसाउन २-३ सेकेन्ड लाग्यो।

घरको कामदारले काममा हस्तक्षेप गर्न थालेको छ।

तेस्रो ग्राफले देखाउँछ कि, सामान्यतया, ट्र्यापर र इतिहास सिङ्करहरूमा लोड अझै 60% मा छ। चौथो ग्राफमा, HistoryCache पहिले नै हाउसकीपर सञ्चालनको क्रममा धेरै सक्रिय रूपमा भर्न थालेको छ। यो 20% भरिएको छ, जुन लगभग 0,5 GB हो।

PostgreSQL। 80 nvps

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

तीस इतिहास सिङ्करहरूको लोडिङ लागत पहिले नै धेरै उच्च छ।

मैले विभिन्न प्यारामिटरहरू पनि बढाएँ: इतिहास सिंकहरू, क्यासहरू।

मेरो हार्डवेयरमा, इतिहास सिंकहरूको लोडिङ अधिकतममा बढ्यो। HistoryCache चाँडै डाटाले भरियो - प्रशोधनका लागि डाटा बफरमा जम्मा भएको थियो।

यो सबै समय मैले प्रोसेसर, र्याम र अन्य प्रणाली प्यारामिटरहरू कसरी प्रयोग गरिन्थ्यो भनेर अवलोकन गरें, र डिस्कको उपयोग अधिकतममा भएको फेला पारे।

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

दोस्रो सर्भर

मैले अर्को सर्भर लिएँ, जसमा पहिले नै 48 प्रोसेसर र 128 GB RAM थियो। मैले यसलाई ट्युन गरें - यसलाई 60 इतिहास सिङ्करमा सेट गरें, र स्वीकार्य प्रदर्शन हासिल गरे।

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

TimescaleDB। 80 nvps

मेरो मुख्य कार्य Zabbix लोड विरुद्ध TimescaleDB को क्षमताहरू परीक्षण गर्नु हो। प्रति सेकेन्ड 80 हजार मानहरू धेरै छन्, मेट्रिक्स सङ्कलन गर्ने आवृत्ति (यान्डेक्स बाहेक, अवश्य पनि) र एकदम ठूलो "सेटअप"।

त्यहाँ प्रत्येक ग्राफ मा एक डुबकी छ - यो ठ्याक्कै डाटा माइग्रेसन हो। Zabbix सर्भरमा विफलता पछि, इतिहास सिङ्करको लोडिङ प्रोफाइल धेरै परिवर्तन भयो - यो तीन पटक घट्यो।

TimescaleDB ले तपाईंलाई लगभग 3 गुणा छिटो डाटा घुसाउन र कम HistoryCache प्रयोग गर्न अनुमति दिन्छ।

तदनुसार, तपाईंले समयमै डाटा प्राप्त गर्नुहुनेछ।

TimescaleDB। 120 nvps

त्यसपछि मैले डेटा तत्वहरूको संख्या 500 हजारमा बढाएँ। मुख्य कार्य TimescaleDB को क्षमताहरू परीक्षण गर्नु थियो - मैले प्रति सेकेन्ड 125 हजार मानहरूको गणना गरिएको मान प्राप्त गरें।

यो काम गर्ने "सेटअप" हो जसले लामो समयसम्म काम गर्न सक्छ। तर मेरो डिस्क मात्र 1,5 TB भएकोले, मैले यसलाई केही दिनमा भरें।

सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि एकै समयमा नयाँ TimescaleDB विभाजनहरू सिर्जना गरियो।

यो प्रदर्शन को लागी पूर्णतया अप्रत्याशित छ। जब विभाजनहरू MySQL मा सिर्जना गरिन्छ, उदाहरणका लागि, सबै कुरा फरक छ। यो सामान्यतया रातमा हुन्छ किनभने यसले सामान्य सम्मिलनलाई रोक्छ, तालिकाहरूसँग काम गर्दछ र सेवामा गिरावट सिर्जना गर्न सक्छ। यो TimescaleDB को मामला होइन।

उदाहरणको रूपमा, म समुदायमा धेरैबाट एउटा ग्राफ देखाउनेछु। तस्विरमा, TimescaleDB सक्षम गरिएको छ, जसको लागि प्रोसेसरमा io.weight प्रयोग गर्ने लोड घटेको छ। आन्तरिक प्रक्रिया तत्वहरूको प्रयोग पनि घट्यो। यसबाहेक, यो साधारण प्यानकेक डिस्कहरूमा एक साधारण भर्चुअल मेसिन हो, SSD होइन।

निष्कर्ष

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

TimescaleDB कन्फिगर गर्न सजिलो छ, प्रदर्शन लाभ दिन्छ, Zabbix र संग राम्रो काम गर्दछ PostgreSQL मा फाइदाहरू छन्.

यदि तपाइँ PostgreSQL प्रयोग गर्नुहुन्छ र यसलाई परिवर्तन गर्ने योजना छैन भने, म सिफारिस गर्दछु Zabbix सँग संयोजनमा TimescaleDB विस्तारको साथ PostgreSQL प्रयोग गर्नुहोस्। यो समाधान प्रभावकारी रूपमा मध्यम "सेटअप" सम्म काम गर्दछ।

जब हामी भन्छौं "उच्च प्रदर्शन" हाम्रो मतलब हाईलोड++। तपाईंले लाखौं प्रयोगकर्ताहरूलाई सेवा दिन सेवाहरू सक्षम पार्ने प्रविधिहरू र अभ्यासहरू बारे जान्नको लागि धेरै समय पर्खनु पर्दैन। सूची रिपोर्टहरू नोभेम्बर 7 र 8 को लागि हामीले पहिले नै कम्पाइल गरेका छौं, तर यहाँ भेटघाटहरू थप सुझाव दिन सकिन्छ।

हाम्रो सदस्यता लिनुहोस् ылку и टेलीग्राम, जसमा हामी आगामी सम्मेलनका विशेषताहरू प्रकट गर्छौं, र यसबाट कसरी अधिकतम लाभ लिने भनेर पत्ता लगाउँछौं।

स्रोत: www.habr.com