उच्च कार्यक्षमता आणि मूळ विभाजन: TimescaleDB समर्थनासह Zabbix

Zabbix एक देखरेख प्रणाली आहे. इतर कोणत्याही प्रणालीप्रमाणे, याला सर्व मॉनिटरिंग सिस्टमच्या तीन मुख्य समस्यांचा सामना करावा लागतो: डेटा गोळा करणे आणि त्यावर प्रक्रिया करणे, इतिहास संग्रहित करणे आणि ते साफ करणे.

डेटा प्राप्त करणे, प्रक्रिया करणे आणि रेकॉर्ड करणे या टप्प्यांमध्ये वेळ लागतो. जास्त नाही, परंतु मोठ्या प्रणालीसाठी याचा परिणाम मोठा विलंब होऊ शकतो. स्टोरेज समस्या ही डेटा ऍक्सेस समस्या आहे. ते अहवाल, तपासणी आणि ट्रिगरसाठी वापरले जातात. डेटा ऍक्सेसमधील विलंब देखील कार्यक्षमतेवर परिणाम करतात. जेव्हा डेटाबेस वाढतात तेव्हा असंबद्ध डेटा हटवावा लागतो. काढून टाकणे हे एक कठीण ऑपरेशन आहे जे काही संसाधने देखील खातात.

Zabbix मधील संकलन आणि संचयन दरम्यान विलंबाच्या समस्या कॅशिंगद्वारे सोडवल्या जातात: अनेक प्रकारचे कॅशे, डेटाबेसमध्ये कॅशिंग. तिसऱ्या समस्येचे निराकरण करण्यासाठी, कॅशिंग योग्य नाही, म्हणून Zabbix ने TimescaleDB वापरले. तो तुम्हाला याबद्दल सांगेल आंद्रे गुश्चिन - तांत्रिक समर्थन अभियंता Zabbix SIA. अँड्री 6 वर्षांहून अधिक काळ झब्बिक्सला समर्थन देत आहे आणि त्याला कामगिरीचा प्रत्यक्ष अनुभव आहे.

TimescaleDB कसे कार्य करते, ते नियमित PostgreSQL च्या तुलनेत काय कार्यप्रदर्शन देऊ शकते? TimescaleDB डेटाबेससाठी Zabbix काय भूमिका बजावते? सुरवातीपासून कसे सुरू करावे आणि PostgreSQL वरून कसे स्थलांतर करावे आणि कोणत्या कॉन्फिगरेशनची कार्यक्षमता चांगली आहे? कट अंतर्गत या सर्व बद्दल.

उत्पादकता आव्हाने

प्रत्येक मॉनिटरिंग सिस्टमला विशिष्ट कार्यप्रदर्शन आव्हानांचा सामना करावा लागतो. मी त्यापैकी तीन बद्दल बोलेन: डेटा संकलन आणि प्रक्रिया, संचयन आणि इतिहास साफ करणे.

जलद डेटा संकलन आणि प्रक्रिया. चांगल्या मॉनिटरिंग सिस्टमने सर्व डेटा त्वरीत प्राप्त केला पाहिजे आणि ट्रिगर अभिव्यक्तीनुसार - त्याच्या निकषांनुसार त्यावर प्रक्रिया केली पाहिजे. प्रक्रिया केल्यानंतर, प्रणालीने नंतरच्या वापरासाठी डेटाबेसमध्ये हा डेटा त्वरीत जतन करणे देखील आवश्यक आहे.

इतिहास संचयन. चांगल्या मॉनिटरिंग सिस्टमने इतिहास डेटाबेसमध्ये संग्रहित केला पाहिजे आणि मेट्रिक्समध्ये सहज प्रवेश प्रदान केला पाहिजे. अहवाल, आलेख, ट्रिगर, थ्रेशहोल्ड आणि गणना केलेल्या अलर्ट डेटा आयटममध्ये इतिहासाचा वापर करणे आवश्यक आहे.

इतिहास साफ करत आहे. कधीकधी असा दिवस येतो जेव्हा आपल्याला मेट्रिक्स संचयित करण्याची आवश्यकता नसते. तुम्हाला 5 वर्षांपूर्वी, एक किंवा दोन महिन्यांपूर्वी गोळा केलेला डेटा का हवा आहे: काही नोड हटवले गेले आहेत, काही होस्ट किंवा मेट्रिक्सची यापुढे आवश्यकता नाही कारण ते कालबाह्य झाले आहेत आणि यापुढे संकलित केले जाणार नाहीत. चांगल्या मॉनिटरिंग सिस्टमने ऐतिहासिक डेटा संग्रहित केला पाहिजे आणि वेळोवेळी तो हटवला पाहिजे जेणेकरून डेटाबेस वाढू नये.

