अनुप्रयोगों में विशिष्ट त्रुटियाँ जो पोस्टग्रेस्क्ल में सूजन का कारण बनती हैं। एंड्री सालनिकोव

मेरा सुझाव है कि आप एंड्री साल्निकोव की 2016 की शुरुआत की रिपोर्ट की प्रतिलेख पढ़ें "अनुप्रयोगों में विशिष्ट त्रुटियां जो पोस्टग्रेस्क्ल में ब्लोट का कारण बनती हैं"

इस रिपोर्ट में, मैं एप्लिकेशन में मुख्य त्रुटियों का विश्लेषण करूंगा जो एप्लिकेशन कोड को डिजाइन करने और लिखने के चरण में उत्पन्न होती हैं। और मैं केवल उन्हीं त्रुटियों को लूँगा जिनके कारण Postgresql में सूजन आ जाती है। एक नियम के रूप में, यह समग्र रूप से आपके सिस्टम के प्रदर्शन के अंत की शुरुआत है, हालाँकि शुरुआत में इसके लिए कोई पूर्वापेक्षाएँ दिखाई नहीं दे रही थीं।

सभी का स्वागत करते हुए खुशी हो रही है! यह रिपोर्ट मेरे सहयोगी की पिछली रिपोर्ट जितनी तकनीकी नहीं है। यह रिपोर्ट मुख्य रूप से बैकएंड सिस्टम डेवलपर्स पर लक्षित है क्योंकि हमारे पास काफी बड़ी संख्या में ग्राहक हैं। और वे सभी एक जैसी गलतियाँ करते हैं। मैं आपको उनके बारे में बताऊंगा. मैं समझाऊंगा कि ये गलतियाँ किन घातक और बुरी चीजों का कारण बनती हैं।

गलतियाँ क्यों की जाती हैं? वे दो कारणों से किए जाते हैं: यादृच्छिक रूप से, शायद यह काम करेगा और डेटाबेस और एप्लिकेशन के बीच के स्तर पर और साथ ही डेटाबेस में होने वाले कुछ तंत्रों की अज्ञानता के कारण।

मैं आपको भयानक चित्रों के साथ तीन उदाहरण दूँगा कि चीजें कितनी बुरी हो गईं। मैं आपको वहां होने वाले तंत्र के बारे में संक्षेप में बताऊंगा। और उनसे कैसे निपटना है, वे कब घटित हुईं, और गलतियों को रोकने के लिए कौन से निवारक तरीकों का उपयोग करना है। मैं आपको सहायक उपकरणों के बारे में बताऊंगा और उपयोगी लिंक प्रदान करूंगा।

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

प्लेट का प्रारंभिक डेटा: यह काफी छोटा है, 2 एमबी। डेटाबेस और विशेष रूप से साइन के लिए प्रतिक्रिया समय भी बहुत अच्छा है। और काफी अच्छा लोड - प्लेट के अनुसार प्रति सेकंड 2 ऑपरेशन।

और इस रिपोर्ट के माध्यम से मैं आपको ग्राफ़ दिखाऊंगा ताकि आप स्पष्ट रूप से समझ सकें कि क्या हो रहा है। ग्राफ़ के साथ हमेशा 2 स्लाइड होंगी। पहली स्लाइड वह है जो सामान्यतः सर्वर पर होती है।

और इस स्थिति में, हम देखते हैं कि हमारे पास वास्तव में एक छोटा सा संकेत है। सूचकांक 2 एमबी पर छोटा है. यह बाईं ओर पहला ग्राफ़ है.

सर्वर पर औसत प्रतिक्रिया समय भी स्थिर और कम है। यह शीर्ष दाहिना ग्राफ़ है.

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

दूसरी स्लाइड हमेशा परीक्षण की जा रही प्लेट को समर्पित होगी। इस स्थिति में, हम ग्राहक के खाते की शेष राशि को लगातार अपडेट करते रहते हैं। और हम देखते हैं कि अपडेट ऑपरेशन के लिए औसत प्रतिक्रिया समय काफी अच्छा है, एक मिलीसेकंड से भी कम। हम देखते हैं कि प्रोसेसर संसाधन (यह ऊपरी दाहिना ग्राफ है) भी समान रूप से और काफी कम खपत होते हैं।

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

और अब हमारे सामने एक त्रासदी है. किसी कारण से कोई लंबे समय से भूला हुआ लेन-देन हुआ है। कारण आमतौर पर सभी साधारण होते हैं:

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

ऐसी बातें कहां ले जाती हैं?

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

और देखते हैं क्या होता है. नीचे बाएँ ग्राफ़ से पता चलता है कि हमारे पास एक लंबा लेन-देन है। और यदि हम ऊपरी बाएँ ग्राफ़ को देखें, तो हम देखते हैं कि हमारी तालिका का आकार अचानक दो मेगाबाइट से बढ़कर 300 मेगाबाइट हो गया है। साथ ही, तालिका में डेटा की मात्रा नहीं बदली है, यानी वहां काफी बड़ी मात्रा में कचरा है।

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

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

