अनुप्रयोगहरूमा विशिष्ट त्रुटिहरू जसले postgresql मा ब्लोट निम्त्याउँछ। Andrey Salnikov

म तपाईंलाई 2016 को शुरुवातबाट Andrey Salnikov द्वारा रिपोर्टको ट्रान्सक्रिप्ट पढ्न सुझाव दिन्छु "एप्लिकेशनहरूमा विशिष्ट त्रुटिहरू जसले postgresql मा ब्लोट निम्त्याउँछ"।

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

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

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

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

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

प्लेट को प्रारम्भिक डाटा: यो एकदम सानो छ, 2 MB। डाटाबेस र विशेष गरी चिन्हको लागि प्रतिक्रिया समय पनि धेरै राम्रो छ। र एकदम राम्रो लोड - प्लेट अनुसार प्रति सेकेन्ड 2 सञ्चालन।

र यो रिपोर्ट मार्फत म तपाईंलाई ग्राफहरू देखाउनेछु ताकि तपाईं स्पष्ट रूपमा के भइरहेको छ बुझ्न सक्नुहुन्छ। त्यहाँ सधैं ग्राफहरू सहित 2 स्लाइडहरू हुनेछ। पहिलो स्लाइड भनेको सर्भरमा सामान्यतया के हुन्छ।

र यस अवस्थामा, हामी देख्छौं कि हामीसँग साँच्चै सानो चिन्ह छ। सूचकांक 2 MB मा सानो छ। यो बायाँमा पहिलो ग्राफ हो।

सर्भरमा औसत प्रतिक्रिया समय पनि स्थिर र छोटो छ। यो शीर्ष दायाँ ग्राफ हो।

तल बायाँ ग्राफ सबैभन्दा लामो लेनदेन देखाउँछ। हामी देख्छौं कि लेनदेन छिटो पूरा हुन्छ। र अटोभ्याक्यूमले यहाँ अझै काम गर्दैन, किनभने यो एक सुरु परीक्षण थियो। यो काम जारी रहनेछ र हाम्रो लागि उपयोगी हुनेछ।

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

तल्लो दायाँ ग्राफले यसलाई अद्यावधिक गर्नु अघि हामीले हाम्रो इच्छित रेखाको खोजीमा कति अपरेटिङ र डिस्क मेमोरी मार्फत जान्छौं भनेर देखाउँछ। र चिन्ह अनुसार सञ्चालनको संख्या 2 प्रति सेकेन्ड हो, मैले सुरुमा भनें।

र अब हामी एक त्रासदी छ। केही कारणले त्यहाँ लामो समय बिर्सिएको लेनदेन छ। कारणहरू सामान्यतया सबै साधारण छन्:

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

यस्ता कुराले कहाँ पु¥याउँछ ?

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

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

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

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

हामीले जीवनमा फर्कन आवश्यक छ। हामी अनलाइन जान्छौं र पत्ता लगाउँछौं कि लामो लेनदेनले समस्या निम्त्याउँछ। हामी यो लेनदेन फेला पार्छौं र मार्छौं। र हाम्रो लागि सबै सामान्य हुँदैछ। सबै कुरा जसरी काम हुन्छ त्यसरी नै चल्छ ।

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

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

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

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

समग्रमा राम्रो छ, तर अवस्था पहिले भन्दा खराब छ। यस डाटाबेससँग काम गर्ने हाम्रो अनुप्रयोगको परिणामको रूपमा डाटाबेसको ह्रास हटाउनुहोस्।

र त्यहाँ के भइरहेको छ भनेर बुझ्नको लागि, यदि तपाईं अघिल्लो रिपोर्टमा हुनुहुन्न भने, अब थोरै सिद्धान्त प्राप्त गरौं। आन्तरिक प्रक्रिया बारे सिद्धान्त। कार भ्याकुम किन हुन्छ र यसले के गर्छ?

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

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

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

दुर्घटना हुँदा के भयो ? त्यहाँ यो प्रक्रिया कसरी भयो?

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

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

वास्तवमा, हामीलाई काम गर्न ग्रीन लाइनहरू चाहिन्छ। तर यस्तो समस्या को समयमा, यो बाहिर जान्छ कि हरियो रेखा को प्रतिशत सम्पूर्ण तालिका मा एकदम कम छ।