जुना डेटा साफ करणे ही एक गंभीर समस्या आहे जी डेटाबेस कार्यक्षमतेवर मोठ्या प्रमाणात परिणाम करते.

Zabbix मध्ये कॅशिंग

Zabbix मध्ये, पहिला आणि दुसरा कॉल कॅशिंग वापरून सोडवला जातो. डेटा गोळा करण्यासाठी आणि त्यावर प्रक्रिया करण्यासाठी RAM चा वापर केला जातो. स्टोरेजसाठी - ट्रिगर, आलेख आणि गणना केलेल्या डेटा घटकांमधील इतिहास. डेटाबेसच्या बाजूला मूलभूत निवडीसाठी काही कॅशिंग आहे, उदाहरणार्थ, आलेख.

Zabbix सर्व्हरच्या बाजूला कॅशिंग स्वतः आहे:

• कॉन्फिगरेशन कॅशे;
• ValueCache;
• हिस्ट्री कॅशे;
• TrendsCache.

चला त्यांचा अधिक तपशीलवार विचार करूया.

कॉन्फिगरेशन कॅशे

हे मुख्य कॅशे आहे जेथे आम्ही मेट्रिक्स, होस्ट, डेटा आयटम, ट्रिगर्स - प्रीप्रोसेसिंग आणि डेटा संकलनासाठी आवश्यक असलेली प्रत्येक गोष्ट संग्रहित करतो.

डेटाबेसमध्ये अनावश्यक प्रश्न निर्माण होऊ नयेत म्हणून हे सर्व कॉन्फिगरेशन कॅशेमध्ये साठवले जाते. सर्व्हर सुरू झाल्यानंतर, आम्ही ही कॅशे अपडेट करतो, कॉन्फिगरेशन तयार करतो आणि वेळोवेळी अपडेट करतो.

माहिती संकलन

आकृती बरीच मोठी आहे, परंतु त्यातील मुख्य गोष्ट आहे पिकर्स. हे विविध "पोलर्स" आहेत - असेंब्ली प्रक्रिया. ते वेगवेगळ्या प्रकारच्या असेंब्लीसाठी जबाबदार आहेत: ते SNMP, IPMI द्वारे डेटा संकलित करतात आणि ते सर्व प्रीप्रोसेसिंगमध्ये हस्तांतरित करतात.

संग्राहक नारिंगी मध्ये रेखांकित आहेत.

Zabbix ने एकत्रीकरण आयटमची गणना केली आहे ज्यांची एकत्रित तपासणी करण्यासाठी आवश्यक आहे. आमच्याकडे ते असल्यास, आम्ही त्यांच्यासाठी थेट ValueCache वरून डेटा आणतो.

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

सर्व संग्राहक नोकऱ्या प्राप्त करण्यासाठी कॉन्फिगरेशन कॅशे वापरतात. मग ते त्यांना प्रीप्रोसेसिंगमध्ये स्थानांतरित करतात.

प्रीप्रोसेसिंग प्रीप्रोसेसिंग चरण प्राप्त करण्यासाठी कॉन्फिगरेशन कॅशे वापरते. ते या डेटावर विविध प्रकारे प्रक्रिया करते.

प्रीप्रोसेसिंग वापरून डेटावर प्रक्रिया केल्यानंतर, आम्ही प्रक्रियेसाठी तो हिस्ट्री कॅशेमध्ये सेव्ह करतो. यामुळे डेटा संकलन समाप्त होते आणि आम्ही Zabbix मधील मुख्य प्रक्रियेकडे जातो - इतिहास समक्रमण, कारण ते एक अखंड वास्तुकला आहे.

टीप: प्रीप्रोसेसिंग हे एक कठीण ऑपरेशन आहे. v 4.2 सह ते प्रॉक्सीमध्ये हलविले गेले आहे. जर तुमच्याकडे मोठ्या संख्येने डेटा घटक आणि संकलन वारंवारता असलेले खूप मोठे Zabbix असेल, तर हे काम खूप सोपे करते.

ValueCache, इतिहास आणि ट्रेंड कॅशे