हमें जीवन में वापस आने की जरूरत है। हम ऑनलाइन जाते हैं और पाते हैं कि लंबे लेन-देन से समस्याएं पैदा होती हैं। हम इस लेन-देन को ढूंढते हैं और ख़त्म कर देते हैं। और हमारे लिए सब कुछ सामान्य होता जा रहा है. हर चीज़ वैसे ही काम कर रही है जैसी उसे करनी चाहिए।

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

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

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

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

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

और यह समझने के लिए कि वहां क्या हो रहा है, यदि आप पिछली रिपोर्ट में नहीं थे, तो अब थोड़ा सिद्धांत प्राप्त करें। आंतरिक प्रक्रिया के बारे में सिद्धांत. कार वैक्यूम क्यों और यह क्या करता है?

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

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

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

दुर्घटना के दौरान क्या हुआ? वहां ये प्रक्रिया कैसे हुई?

हमारे पास कुछ हालत में एक संकेत था, कुछ जीवित, कुछ मृत रेखाएँ। कार वैक्यूम आ गया है. उन्होंने डेटाबेस से पूछा कि हमारा सबसे पुराना लेनदेन क्या है और इसकी आईडी क्या है। यह आईडी मुझे कई घंटे पहले, शायद दस मिनट पहले मिली थी। यह इस बात पर निर्भर करता है कि आपके डेटाबेस पर कितना भारी भार है। और वह उन पंक्तियों की तलाश में लग गया जिन्हें वह पुन: उपयोग के रूप में चिह्नित कर सके। और मुझे हमारी तालिका में ऐसी पंक्तियाँ नहीं मिलीं।

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

वास्तव में, हमें काम करने के लिए हरी रेखाओं की आवश्यकता है। लेकिन ऐसी समस्या के दौरान, यह पता चलता है कि संपूर्ण तालिका में हरी रेखाओं का प्रतिशत बेहद कम है।

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

हमारे लिए इसके क्या परिणाम हो सकते हैं?

• मेरे उदाहरण में, तालिका और सूचकांक 150 गुना बढ़ गए। हमारे कुछ ग्राहकों के साथ ऐसे और भी घातक मामले सामने आए हैं जब उनके पास डिस्क स्थान ख़त्म होने लगा।
• टेबलों का आकार कभी कम नहीं होगा. कुछ मामलों में ऑटोवैक्यूम टेबल की पूंछ को काट सकता है यदि केवल मृत रेखाएं हों। लेकिन चूँकि निरंतर घूर्णन होता रहता है, एक हरी रेखा अंत में रुक सकती है और अद्यतन नहीं हो सकती है, जबकि अन्य सभी प्लेट की शुरुआत में कहीं लिखी होंगी। लेकिन यह इतनी अप्रत्याशित घटना है कि आपकी टेबल का आकार ही छोटा हो जाएगा, इसलिए आपको इसकी उम्मीद नहीं करनी चाहिए।
• डेटाबेस को बेकार लाइनों के एक पूरे समूह को क्रमबद्ध करने की आवश्यकता है। और हम डिस्क संसाधनों को बर्बाद करते हैं, हम प्रोसेसर संसाधनों और बिजली को बर्बाद करते हैं।
• और इसका सीधा असर हमारे एप्लिकेशन पर पड़ता है, क्योंकि अगर शुरुआत में हमने अनुरोध पर 10 मिलीसेकंड, अपने कोड पर 10 मिलीसेकंड खर्च किए, तो क्रैश के दौरान हमने अनुरोध पर एक सेकंड और कोड पर 10 मिलीसेकंड खर्च करना शुरू कर दिया, यानी एक ऑर्डर। अनुप्रयोग प्रदर्शन में परिमाण में कमी आई। और जब दुर्घटना का समाधान हो गया, तो हमने एक अनुरोध पर 20 मिलीसेकंड और एक कोड पर 10 मिलीसेकंड खर्च करना शुरू कर दिया। इसका मतलब यह है कि हमारी उत्पादकता में अभी भी डेढ़ गुना गिरावट आई है। और यह सब एक लेन-देन के कारण है जो रुक गया, शायद हमारी गलती के कारण।
• और सवाल: "हम सब कुछ कैसे वापस पा सकते हैं?" ताकि हमारे साथ सब कुछ ठीक रहे और अनुरोध दुर्घटना से पहले की तरह जल्दी से आ जाएं।

इस प्रयोजन के लिए कार्य का एक निश्चित चक्र चलाया जाता है।

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

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