र जब हामी एक क्वेरी कार्यान्वयन गर्छौं, डाटाबेसले सबै लाइनहरू मार्फत जानुपर्छ: रातो र हरियो दुवै, इच्छित रेखा फेला पार्न। र बेकार डाटाको साथ टेबल ब्लोट गर्ने प्रभावलाई "ब्लोट" भनिन्छ, जसले हाम्रो डिस्क स्पेस पनि खान्छ। याद गर्नुहोस्, यो 2 MB थियो, यो 300 MB भयो? अब मेगाबाइटलाई गीगाबाइटमा परिवर्तन गर्नुहोस् र तपाइँले तुरुन्तै तपाइँका सबै डिस्क स्रोतहरू गुमाउनुहुनेछ।

हाम्रो लागि कस्तो परिणाम हुन सक्छ?

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

यस उद्देश्यका लागि कार्यको एक निश्चित चक्र छ।

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

एकचोटि तपाईंले यी तालिकाहरू फेला पारेपछि, तपाईंले तिनीहरूलाई कम्प्रेस गर्न आवश्यक छ। यसका लागि पहिले नै उपकरणहरू छन्। हाम्रो कम्पनीमा हामी तीनवटा उपकरणहरू प्रयोग गर्छौं। पहिलो बिल्ट-इन भ्याकुम फुल हो। उहाँ क्रूर, कठोर र निर्दयी हुनुहुन्छ, तर कहिलेकाहीँ उहाँ धेरै उपयोगी हुनुहुन्छ। Pg_repack и pgcompacttable - यी तालिकाहरू कम्प्रेस गर्नका लागि तेस्रो-पक्ष उपयोगिताहरू हुन्। र तिनीहरूले डाटाबेसलाई अझ सावधानीपूर्वक व्यवहार गर्छन्।

तिनीहरू तपाइँको लागि अधिक सुविधाजनक के आधारमा प्रयोग गरिन्छ। तर म तपाईलाई यसको अन्त्यमा भन्नेछु। मुख्य कुरा यो हो कि त्यहाँ तीन उपकरणहरू छन्। त्यहाँ छनौट गर्न धेरै छन्।

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

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

यी ग्राफहरूमा, म तपाईंलाई यो केसमा VACUUM FULL सँग साइन मार्फत गए पछि डाटाबेसको चिन्ह र व्यवहार कसरी परिवर्तन भयो भनेर देखाउन चाहन्छु। यो मेरो लागि उत्पादन होइन।

तालिकाको आकार तुरुन्तै मेगाबाइटको एक जोडीको सामान्य अपरेटिङ स्थितिमा फर्कियो। यसले सर्भरको लागि औसत प्रतिक्रिया समयलाई ठूलो असर पारेन।

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

यहाँ पहिलो कथा समाप्त हुन्छ। यो सबैभन्दा सामान्य छ। र यो सबैलाई हुन्छ, ग्राहकको अनुभव र प्रोग्रामरहरू कत्तिको योग्य भए पनि। ढिलो वा चाँडो यो हुन्छ।

दोस्रो कथा, जसमा हामी लोड वितरण गर्छौं र सर्भर स्रोतहरू अनुकूलन गर्छौं

• हामी पहिले नै हुर्केका छौं र गम्भीर केटाहरू बनिसकेका छौं। र हामी बुझ्छौं कि हामीसँग प्रतिकृति छ र यो हाम्रो लागि भार सन्तुलन गर्न राम्रो हुनेछ: मास्टरलाई लेख्नुहोस्, र प्रतिकृतिबाट पढ्नुहोस्। र सामान्यतया यो अवस्था उत्पन्न हुन्छ जब हामी केहि रिपोर्ट वा ETL तयार गर्न चाहन्छौं। र यसबाट व्यापार धेरै खुसी छ। उहाँ साँच्चै धेरै जटिल विश्लेषणका साथ विभिन्न प्रकारका रिपोर्टहरू चाहनुहुन्छ।
• रिपोर्टहरू धेरै घण्टा लाग्छ, किनभने जटिल विश्लेषणहरू मिलिसेकेन्डमा गणना गर्न सकिँदैन। हामी, बहादुर केटाहरू जस्तै, कोड लेख्छौं। सम्मिलन अनुप्रयोगमा हामी मास्टरमा रेकर्डिङ गर्छौं, र प्रतिकृतिमा रिपोर्टहरू कार्यान्वयन गर्छौं।
• भार वितरण गर्दै।
• सबै कुरा पूर्ण रूपमा काम गर्दछ। हामी महान छौं।