इतिहास समक्रमण ही मुख्य प्रक्रिया आहे जी प्रत्येक डेटा घटकावर, म्हणजेच प्रत्येक मूल्यावर परमाणु प्रक्रिया करते.

हिस्ट्री सिंकर हिस्ट्री कॅशे मधून मूल्ये घेते आणि गणनासाठी ट्रिगरच्या उपस्थितीसाठी कॉन्फिगरेशन तपासते. ते अस्तित्वात असल्यास, ते गणना करते.

इतिहास समक्रमण एक इव्हेंट तयार करतो, कॉन्फिगरेशन आणि रेकॉर्डद्वारे आवश्यक असल्यास अॅलर्ट तयार करण्यासाठी एस्केलेशन. त्यानंतरच्या प्रक्रियेसाठी ट्रिगर असल्यास, ते हे मूल्य 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 गणना करतो. जेव्हा डेटा येतो, तेव्हा आम्ही ते एका तासासाठी एकत्रित करतो आणि ट्रेंड बदलांच्या गतिशीलतेसाठी ते टेबलमध्ये रेकॉर्ड करतो.

हाऊसकीपर नेहमीच्या "सिलेक्ट्स" वापरून डेटाबेसमधून माहिती सुरू करतो आणि हटवतो. हे नेहमीच प्रभावी नसते, जसे की अंतर्गत प्रक्रियांच्या कामगिरीच्या आलेखांवरून पाहिले जाऊ शकते.

लाल आलेख दाखवतो की हिस्ट्री सिंकर सतत व्यस्त असतो. शीर्षस्थानी नारिंगी आलेख हाऊसकीपर आहे, जो सतत चालू असतो. तो डेटाबेसने निर्दिष्ट केलेल्या सर्व पंक्ती हटविण्याची प्रतीक्षा करतो.

तुम्ही हाऊसकीपर कधी अक्षम करावे? उदाहरणार्थ, एक "आयटम आयडी" आहे आणि तुम्हाला शेवटच्या 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 टीबी झाला होता, ज्याने एक तास घेतला. जरी काही प्रकरणांमध्ये, चाचणी दरम्यान, स्टोरेजसाठी आवश्यक नसलेल्या वर्ण प्रकारांचा ऐतिहासिक डेटा मी हटवला, जेणेकरून ते हस्तांतरित करू नये.

शेवटचा टप्पा - UPDATE: येथे db_extension टाकणे timescaledbजेणेकरून डेटाबेसला समजेल की हा विस्तार अस्तित्वात आहे. Zabbix ते सक्रिय करते आणि डेटाबेसमध्ये वाक्यरचना आणि क्वेरी योग्यरित्या वापरते - ती वैशिष्ट्ये जी TimescaleDB साठी आवश्यक आहेत.

हार्डवेअर कॉन्फिगरेशन

मी दोन सर्व्हर वापरले. पहिला - VMware मशीन. हे अगदी लहान आहे: 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 स्थापित केले. या विशिष्ट डेटाबेसचा वापर करण्यासाठी मी सर्वकाही कमीत कमी कॉन्फिगर केले आहे, Zabbix स्वतः काय वापरेल.

त्याच मशीनवर एक Zabbix सर्व्हर होता, PostgreSQL आणि लोड एजंट. माझ्याकडे 50 सक्रिय एजंट होते जे वापरत होते LoadableModuleखूप लवकर भिन्न परिणाम निर्माण करण्यासाठी: संख्या, तार. मी डेटाबेसमध्ये भरपूर डेटा भरला.

सुरुवातीला कॉन्फिगरेशन समाविष्ट होते 5 घटक प्रति यजमान डेटा. जवळजवळ प्रत्येक घटकामध्ये वास्तविक इंस्टॉलेशन्स सारखे बनवण्यासाठी ट्रिगर आहे. काही प्रकरणांमध्ये एकापेक्षा जास्त ट्रिगर होते. एका नेटवर्क नोडसाठी होते 3-000 ट्रिगर.

डेटा आयटम अपडेट अंतराल − 4-7 सेकंद. मी केवळ 50 एजंट वापरूनच नव्हे तर आणखी जोडून लोड स्वतःच नियंत्रित केले. तसेच, डेटा घटकांचा वापर करून, मी गतिमानपणे लोड समायोजित केले आणि अद्यतन मध्यांतर 4 s पर्यंत कमी केले.