आपके लिए क्या अधिक सुविधाजनक है इसके आधार पर उनका उपयोग किया जाता है। लेकिन मैं आपको इसके बारे में सबसे अंत में बताऊंगा। मुख्य बात यह है कि तीन उपकरण हैं। चुनने के लिए बहुत कुछ है.

जब हमने सब कुछ ठीक कर लिया और यह सुनिश्चित कर लिया कि सब कुछ ठीक है, तो हमें पता होना चाहिए कि भविष्य में इस स्थिति को कैसे रोका जाए:

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

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

तालिका का आकार तुरंत कुछ मेगाबाइट की अपनी सामान्य परिचालन स्थिति में वापस आ गया। इससे सर्वर के औसत प्रतिक्रिया समय पर बहुत अधिक प्रभाव नहीं पड़ा।

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

यहीं पर पहली कहानी ख़त्म होती है. यह सबसे आम है. और यह हर किसी के साथ होता है, चाहे ग्राहक का अनुभव कुछ भी हो और प्रोग्रामर कितने योग्य हों। देर-सबेर ऐसा होता है.

दूसरी कहानी, जिसमें हम लोड वितरित करते हैं और सर्वर संसाधनों का अनुकूलन करते हैं

• हम पहले ही बड़े हो चुके हैं और गंभीर लोग बन गए हैं। और हम समझते हैं कि हमारे पास एक प्रतिकृति है और हमारे लिए लोड को संतुलित करना अच्छा होगा: मास्टर को लिखें, और प्रतिकृति से पढ़ें। और आमतौर पर यह स्थिति तब उत्पन्न होती है जब हम कोई रिपोर्ट या ईटीएल तैयार करना चाहते हैं। और बिजनेस इस बात से काफी खुश है. वह वास्तव में बहुत सारे जटिल विश्लेषण के साथ विभिन्न प्रकार की रिपोर्ट चाहता है।
• रिपोर्ट में कई घंटे लगते हैं, क्योंकि जटिल विश्लेषण की गणना मिलीसेकेंड में नहीं की जा सकती। हम, बहादुर लोगों की तरह, कोड लिखते हैं। इंसर्शन एप्लिकेशन में हम मास्टर पर रिकॉर्डिंग करते हैं, और प्रतिकृति पर रिपोर्ट निष्पादित करते हैं।
• भार वितरण.
• सब कुछ पूरी तरह से काम करता है. महान थे।

और यह स्थिति कैसी दिखती है? विशेष रूप से इन ग्राफ़ पर, मैंने लेन-देन की अवधि के लिए प्रतिकृति से लेन-देन की अवधि भी जोड़ी। अन्य सभी ग्राफ़ केवल मास्टर सर्वर को संदर्भित करते हैं।

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

विशेष रूप से, परीक्षण की गई प्लेट के अनुसार, हम वहां खाता शेष को अद्यतन करना जारी रखते हैं। और हमारे पास अनुरोधों के लिए एक स्थिर प्रतिक्रिया समय, स्थिर संसाधन खपत भी है। हमारे साथ सब कुछ ठीक है.

जब तक प्रतिकृति के साथ टकराव के कारण ये रिपोर्टें प्रतिक्रिया स्वरूप शुरू नहीं हो जातीं, तब तक सब कुछ ठीक है। और वे नियमित अंतराल पर जवाबी गोलीबारी करते हैं।

हम ऑनलाइन जाते हैं और पढ़ना शुरू करते हैं कि ऐसा क्यों हो रहा है। और हम एक समाधान ढूंढते हैं.

पहला समाधान प्रतिकृति विलंबता को बढ़ाना है। हम जानते हैं कि हमारी रिपोर्ट 3 घंटे तक चलती है। हमने प्रतिकृति विलंब को 3 घंटे पर सेट किया है। हम सब कुछ लॉन्च कर रहे हैं, लेकिन हमें अभी भी कभी-कभी रिपोर्ट रद्द होने की समस्या आ रही है।

हम चाहते हैं कि सबकुछ परफेक्ट हो. हम और आगे चढ़ते हैं। और हमें इंटरनेट पर एक बढ़िया सेटिंग मिली - hot_standby_feedback। आइए इसे चालू करें. Hot_standby_feedback हमें मास्टर पर ऑटोवैक्यूम को रोकने की अनुमति देता है। इस प्रकार, हम प्रतिकृति संघर्षों से पूरी तरह छुटकारा पा लेते हैं। और रिपोर्ट के साथ हमारे लिए सब कुछ अच्छा काम करता है।

और इस समय मास्टर सर्वर के साथ क्या हो रहा है? और हम मास्टर सर्वर से पूरी तरह परेशान हैं। अब हम ग्राफ़ देख रहे हैं जब मेरे पास ये दोनों सेटिंग्स सक्षम हैं। और हम देखते हैं कि हमारी प्रतिकृति पर सत्र किसी तरह मास्टर सर्वर पर स्थिति को प्रभावित करने लगा। उसका प्रभाव पड़ता है क्योंकि उसने ऑटोवैक्यूम को रोक दिया है, जिससे मृत रेखाएं साफ हो जाती हैं। हमारी टेबल का आकार फिर से आसमान छू गया है। संपूर्ण डेटाबेस में औसत क्वेरी निष्पादन समय भी आसमान छू गया। ऑटोवैक्यूम थोड़ा कड़ा हो गया।

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