र यो अवस्था कस्तो देखिन्छ? विशेष गरी यी ग्राफहरूमा, मैले लेनदेन अवधिको लागि प्रतिकृतिबाट लेनदेनको अवधि पनि थपेको छु। अन्य सबै ग्राफहरू मास्टर सर्भरलाई मात्र सन्दर्भ गर्दछ।

त्यतिन्जेल, मेरो रिपोर्ट बोर्ड बढेको थियो। ती मध्ये धेरै छन्। हामी देख्छौं कि औसत सर्भर प्रतिक्रिया समय स्थिर छ। हामी देख्छौं कि प्रतिकृतिमा हामीसँग लामो समयदेखि चलिरहेको लेनदेन छ जुन २ घण्टासम्म चल्छ। हामी अटोभ्याक्यूमको शान्त सञ्चालन देख्छौं, जसले डेड लाइनहरू प्रशोधन गर्छ। र हामीसँग सबै ठीक छ।

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

प्रतिकृतिको साथ द्वन्द्वको कारण यी रिपोर्टहरू फिर्ता फायर गर्न सुरु नभएसम्म सबै कुरा ठीक छ। र तिनीहरू नियमित अन्तरालहरूमा फिर्ता फायर गर्छन्।

हामी अनलाइन जान्छौं र यो किन भइरहेको छ भनेर पढ्न थाल्छौं। र हामी समाधान खोज्छौं।

पहिलो समाधान भनेको प्रतिकृति विलम्बता बढाउनु हो। हामीलाई थाहा छ हाम्रो रिपोर्ट 3 घण्टा चल्छ। हामीले प्रतिकृति ढिलाइ 3 घण्टामा सेट गर्यौं। हामी सबै कुरा सुरु गर्दैछौं, तर हामी अझै पनि कहिलेकाहीं रद्द हुने रिपोर्टहरूमा समस्याहरू जारी राख्छौं।

हामी सबै कुरा सही होस् भन्ने चाहन्छौं। हामी थप चढ्छौं। र हामीले इन्टरनेटमा राम्रो सेटिङ फेला पार्‍यौं - hot_standby_feedback। यसलाई अन गरौं। Hot_standby_feedback ले हामीलाई Master मा autovacuum लाई होल्ड गर्न अनुमति दिन्छ। यसरी, हामी प्रतिकृति द्वन्द्वबाट पूर्ण रूपमा छुटकारा पाउँछौं। र सबै कुरा रिपोर्ट संग हाम्रो लागि राम्रो काम गर्दछ।

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

विशेष गरी, हाम्रो प्लेटबाट, हामी देख्छौं कि यसमा डाटा अपडेट पनि आकाशमा उफ्रिएको छ। CPU खपत पनि उस्तै धेरै बढेको छ। हामी फेरि ठूलो संख्यामा मृत, बेकार लाइनहरू पार गर्दैछौं। र यस चिन्हको लागि प्रतिक्रिया समय र लेनदेनको संख्या घटेको छ।

यदि हामीले पहिले के कुरा गरिरहेको थिएँ थाहा छैन भने यो कस्तो देखिन्छ?

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

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

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

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

कुनै पनि अवस्थामा, हामीले प्रदर्शन ड्रडाउन पाउँछौं, पहिलो केसमा जस्तै, डेढ देखि दुई पटक, र कहिलेकाहीँ बढी।

हामीले सबै कुरा ठीक गरेका छौँ जस्तो लाग्छ। लोड वितरण गर्नुहोस्। उपकरण निष्क्रिय छैन। हामीले हाम्रो दिमाग अनुसार अनुरोधहरू विभाजित गर्यौं, तर अझै पनि सबै खराब भयो।