PostgreSQL. 35 एनव्हीपीएस

या हार्डवेअरवर माझी पहिली धाव शुद्ध PostgreSQL वर होती - 35 हजार मूल्ये प्रति सेकंद. जसे आपण पाहू शकता, डेटा घालण्यासाठी सेकंदाचा काही अंश लागतो - सर्वकाही चांगले आणि जलद आहे. एकच गोष्ट अशी आहे की 200 GB SSD डिस्क त्वरीत भरते.

हा एक मानक Zabbix सर्व्हर कामगिरी डॅशबोर्ड आहे.

पहिला निळा आलेख प्रति सेकंद मूल्यांची संख्या आहे. उजवीकडील दुसरा आलेख बिल्ड प्रक्रियेचे लोडिंग आहे. तिसरी अंतर्गत बिल्ड प्रक्रिया लोड होत आहे: हिस्ट्री सिंकर्स आणि हाऊसकीपर, जे येथे बर्‍याच काळापासून चालू आहे.

चौथा आलेख HistoryCache चा वापर दाखवतो. डेटाबेसमध्ये टाकण्यापूर्वी हा एक प्रकारचा बफर आहे. हिरवा पाचवा आलेख ValueCache चा वापर दर्शवतो, म्हणजेच ट्रिगर्ससाठी किती ValueCache हिट होतो - हे प्रति सेकंद अनेक हजार मूल्ये आहेत.

PostgreSQL. 50 एनव्हीपीएस

मग मी त्याच हार्डवेअरवर लोड 50 हजार व्हॅल्यू प्रति सेकंदापर्यंत वाढवले.

हाऊसकीपरकडून लोड करताना, 10 हजार मूल्ये घालण्यासाठी 2-3 सेकंद लागले.

घरकाम करणारा आधीच कामात व्यत्यय आणू लागला आहे.

तिसरा आलेख दर्शवितो की, सर्वसाधारणपणे, ट्रॅपर्स आणि हिस्ट्री सिंकर्सवर भार अजूनही 60% आहे. चौथ्या आलेखामध्ये, हाऊसकीपर ऑपरेशन दरम्यान हिस्ट्री कॅशे आधीच सक्रियपणे भरण्यास सुरुवात केली आहे. ते 20% भरले आहे, जे सुमारे 0,5 GB आहे.

PostgreSQL. 80 एनव्हीपीएस

मग मी भार प्रति सेकंद 80 हजार मूल्यांपर्यंत वाढविला. हे अंदाजे 400 हजार डेटा घटक आणि 280 हजार ट्रिगर्स आहेत.

तीस हिस्ट्री सिंकर्सची लोडिंग किंमत आधीच खूप जास्त आहे.

मी विविध पॅरामीटर्स देखील वाढवले ​​आहेत: इतिहास समक्रमण, कॅशे.

माझ्या हार्डवेअरवर, हिस्ट्री सिंकर्सचे लोडिंग कमाल झाले. हिस्ट्री कॅशे त्वरीत डेटाने भरले - प्रक्रियेसाठी डेटा बफरमध्ये जमा झाला होता.

या सर्व वेळी मी प्रोसेसर, रॅम आणि इतर सिस्टीम पॅरामीटर्स कसे वापरले जातात ते पाहिले आणि डिस्कचा जास्तीत जास्त वापर झाल्याचे आढळले.

मी उपयोग साधला आहे कमाल डिस्क क्षमता या हार्डवेअरवर आणि या आभासी मशीनवर. अशा तीव्रतेसह, PostgreSQL ने डेटा सक्रियपणे फ्लश करण्यास सुरुवात केली आणि डिस्कला आता लिहिण्यास आणि वाचण्यास वेळ मिळाला नाही.

दुसरा सर्व्हर

मी दुसरा सर्व्हर घेतला, ज्यात आधीच ४८ प्रोसेसर आणि १२८ जीबी रॅम आहे. मी ते ट्यून केले - ते 48 हिस्ट्री सिंकरवर सेट केले आणि स्वीकार्य कामगिरी प्राप्त केली.

खरं तर, ही उत्पादकतेची मर्यादा आहे जिथे काहीतरी करणे आवश्यक आहे.

TimescaleDB. 80 एनव्हीपीएस