यदि हम नहीं जानते कि मैं पहले किस बारे में बात कर रहा था तो यह कैसा दिखेगा?

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

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

सत्र ख़त्म हो गया है. और कुछ समय बाद ही सर्वर कमोबेश ठीक हो जाता है। और मास्टर सर्वर पर अनुरोधों के लिए औसत प्रतिक्रिया समय सामान्य हो जाता है। क्योंकि, अंततः, ऑटोवैक्यूम के पास इन मृत रेखाओं को साफ करने और चिह्नित करने का अवसर है। और वह अपना काम करने लगा. और वह इसे कितनी जल्दी करेगा, इतनी जल्दी हम व्यवस्थित हो जायेंगे।

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

किसी भी स्थिति में, हमें प्रदर्शन में गिरावट मिलती है, जैसा कि पहले मामले में, डेढ़ से दो गुना तक, और कभी-कभी इससे भी अधिक।

ऐसा लगता है कि हमने सब कुछ ठीक किया है। भार बांटो. उपकरण निष्क्रिय नहीं है. हमने अनुरोधों को अपने मन के अनुसार विभाजित किया, लेकिन फिर भी सब कुछ खराब निकला।

• hot_standby_feedback सक्षम न करें? हां, विशेष रूप से मजबूत कारणों के बिना इसे चालू करने की अनुशंसा नहीं की जाती है। क्योंकि यह मोड़ सीधे मास्टर सर्वर को प्रभावित करता है और वहां ऑटोवैक्यूम के संचालन को निलंबित कर देता है। इसे किसी प्रतिकृति पर सक्षम करके और इसके बारे में भूलकर, आप मास्टर को मार सकते हैं और एप्लिकेशन के साथ बड़ी समस्याएं प्राप्त कर सकते हैं।
• अधिकतम_स्टैंडबाय_स्ट्रीमिंग_देरी बढ़ाएँ? हाँ, रिपोर्टों के लिए यह सच है। यदि आपके पास तीन घंटे की रिपोर्ट है और आप नहीं चाहते कि प्रतिकृति विवादों के कारण यह क्रैश हो जाए, तो बस विलंब बढ़ा दें। एक दीर्घकालिक रिपोर्ट के लिए कभी भी उस डेटा की आवश्यकता नहीं होती है जो अभी डेटाबेस में आया हो। यदि आपके पास यह तीन घंटे के लिए है, तो आप इसे किसी पुरानी डेटा अवधि के लिए चला रहे हैं। और आपके लिए, चाहे तीन घंटे की देरी हो या छह घंटे की देरी से कोई फर्क नहीं पड़ेगा, लेकिन आपको लगातार रिपोर्ट प्राप्त होंगी और उनके गिरने में कोई समस्या नहीं होगी।
• स्वाभाविक रूप से, आपको प्रतिकृतियों पर लंबे सत्रों को नियंत्रित करने की आवश्यकता है, खासकर यदि आप प्रतिकृति पर hot_standby_feedback सक्षम करने का निर्णय लेते हैं। क्योंकि कुछ भी हो सकता है. हमने यह प्रतिकृति डेवलपर को दी ताकि वह प्रश्नों का परीक्षण कर सके। उसने एक पागलपन भरा अनुरोध लिखा। उन्होंने इसे लॉन्च किया और चाय पीने चले गए, और हमें स्थापित मास्टर मिल गए। या हो सकता है कि हमने वहां गलत एप्लिकेशन डाल दिया हो। परिस्थितियाँ विविध हैं। प्रतिकृतियों पर सत्र की निगरानी मास्टर की तरह ही सावधानीपूर्वक की जानी चाहिए।
• और यदि आपके पास प्रतिकृतियों पर तेज़ और लंबे प्रश्न हैं, तो इस मामले में लोड को वितरित करने के लिए उन्हें विभाजित करना बेहतर है। यह स्ट्रीमिंग_डिले का लिंक है। तेज़ लोगों के लिए, थोड़ी प्रतिकृति विलंब के साथ एक प्रतिकृति रखें। लंबे समय तक चलने वाले रिपोर्टिंग अनुरोधों के लिए, एक प्रतिकृति रखें जो 6 घंटे या एक दिन तक विलंबित हो सकती है। यह बिल्कुल सामान्य स्थिति है.

हम परिणामों को उसी तरह समाप्त करते हैं:

• हमें फूली हुई मेजें मिलती हैं।
• और हम इसे सबसे सुविधाजनक उपकरण से संपीड़ित करते हैं जो हमारे लिए उपयुक्त है।

दूसरी कहानी यहीं ख़त्म होती है. आइए तीसरी कहानी पर चलते हैं।

हमारे लिए यह भी काफी सामान्य है जिसमें हम प्रवास करते हैं।

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

यहां आपके सामने अपडेट के साथ माइग्रेशन प्रस्तुत है। चूँकि ये मेरे खाते के लेन-देन हैं, प्लेट 15 जीबी थी। और चूँकि हम प्रत्येक पंक्ति को अद्यतन करते हैं, हमने अद्यतन के साथ तालिका का आकार दोगुना कर दिया है, क्योंकि हमने प्रत्येक पंक्ति को फिर से लिखा है।

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

हमने माइग्रेशन किया और फिर से समस्याएं आईं।

माइग्रेशन सफल रहा, लेकिन:

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

और यह फिर से सूजन है, जो फिर से हमारे जीवन को बर्बाद कर देती है।

यहां मैं प्रदर्शित करता हूं कि तालिका, पिछले दो मामलों की तरह, अपने पिछले आकार में वापस नहीं आने वाली है। औसत सर्वर लोड पर्याप्त प्रतीत होता है.

और यदि हम खातों वाली तालिका की ओर मुड़ें, तो हम देखेंगे कि इस तालिका के लिए औसत अनुरोध समय दोगुना हो गया है। प्रोसेसर पर लोड और मेमोरी में क्रमबद्ध लाइनों की संख्या 7,5 से ऊपर पहुंच गई, लेकिन कम थी। और प्रोसेसर के मामले में यह 2 गुना बढ़ गया, ब्लॉक ऑपरेशंस के मामले में 1,5 गुना, यानी हमें सर्वर प्रदर्शन में गिरावट मिली। और परिणामस्वरूप - हमारे एप्लिकेशन के प्रदर्शन में गिरावट। वहीं, कॉल्स की संख्या लगभग उसी स्तर पर रही।

और यहां मुख्य बात यह समझना है कि ऐसे माइग्रेशन को सही तरीके से कैसे किया जाए। और उन्हें पूरा करने की जरूरत है. हम ये माइग्रेशन काफी लगातार करते हैं।

• इतने बड़े प्रवास स्वत: नहीं होते। उन्हें सदैव नियंत्रण में रहना चाहिए।
• किसी जानकार व्यक्ति के पर्यवेक्षण की आवश्यकता है। यदि आपकी टीम में डीबीए है, तो डीबीए को यह काम करने दें। यह उसका काम है. यदि नहीं, तो सबसे अनुभवी व्यक्ति को ऐसा करने दें, जो डेटाबेस के साथ काम करना जानता हो।
• एक नया डेटाबेस स्कीमा, भले ही हम एक कॉलम को अपडेट करते हैं, हम हमेशा चरणों में तैयार करते हैं, यानी एप्लिकेशन के नए संस्करण को रोल आउट करने से पहले पहले से:
• नए फ़ील्ड जोड़े गए हैं जिनमें हम अद्यतन डेटा रिकॉर्ड करेंगे।
• हम डेटा को पुराने फ़ील्ड से नए फ़ील्ड में छोटे भागों में स्थानांतरित करते हैं। हम यह क्यों कर रहे हैं? सबसे पहले, हम हमेशा इस प्रक्रिया की प्रक्रिया को नियंत्रित करते हैं। हम जानते हैं कि हम पहले ही बहुत सारे बैच स्थानांतरित कर चुके हैं और हमारे पास बहुत सारे बैच बाकी हैं।
• और दूसरा सकारात्मक प्रभाव यह है कि ऐसे प्रत्येक बैच के बीच हम लेनदेन को बंद कर देते हैं, एक नया लेनदेन खोलते हैं, और यह ऑटोवैक्यूम को प्लेट के अनुसार काम करने की अनुमति देता है, पुन: उपयोग के लिए मृत रेखाओं को चिह्नित करता है।
• उन पंक्तियों के लिए जो एप्लिकेशन चलने के दौरान दिखाई देंगी (हमारे पास अभी भी पुराना एप्लिकेशन चल रहा है), हम एक ट्रिगर जोड़ते हैं जो नए फ़ील्ड में नए मान लिखता है। हमारे मामले में, यह पुराने मूल्य के एक सौ से गुणा है।
• यदि हम पूरी तरह से जिद्दी हैं और वही फ़ील्ड चाहते हैं, तो सभी माइग्रेशन पूरा होने पर और एप्लिकेशन का नया संस्करण शुरू करने से पहले, हम बस फ़ील्ड का नाम बदल देते हैं। पुराने फ़ील्ड को कुछ आविष्कृत नाम दिया गया है, और नए फ़ील्ड का नाम बदलकर पुराने फ़ील्ड कर दिया गया है।
• और उसके बाद ही हम एप्लिकेशन का एक नया संस्करण लॉन्च करते हैं।