• hot_standby_feedback सक्षम नगर्ने? हो, यो विशेष बलियो कारण बिना यसलाई खोल्न सिफारिस गरिएको छैन। किनभने यो ट्विस्टले मास्टर सर्भरलाई प्रत्यक्ष असर गर्छ र त्यहाँ अटोभ्याक्यूमको सञ्चालनलाई निलम्बन गर्छ। यसलाई केही प्रतिकृतिमा सक्षम गरेर र यसको बारेमा बिर्सेर, तपाइँ मास्टरलाई मार्न र अनुप्रयोगको साथ ठूलो समस्याहरू प्राप्त गर्न सक्नुहुन्छ।
• max_standby_streaming_delay बढाउने हो? हो, रिपोर्टहरूको लागि यो सत्य हो। यदि तपाइँसँग तीन-घण्टा रिपोर्ट छ र तपाइँ यसलाई प्रतिकृति द्वन्द्वको कारण क्र्यास गर्न चाहनुहुन्न भने, त्यसपछि मात्र ढिलाइ बढाउनुहोस्। एक दीर्घकालीन रिपोर्टलाई डाटाबेसमा अहिले आएको डाटाको आवश्यकता पर्दैन। यदि तपाइँसँग यो तीन घण्टाको लागि छ भने, तपाइँ यसलाई केहि पुरानो डाटा अवधिको लागि चलाइरहनुभएको छ। र तपाईंको लागि, तीन घण्टा ढिलो होस् वा छ घण्टा ढिलाइले कुनै फरक पार्दैन, तर तपाईंले लगातार रिपोर्टहरू प्राप्त गर्नुहुनेछ र तिनीहरूलाई झर्दा कुनै समस्या हुनेछैन।
• स्वाभाविक रूपमा, तपाईंले प्रतिकृतिहरूमा लामो सत्रहरू नियन्त्रण गर्न आवश्यक छ, विशेष गरी यदि तपाईंले प्रतिकृतिमा hot_standby_feedback सक्षम गर्ने निर्णय गर्नुभयो भने। किनभने जे पनि हुन सक्छ। हामीले यो प्रतिकृति विकासकर्तालाई दियौं ताकि उसले प्रश्नहरूको परीक्षण गर्न सकून्। उनले एक पागल अनुरोध लेखे। उसले लन्च गर्यो र चिया पिउन गए, र हामीले स्थापित मास्टर पायौं। वा हुनसक्छ हामीले त्यहाँ गलत अनुप्रयोग राख्यौं। परिस्थितिहरू विविध छन्। प्रतिकृतिहरूमा सत्रहरू मास्टरमा जस्तै सावधानीपूर्वक निगरानी गर्नुपर्छ।
• र यदि तपाइँसँग प्रतिकृतिहरूमा छिटो र लामो प्रश्नहरू छन् भने, यस अवस्थामा यो लोड वितरण गर्न तिनीहरूलाई विभाजित गर्न राम्रो छ। यो streaming_delay को लिङ्क हो। छिटोका लागि, सानो प्रतिकृति ढिलाइ भएको एउटा प्रतिकृति छ। लामो समय चलिरहेको रिपोर्टिङ अनुरोधहरूको लागि, एक प्रतिकृति छ जुन 6 घण्टा वा एक दिन ढिलो हुन सक्छ। यो पूर्णतया सामान्य अवस्था हो।

हामी त्यसै तरिकामा परिणामहरू हटाउँछौं:

• हामी फूलेको टेबल फेला पार्छौं।
• र हामी यसलाई सबैभन्दा सुविधाजनक उपकरणको साथ कम्प्रेस गर्छौं जुन हामीलाई उपयुक्त छ।

दोस्रो कथा यहाँ समाप्त हुन्छ। तेस्रो कथामा जाऔं।

हामी माइग्रेसन गर्ने हाम्रो लागि पनि सामान्य।

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

यहाँ तपाइँको सामने प्रस्तुत अद्यावधिक संग माइग्रेसन छ। किनकि यी मेरो खाता लेनदेन हुन्, प्लेट 15 GB थियो। र हामीले हरेक पङ्क्ति अपडेट गरेपछि, हामीले अपडेटको साथ तालिकाको साइज दोब्बर बनायौं, किनभने हामीले प्रत्येक लाइनलाई पुन: लेख्यौं।

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