Zabbix लोड विरुद्ध TimescaleDB ची क्षमता तपासणे हे माझे मुख्य कार्य आहे. प्रति सेकंद 80 हजार मूल्ये खूप आहेत, मेट्रिक्स गोळा करण्याची वारंवारता (यांडेक्स वगळता, अर्थातच) आणि बर्‍यापैकी मोठा “सेटअप”.

प्रत्येक आलेखामध्ये एक डुबकी आहे - हे तंतोतंत डेटा स्थलांतर आहे. Zabbix सर्व्हरमध्ये अयशस्वी झाल्यानंतर, इतिहास सिंकरचे लोडिंग प्रोफाइल बरेच बदलले - ते तीन वेळा घसरले.

TimescaleDB तुम्हाला जवळपास 3 पट वेगाने डेटा घालण्याची आणि कमी HistoryCache वापरण्याची परवानगी देते.

त्यानुसार, तुम्हाला वेळेवर डेटा प्राप्त होईल.

TimescaleDB. 120 एनव्हीपीएस

मग मी डेटा घटकांची संख्या 500 हजारांपर्यंत वाढवली. मुख्य कार्य TimescaleDB च्या क्षमतांची चाचणी घेणे होते - मला प्रति सेकंद 125 हजार मूल्यांचे गणना केलेले मूल्य प्राप्त झाले.

हा एक कार्यरत "सेटअप" आहे जो बर्याच काळासाठी कार्य करू शकतो. पण माझी डिस्क फक्त 1,5 TB असल्याने मी ती काही दिवसात भरली.

सर्वात महत्वाची गोष्ट म्हणजे त्याच वेळी नवीन TimescaleDB विभाजने तयार केली गेली.

कार्यक्षमतेसाठी हे पूर्णपणे लक्षात घेण्यासारखे नाही. जेव्हा MySQL मध्ये विभाजने तयार केली जातात, उदाहरणार्थ, सर्वकाही वेगळे असते. हे सहसा रात्री घडते कारण ते सामान्य प्रवेश अवरोधित करते, टेबलसह कार्य करते आणि सेवा निकृष्ट दर्जा निर्माण करू शकते. TimescaleDB च्या बाबतीत असे नाही.

उदाहरण म्हणून मी समाजातील अनेकांचा एक आलेख दाखवतो. चित्रात, TimescaleDB सक्षम आहे, ज्यामुळे प्रोसेसरवरील io.weight वापरण्याचा भार कमी झाला आहे. अंतर्गत प्रक्रिया घटकांचा वापर देखील कमी झाला. शिवाय, हे सामान्य पॅनकेक डिस्कवरील एक सामान्य आभासी मशीन आहे, SSD नाही.

निष्कर्ष

TimescaleDB हा लहान "सेटअप" साठी चांगला उपाय आहे, जे डिस्क कार्यक्षमतेवर परिणाम करतात. डेटाबेस शक्य तितक्या लवकर हार्डवेअरमध्ये स्थलांतरित होईपर्यंत हे तुम्हाला चांगले कार्य करण्यास अनुमती देईल.

TimescaleDB कॉन्फिगर करणे सोपे आहे, कामगिरी वाढवते, Zabbix सह चांगले कार्य करते आणि PostgreSQL वर फायदे आहेत.

तुम्ही PostgreSQL वापरत असल्यास आणि ते बदलण्याची योजना नसल्यास, मी शिफारस करतो Zabbix च्या संयोगाने TimescaleDB विस्तारासह PostgreSQL वापरा. हे समाधान मध्यम "सेटअप" पर्यंत प्रभावीपणे कार्य करते.

जेव्हा आपण "उच्च कार्यप्रदर्शन" म्हणतो तेव्हा आपला अर्थ होतो HighLoad++. लाखो वापरकर्त्यांना सेवा देण्यासाठी सेवा सक्षम करणाऱ्या तंत्रज्ञान आणि पद्धतींबद्दल जाणून घेण्यासाठी तुम्हाला जास्त वेळ प्रतीक्षा करावी लागणार नाही. यादी अहवाल नोव्हेंबर 7 आणि 8 साठी आम्ही आधीच संकलित केले आहे, परंतु येथे भेटीगाठी अधिक सुचवले जाऊ शकते.

आमच्या सदस्यता घ्या ылку и तार, ज्यामध्ये आम्ही आगामी परिषदेची वैशिष्ट्ये प्रकट करतो आणि त्यातून जास्तीत जास्त कसे मिळवायचे ते शोधू.

स्त्रोत: www.habr.com