और साथ ही हमें सूजन भी नहीं होगी और प्रदर्शन के मामले में भी नुकसान नहीं होगा।

यहीं पर तीसरी कहानी ख़त्म होती है.

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

और अब उन उपकरणों के बारे में थोड़ा और विस्तार से जिनका मैंने पहली कहानी में उल्लेख किया था।

ब्लोट की खोज करने से पहले, आपको एक्सटेंशन इंस्टॉल करना होगा pgstattuple.

ताकि आपको प्रश्नों के साथ न आना पड़े, हमने इन प्रश्नों को पहले ही अपने काम में लिख दिया है। आप उनका उपयोग कर सकते हैं. यहां दो अनुरोध हैं.

• पहले वाले को काम करने में काफी लंबा समय लगता है, लेकिन यह आपको तालिका से सटीक ब्लोट मान दिखाएगा।
• दूसरा तेजी से काम करता है और बहुत प्रभावी होता है जब आपको तालिका के अनुसार तुरंत आकलन करने की आवश्यकता होती है कि सूजन है या नहीं। और आपको यह भी समझना चाहिए कि ब्लोट हमेशा पोस्टग्रेज़ तालिका में मौजूद होता है। यह इसके MVCC मॉडल की एक विशेषता है।
• और अधिकांश मामलों में तालिकाओं के लिए 20% ब्लोट सामान्य है। यानी आपको चिंता नहीं करनी चाहिए और इस टेबल को कंप्रेस कर लेना चाहिए।

हमने यह पता लगाया कि उन तालिकाओं की पहचान कैसे की जाए जो बेकार डेटा से भरी हुई हैं।

अब ब्लोटिंग को ठीक करने के तरीके के बारे में:

• यदि हमारे पास एक छोटा टैबलेट और अच्छी डिस्क है, यानी एक गीगाबाइट तक के टैबलेट पर, तो VACUUM FULL का उपयोग करना काफी संभव है। वह कुछ सेकंड के लिए आपसे टेबल पर एक विशेष ताला ले लेगा और ठीक है, लेकिन वह सब कुछ जल्दी और कठोरता से करेगा। वैक्यूम फुल क्या करता है? यह टेबल पर एक विशेष लॉक लेता है और पुरानी टेबल से लाइव पंक्तियों को नई टेबल में फिर से लिखता है। और अंत में वह उनकी जगह ले लेता है। यह पुरानी फ़ाइलों को हटा देता है और पुरानी फ़ाइलों को नई फ़ाइलों से बदल देता है। लेकिन अपने काम की अवधि के लिए, यह मेज पर एक विशेष ताला लगाता है। इसका मतलब यह है कि आप इस तालिका के साथ कुछ भी नहीं कर सकते: न तो इसमें लिखें, न ही इसे पढ़ें, न ही इसमें संशोधन करें। और VACUUM FULL को डेटा लिखने के लिए अतिरिक्त डिस्क स्थान की आवश्यकता होती है।
• अगला उपकरण pg_repack. अपने सिद्धांत में, यह VACUUM FULL के समान है, क्योंकि यह पुरानी फ़ाइलों से डेटा को नई फ़ाइलों में फिर से लिखता है और उन्हें तालिका में बदल देता है। लेकिन साथ ही, यह अपने काम की शुरुआत में ही टेबल पर एक विशेष लॉक नहीं लेता है, बल्कि इसे केवल उस समय लेता है जब फ़ाइलों को बदलने के लिए उसके पास पहले से ही तैयार डेटा होता है। इसकी डिस्क संसाधन आवश्यकताएँ VACUUM FULL के समान हैं। आपको अतिरिक्त डिस्क स्थान की आवश्यकता है, और यदि आपके पास टेराबाइट तालिकाएँ हैं तो यह कभी-कभी महत्वपूर्ण होता है। और यह काफी प्रोसेसर-भूख वाला है क्योंकि यह सक्रिय रूप से I/O के साथ काम करता है।
• तीसरी उपयोगिता है पीजीकॉम्पैक्टटेबल. यह संसाधनों के मामले में अधिक सावधान है क्योंकि यह थोड़े अलग सिद्धांतों के अनुसार काम करता है। pgcompacttable का मुख्य विचार यह है कि यह तालिका में अपडेट का उपयोग करके सभी लाइव पंक्तियों को तालिका की शुरुआत में ले जाता है। और फिर यह इस टेबल पर एक वैक्यूम चलाता है, क्योंकि हम जानते हैं कि हमारे पास शुरुआत में जीवित पंक्तियाँ हैं और अंत में मृत पंक्तियाँ हैं। और वैक्यूम स्वयं इस पूंछ को काट देता है, यानी इसे अधिक अतिरिक्त डिस्क स्थान की आवश्यकता नहीं होती है। और साथ ही, संसाधनों के मामले में इसे अभी भी निचोड़ा जा सकता है।