हामीले बसाइँ सरायौं र फेरि समस्या भोग्यौं।

माइग्रेसन सफल भयो, तर:

• पुरानो कार्यक्षमता अब पूरा हुन धेरै समय लाग्छ।
• टेबल फेरि आकारमा बढ्यो।
• सर्भरमा फेरि लोड पहिलेको भन्दा बढ्यो।
• र, निस्सन्देह, हामी अझै राम्रोसँग काम गर्ने कार्यक्षमतासँग टिंकर गर्दैछौं, हामीले यसलाई थोरै सुधार गरेका छौं।

र यो फेरि ब्लोट हो, जसले हाम्रो जीवनलाई फेरि बर्बाद गर्दछ।

यहाँ मैले देखाउँछु कि तालिका, अघिल्लो दुई केसहरू जस्तै, यसको अघिल्लो आकारहरूमा फर्किने छैन। औसत सर्भर लोड पर्याप्त देखिन्छ।

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

र यहाँ मुख्य कुरा यस्तो माइग्रेसन सही तरिकाले गर्न कसरी बुझ्न छ। र तिनीहरू गर्न आवश्यक छ। हामी यी माइग्रेसनहरू राम्ररी लगातार गर्छौं।

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

र एकै समयमा हामीले ब्लोट पाउनेछैनौं र प्रदर्शनको सन्दर्भमा पीडित हुनेछैनौं।

तेस्रो कथा यहीँ समाप्त हुन्छ।

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

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

तपाईंका प्रश्नहरू

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

यस अवस्थामा, यो तपाईंको कम्पनीका प्रशासकहरूको लागि कार्य हो, DBA को लागि आवश्यक छैन।

म प्रशासक हुँ।

PostgreSQL सँग pg_stat_activity भनिने एउटा दृश्य छ जसले डङ्गलिंग प्रश्नहरू देखाउँछ। र तपाईले देख्न सक्नुहुन्छ कि यो त्यहाँ कति लामो छ।

के म भित्र आउन र हरेक 5 मिनेट हेर्नुपर्छ?

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

के त्यहाँ कुनै स्पष्ट कारणहरू छन् किन यो हुन्छ?

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

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

उनी एक विशेष लक गर्छिन्।

... त्यसपछि म सम्भावित रूपमा डाटा गुमाउन सक्छु। के मेरो आवेदन यस समयमा केहि पनि रेकर्ड गर्नु हुँदैन?

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

त्यो हो, उसले वास्तवमा अन्तमा यो गर्छ?

अन्तमा, उसले यी फाइलहरू स्वैप गर्न एक विशेष लक लिन्छ।

के यो VACUUM FULL भन्दा छिटो हुनेछ?

VACUUM FULL, यो सुरु हुने बित्तिकै, तुरुन्तै एक विशेष लक लग्यो। र जबसम्म उसले सबै कुरा गर्दैन, उसले उसलाई जान दिनेछैन। र pg_repack ले फाइल प्रतिस्थापनको समयमा मात्र एक विशेष लक लिन्छ। यस क्षणमा तपाईले त्यहाँ लेख्नुहुने छैन, तर डाटा हराउने छैन, सबै ठीक हुनेछ।

नमस्ते! तपाईंले कार भ्याकुम सञ्चालनको बारेमा कुरा गर्नुभयो। त्यहाँ रातो, पहेंलो र हरियो रेकर्डिङ कक्षहरूको साथ ग्राफ थियो। त्यो हो, पहेंलो - उसले तिनीहरूलाई मेटाइएको रूपमा चिन्ह लगायो। र परिणाम स्वरूप, तिनीहरूमा केहि नयाँ लेख्न सकिन्छ?

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

म बुझ्दछु। तर यो प्रश्नको बारेमा होइन। मैले पूरा गरिन। मानौं हामीसँग एउटा टेबल छ। यसमा चर आकारको क्षेत्रहरू छन्। र यदि मैले केहि नयाँ सम्मिलित गर्ने प्रयास गरें भने, यो पुरानो सेलमा फिट नहुन सक्छ।

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

रिपोर्ट को लागी धन्यवाद! यो अवधि सीमित गर्न कथन टाइमआउट प्रश्नहरू प्रयोग गर्न स्वीकार्य छ?

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