उपकरण के साथ सब कुछ.

यदि आपको ब्लोट विषय अधिक गहराई से जानने के लिहाज से दिलचस्प लगता है, तो यहां कुछ उपयोगी लिंक दिए गए हैं:

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - यह मेरे सहकर्मी की रिपोर्ट है। यह सामान्य है कि पोस्टग्रेज़ का स्थान अपने कार्य और जीवन के दौरान कहाँ जाता है। और ब्लोट के बारे में डेटाबेस प्रशासकों के लिए एक बहुत बड़ा और विस्तृत तकनीकी टुकड़ा है।
• https://github.com/dataegret/pg-utils - यह हमारे भंडार का एक लिंक है, जहां हम डेटाबेस की स्थिति की जांच के लिए उपयोगी स्क्रिप्ट का एक समूह संग्रहीत करते हैं। वहां आप ब्लोट की खोज के लिए स्क्रिप्ट पा सकते हैं।
• तिहाई и चौथा ऐसे टूल के लिंक जो आपको संकेतों को छोटा करने में मदद करेंगे।
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - यह मेरे सहकर्मी की पोस्ट है। वहां वह प्रशासकों के करीबी स्तर पर ब्लोट का काफी गंभीरता से और तकनीकी रूप से विस्तार से विश्लेषण करता है।

मैंने डेवलपर्स के लिए एक डरावनी कहानी दिखाने की अधिक कोशिश की, क्योंकि वे डेटाबेस के हमारे प्रत्यक्ष ग्राहक हैं और उन्हें समझना चाहिए कि क्या और क्या कार्रवाई होती है। मुझे आशा है कि मैं सफल हुआ। आपके ध्यान देने के लिए धन्यवाद!

सवाल

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

इस मामले में, यह आपकी कंपनी के प्रशासकों के लिए एक कार्य है, जरूरी नहीं कि डीबीए के लिए भी।

मैं एक प्रशासक हूं.

PostgreSQL में pg_stat_activity नाम का एक दृश्य है जो लटकती क्वेरीज़ दिखाता है। और आप देख सकते हैं कि यह कितनी देर तक वहां लटका रहता है।

क्या मुझे हर 5 मिनट में अंदर आकर देखना होगा?

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

क्या ऐसा होने का कोई स्पष्ट कारण है?

मैंने कुछ को सूचीबद्ध किया है। अन्य अधिक जटिल उदाहरण. और काफी देर तक बातचीत हो सकती है.

रिपोर्ट के लिए धन्यवाद! मैं pg_repack उपयोगिता के बारे में स्पष्टीकरण देना चाहता था। अगर वह एक्सक्लूसिव लॉक नहीं करती है, तो...

वह एक विशेष ताला लगाती है।

... तो मैं संभावित रूप से डेटा खो सकता हूं। क्या इस दौरान मेरा एप्लिकेशन कुछ भी रिकॉर्ड नहीं कर रहा होगा?

नहीं, यह तालिका के साथ सुचारू रूप से काम करता है, यानी pg_repack पहले मौजूद सभी लाइव लाइनों को स्थानांतरित करता है। स्वाभाविक रूप से, तालिका में किसी प्रकार की प्रविष्टि वहां होती है। वह बस इस पोनीटेल को बाहर फेंक रहा है।

यानी आख़िर में वह वास्तव में ऐसा करता है?

अंत में, वह इन फ़ाइलों को स्वैप करने के लिए एक विशेष लॉक लेता है।

क्या यह VACUUM FULL से तेज़ होगा?

वैक्यूम फुल, जैसे ही यह शुरू हुआ, तुरंत एक विशेष लॉक ले लिया। और जब तक वह सब कुछ न कर ले, वह उसे जाने न देगा। और pg_repack केवल फ़ाइल प्रतिस्थापन के समय एक विशेष लॉक लेता है। इस समय आप वहां नहीं लिखेंगे, लेकिन डेटा नष्ट नहीं होगा, सब कुछ ठीक हो जाएगा।

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

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

मैं समझता हूँ। लेकिन सवाल यह नहीं है। मैंने ख़त्म नहीं किया. आइए मान लें कि हमारे पास एक टेबल है। इसमें परिवर्तनशील आकार के फ़ील्ड हैं. और अगर मैं कुछ नया डालने की कोशिश करता हूं, तो हो सकता है कि वह पुराने सेल में फिट न हो।

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

रिपोर्ट के लिए धन्यवाद! क्या अवधि सीमित करने के लिए स्टेटमेंट टाइमआउट क्वेरी का उपयोग करना स्वीकार्य है?