रिपोर्ट को लागी धन्यवाद! म तपाईंको प्रतिवेदनलाई मेरो आवेदनहरूमा लागू गर्ने प्रयास गर्दैछु। र यस्तो देखिन्छ कि हामीले जताततै लेनदेन सुरु गर्छौं, र स्पष्ट रूपमा यसलाई जताततै पूरा गर्छौं। यदि त्यहाँ केहि अपवाद छ भने, रोलब्याक अझै पनि हुन्छ। अनि सोच्न थालेँ । आखिर, लेनदेन स्पष्ट रूपमा सुरु नहुन सक्छ। यो सायद केटीको लागि संकेत हो। यदि मैले भर्खरै रेकर्ड अपडेट गरें भने, लेनदेन PostgreSQL मा सुरु हुन्छ र जडान विच्छेद हुँदा मात्र पूरा हुन्छ?

यदि तपाइँ अहिले एप्लिकेसन लेभलको बारेमा कुरा गर्दै हुनुहुन्छ भने, यो तपाइँले प्रयोग गरिरहनु भएको ड्राइभरमा, प्रयोग भइरहेको ORM मा निर्भर गर्दछ। त्यहाँ धेरै सेटिङहरू छन्। यदि तपाईंसँग स्वत: कमिट सक्षम छ भने, त्यहाँ लेनदेन सुरु हुन्छ र तुरुन्तै बन्द हुन्छ।

त्यो हो, यो अपडेट पछि तुरुन्तै बन्द हुन्छ?

यो सेटिङहरूमा निर्भर गर्दछ। मैले एउटा सेटिङ नाम दिएँ। यो स्वत: प्रतिबद्ध छ। यो एकदम सामान्य छ। यदि यो सक्षम छ भने, लेनदेन खोलिएको छ र बन्द छ। जबसम्म तपाईंले स्पष्ट रूपमा "लेनदेन सुरु गर्नुहोस्" र "अन्त लेनदेन" भन्नुभयो, तर केवल सत्रमा अनुरोध सुरु गर्नुभयो।

नमस्ते! रिपोर्ट को लागी धन्यवाद! कल्पना गरौं कि हामीसँग एउटा डाटाबेस छ जुन सुन्निएको छ र सुन्निएको छ र त्यसपछि सर्भरमा ठाउँ समाप्त हुन्छ। के त्यहाँ यो अवस्था ठीक गर्न कुनै उपकरणहरू छन्?

सर्भरमा स्पेस राम्रोसँग निगरानी गर्न आवश्यक छ।

उदाहरणका लागि, DBA चियाको लागि गयो, रिसोर्टमा थियो, आदि।

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

यदि यो पूर्णतया शून्य भन्दा तल छ भने के हुन्छ?

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

त्यहाँ कुनै अन्य उपकरणहरू छन्?

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

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

तिनीहरू पनि प्याक गर्छन्।

तर वैक्यूमले सूचकांकलाई असर गर्दैन?

केहि अनुक्रमणिका संग काम गर्दछ। उदाहरण को लागी, pg_rapack, pgcompacttable। वैक्यूमले अनुक्रमणिकाहरू पुन: सिर्जना गर्दछ र तिनीहरूलाई असर गर्छ। VACUUM FULL को साथ सबै कुरा ओभरराइट गर्ने विचार हो, अर्थात् यसले सबैसँग काम गर्छ।

र दोस्रो प्रश्न। म बुझ्दिन किन प्रतिकृतिहरूमा रिपोर्टहरू प्रतिकृतिमा धेरै निर्भर हुन्छन्। मलाई रिपोर्टहरू पढिन्छ, र प्रतिकृति लेखिन्छ जस्तो लाग्थ्यो।

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

Andrey, मसँग एउटा प्रश्न छ। तपाईंले प्रस्तुतिको क्रममा देखाउनुभएको यी अद्भुत ग्राफहरू, के यी तपाईंको कुनै प्रकारको उपयोगिताको कामको परिणाम हो? ग्राफहरू कसरी बनाइयो?

यो एक सेवा हो ओकमिटर.

के यो व्यावसायिक उत्पादन हो?

हो। यो एक व्यावसायिक उत्पादन हो।

स्रोत: www.habr.com