बहुत स्वीकार्य. इसका प्रयोग हम हर जगह करते हैं. और चूँकि हमारे पास अपनी स्वयं की सेवाएँ नहीं हैं, हम दूरस्थ सहायता प्रदान करते हैं, हमारे पास काफी विविध प्रकार के ग्राहक हैं। और इससे हर कोई पूरी तरह संतुष्ट है. यानी, हमारे पास क्रॉन नौकरियां हैं जो जांच करती हैं। सत्र की अवधि पर केवल ग्राहक के साथ सहमति होती है, इससे पहले हम सहमत नहीं होते हैं। यह एक मिनट हो सकता है, यह 10 मिनट हो सकता है। यह आधार पर भार और उसके उद्देश्य पर निर्भर करता है। लेकिन हम सभी pg_stat_activity का उपयोग करते हैं।

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

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

यानी अपडेट के तुरंत बाद बंद हो जाता है?

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

नमस्ते! रिपोर्ट के लिए धन्यवाद! आइए कल्पना करें कि हमारे पास एक डेटाबेस है जो फूलता और फूलता जा रहा है और फिर सर्वर पर जगह खत्म हो जाती है। क्या इस स्थिति को ठीक करने के लिए कोई उपकरण हैं?

सर्वर पर स्थान की ठीक से निगरानी की जानी चाहिए।

उदाहरण के लिए, डीबीए चाय के लिए गया, किसी रिसॉर्ट में था, आदि।

जब एक फ़ाइल सिस्टम बनाया जाता है, तो कम से कम कुछ प्रकार का बैकअप स्थान बनाया जाता है जहाँ डेटा नहीं लिखा जाता है।

क्या होगा यदि यह पूरी तरह से शून्य से नीचे है?

वहां इसे आरक्षित स्थान कहा जाता है, यानी इसे मुक्त किया जा सकता है और यह कितना बड़ा बनाया गया है, इसके आधार पर आपको मुक्त स्थान मिलता है। डिफ़ॉल्ट रूप से मुझे नहीं पता कि कितने हैं। और दूसरे मामले में, डिस्क वितरित करें ताकि आपके पास पुनर्निर्माण कार्य करने के लिए जगह हो। आप कुछ ऐसी तालिका हटा सकते हैं जिसकी आपको गारंटी नहीं होगी।

क्या कोई अन्य उपकरण हैं?

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

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

वे उन्हें पैक भी करते हैं.

लेकिन निर्वात सूचकांक को प्रभावित नहीं करता?

कुछ लोग इंडेक्स के साथ काम करते हैं। उदाहरण के लिए, pg_rapack, pgcompacttable। निर्वात अनुक्रमितों को पुनः बनाता है और उन्हें प्रभावित करता है। VACUUM FULL के साथ विचार यह है कि हर चीज़ को अधिलेखित कर दिया जाए, यानी यह सभी के साथ काम करता है।

और दूसरा प्रश्न. मुझे समझ में नहीं आता कि प्रतिकृतियों पर रिपोर्टें प्रतिकृति पर ही इतनी अधिक निर्भर क्यों होती हैं। मुझे ऐसा लगा कि रिपोर्टें पढ़ी जाती हैं और प्रतिकृति लिखी जाती है।

प्रतिकृति संघर्ष का क्या कारण बनता है? हमारे पास एक मास्टर है जिस पर प्रक्रियाएं होती हैं। हमारे यहां कार वैक्यूम चल रहा है। ऑटोवैक्यूम वास्तव में क्या करता है? वह कुछ पुरानी लाइनें काट रहे हैं. यदि इस समय हमारे पास प्रतिकृति पर एक अनुरोध है जो इन पुरानी पंक्तियों को पढ़ता है, और मास्टर पर ऐसी स्थिति उत्पन्न होती है कि ऑटोवैक्यूम ने इन पंक्तियों को ओवरराइटिंग के लिए संभव के रूप में चिह्नित किया है, तो हमने उन्हें ओवरराइट कर दिया है। और हमें एक डेटा पैकेट प्राप्त हुआ, जब हमें उन पंक्तियों को फिर से लिखने की आवश्यकता होती है जिनकी अनुरोध को प्रतिकृति पर आवश्यकता होती है, तो प्रतिकृति प्रक्रिया आपके द्वारा कॉन्फ़िगर किए गए टाइमआउट की प्रतीक्षा करेगी। और फिर PostgreSQL तय करेगा कि उसके लिए क्या अधिक महत्वपूर्ण है। और प्रतिकृति उसके लिए अनुरोध से अधिक महत्वपूर्ण है, और वह प्रतिकृति पर ये परिवर्तन करने के लिए अनुरोध को शूट करेगा।

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

यह एक सेवा है ओकेमीटर.

क्या यह एक व्यावसायिक उत्पाद है?

हाँ। यह एक व्यावसायिक उत्पाद है.

स्रोत: www.habr.com