ऍप्लिकेशन्समधील ठराविक त्रुटी ज्यामुळे postgresql मध्ये ब्लोट होतो. आंद्रे सालनिकोव्ह

मी तुम्हाला 2016 च्या सुरुवातीपासूनच्या अहवालाचा उतारा वाचण्याचा सल्ला देतो आंद्रे सालनिकोव्ह "अनुप्रयोगांमधील ठराविक त्रुटी ज्यामुळे postgresql मध्ये सूज येते"

या अहवालात, मी अनुप्रयोग कोड डिझाइन आणि लिहिण्याच्या टप्प्यावर उद्भवलेल्या अनुप्रयोगांमधील मुख्य त्रुटींचे विश्लेषण करेन. आणि पोस्टग्रेस्क्यूएलमध्ये ब्लोट होऊ देणार्‍या चुकाच मी घेईन. नियमानुसार, ही संपूर्णपणे आपल्या सिस्टमच्या कार्यप्रदर्शनाच्या समाप्तीची सुरुवात आहे, जरी सुरुवातीला यासाठी कोणतीही पूर्वस्थिती दृश्यमान नव्हती.

सर्वांचे स्वागत करण्यात आनंद झाला! हा अहवाल माझ्या सहकाऱ्याच्या मागील अहवालासारखा तांत्रिक नाही. हा अहवाल प्रामुख्याने बॅकएंड सिस्टम डेव्हलपरसाठी आहे कारण आमच्याकडे मोठ्या प्रमाणात क्लायंट आहेत. आणि ते सर्व समान चुका करतात. मी तुम्हाला त्यांच्याबद्दल सांगेन. या चुकांमुळे कोणत्या घातक आणि वाईट गोष्टी होतात हे मी समजावून सांगेन.

चुका का केल्या जातात? ते दोन कारणांसाठी केले जातात: यादृच्छिकपणे, कदाचित ते कार्य करेल आणि डेटाबेस आणि ऍप्लिकेशन दरम्यान तसेच डेटाबेसमध्येच असलेल्या काही यंत्रणांच्या अज्ञानामुळे.

मी तुम्हाला तीन उदाहरणे देईन ज्याची भयानक चित्रे किती वाईट आहेत. मी तुम्हाला तिथे घडणाऱ्या यंत्रणेबद्दल थोडक्यात सांगेन. आणि त्यांना कसे सामोरे जावे, ते कधी घडले आणि चुका टाळण्यासाठी कोणत्या प्रतिबंधात्मक पद्धती वापरायच्या. मी तुम्हाला सहायक साधनांबद्दल सांगेन आणि उपयुक्त लिंक देईन.

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

प्लेटचा प्रारंभिक डेटा: तो खूपच लहान आहे, 2 MB. डेटाबेस आणि विशेषतः चिन्हासाठी प्रतिसाद वेळ देखील खूप चांगला आहे. आणि बर्‍यापैकी चांगला भार - प्लेटनुसार प्रति सेकंद 2 ऑपरेशन्स.

आणि या अहवालाद्वारे मी तुम्हाला आलेख दाखवीन जेणेकरुन तुम्हाला काय होत आहे ते स्पष्टपणे समजेल. आलेखांसह नेहमी 2 स्लाइड्स असतील. पहिली स्लाइड म्हणजे सर्व्हरवर सर्वसाधारणपणे काय घडते.

आणि या परिस्थितीत, आपण पाहतो की आपल्याकडे खरोखर एक लहान चिन्ह आहे. निर्देशांक 2 MB वर लहान आहे. डावीकडील हा पहिला आलेख आहे.

सर्व्हरवरील सरासरी प्रतिसाद वेळ देखील स्थिर आणि लहान आहे. हा वरचा उजवा आलेख आहे.

तळाशी डावा आलेख सर्वात लांब व्यवहार दाखवतो. व्यवहार लवकर पूर्ण होत असल्याचे आपण पाहतो. आणि ऑटोव्हॅक्यूम अद्याप येथे कार्य करत नाही, कारण ती एक प्रारंभ चाचणी होती. ते काम करत राहील आणि आम्हाला उपयोगी पडेल.

दुसरी स्लाइड नेहमी चाचणी होत असलेल्या प्लेटसाठी समर्पित असेल. या परिस्थितीत, आम्ही ग्राहकाच्या खात्यातील शिल्लक सतत अद्यतनित करतो. आणि आम्ही पाहतो की अपडेट ऑपरेशनसाठी सरासरी प्रतिसाद वेळ खूप चांगला आहे, मिलीसेकंद पेक्षा कमी. आम्ही पाहतो की प्रोसेसर संसाधने (हा वरचा उजवा आलेख आहे) देखील समान प्रमाणात आणि अगदी लहान प्रमाणात वापरला जातो.

खालचा उजवा आलेख दर्शवितो की आम्ही किती ऑपरेटिंग आणि डिस्क मेमरी अपडेट करण्यापूर्वी आमच्या इच्छित रेषेच्या शोधात जातो. आणि चिन्हानुसार ऑपरेशन्सची संख्या 2 प्रति सेकंद आहे, मी सुरुवातीला म्हटल्याप्रमाणे.

आणि आता आपल्याकडे एक शोकांतिका आहे. काही कारणास्तव बराच काळ विसरलेला व्यवहार आहे. कारणे सहसा सर्व सामान्य आहेत:

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

अशा गोष्टी कुठे घेऊन जातात?

इथपर्यंत की आमची तक्ते आणि निर्देशांक नाटकीयपणे फुगायला लागतात. हे अगदी समान ब्लोट प्रभाव आहे. डेटाबेससाठी, याचा अर्थ असा होईल की डेटाबेस प्रतिसाद वेळ खूप वेगाने वाढेल आणि डेटाबेस सर्व्हरवरील भार वाढेल. आणि परिणामी, आमच्या अर्जाचे नुकसान होईल. कारण जर तुम्ही डेटाबेसच्या विनंतीवर तुमच्या कोडमध्ये 10 मिलीसेकंद, तुमच्या लॉजिकवर 10 मिलीसेकंद खर्च केले, तर तुमचे फंक्शन पूर्ण होण्यासाठी 20 मिलीसेकंद लागले. आणि आता तुमची परिस्थिती पूर्णपणे दुःखी होईल.

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

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

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

आपल्याला जीवनात परत येण्याची गरज आहे. आम्ही ऑनलाइन जातो आणि शोधतो की दीर्घ व्यवहारांमुळे समस्या निर्माण होतात. आम्ही हा व्यवहार शोधून मारतो. आणि आपल्यासाठी सर्व काही सामान्य होत आहे. सर्व काही जसे पाहिजे तसे कार्य करते.

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

आणि प्रश्न: "या क्षणी बेसमध्ये काय होत आहे?" आणि खालील परिस्थिती बेस सह उद्भवते. व्यवहार चार्टवर तुम्ही पाहू शकता की ते थांबले आहे आणि खरोखर कोणतेही दीर्घकालीन व्यवहार नाहीत. परंतु अपघातादरम्यान चिन्हाचा आकार घातकपणे वाढला. आणि तेव्हापासून ते कमी झाले नाहीत. बेसवरील सरासरी वेळ स्थिर झाला आहे. आणि उत्तरे आपल्याला स्वीकारार्ह गतीने पुरेशा प्रमाणात येत आहेत असे दिसते. ऑटोव्हॅक्यूम अधिक सक्रिय झाला आणि चिन्हासह काहीतरी करू लागला, कारण त्याला अधिक डेटा चाळण्याची आवश्यकता आहे.

विशेषतः, खात्यांसह चाचणी प्लेटनुसार, जिथे आम्ही शिल्लक बदलतो: विनंतीसाठी प्रतिसाद वेळ सामान्य स्थितीत परत आल्याचे दिसते. मात्र प्रत्यक्षात ते दीडपट जास्त आहे.

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

एकूणच चांगली, पण परिस्थिती पूर्वीपेक्षा वाईट आहे. या डेटाबेससह कार्य करणार्‍या आमच्या अनुप्रयोगाचा परिणाम म्हणून डेटाबेस डिग्रेडेशन साफ ​​करा.

आणि तेथे काय चालले आहे हे समजून घेण्यासाठी, जर तुम्ही मागील अहवालात नसाल तर, आता एक छोटा सिद्धांत घेऊ. अंतर्गत प्रक्रियेबद्दल सिद्धांत. कार व्हॅक्यूम का आणि ते काय करते?

शब्दशः थोडक्यात समजून घेण्यासाठी. कधीतरी आमच्याकडे एक टेबल असते. आमच्याकडे टेबलमध्ये पंक्ती आहेत. या ओळी सक्रिय, जिवंत असू शकतात आणि आपल्याला आता काय हवे आहे. ते चित्रात हिरव्या रंगात चिन्हांकित आहेत. आणि तेथे डेड लाइन्स आहेत ज्या आधीच तयार केल्या गेल्या आहेत, अपडेट केल्या गेल्या आहेत आणि त्यावर नवीन नोंदी दिसू लागल्या आहेत. आणि त्यांना चिन्हांकित केले आहे की ते यापुढे डेटाबेससाठी स्वारस्यपूर्ण नाहीत. परंतु पोस्टग्रेस वैशिष्ट्यामुळे ते टेबलमध्ये आहेत.

तुम्हाला कार व्हॅक्यूमची गरज का आहे? काही क्षणी, ऑटोव्हॅक्यूम येतो, डेटाबेसमध्ये प्रवेश करतो आणि त्याला विचारतो: "कृपया मला सध्या डेटाबेसमध्ये उघडलेल्या सर्वात जुन्या व्यवहाराचा आयडी द्या." डेटाबेस हा आयडी परत करतो. आणि ऑटोव्हॅक्यूम, त्यावर अवलंबून, टेबलमधील ओळींमधून क्रमवारी लावते. आणि जर त्याने पाहिले की काही ओळी जुन्या व्यवहारांद्वारे बदलल्या गेल्या आहेत, तर त्याला त्या ओळी म्हणून चिन्हांकित करण्याचा अधिकार आहे ज्याचा आपण भविष्यात नवीन डेटा लिहून पुन्हा वापरू शकतो. ही एक पार्श्वभूमी प्रक्रिया आहे.

यावेळी, आम्ही डेटाबेससह कार्य करणे सुरू ठेवतो आणि टेबलमध्ये काही बदल करणे सुरू ठेवतो. आणि या ओळींवर, ज्याचा आपण पुन्हा वापर करू शकतो, आम्ही नवीन डेटा लिहितो. आणि अशा प्रकारे आपल्याला एक चक्र मिळते, म्हणजे नेहमी काही मृत जुन्या ओळी तिथे दिसतात, त्याऐवजी आपण आपल्याला आवश्यक असलेल्या नवीन ओळी लिहितो. आणि PostgreSQL साठी कार्य करण्यासाठी ही एक सामान्य स्थिती आहे.

अपघातादरम्यान काय घडले? तिथे ही प्रक्रिया कशी घडली?

आमच्याकडे काही स्थितीत चिन्ह होते, काही जिवंत, काही मृत रेषा. कार व्हॅक्यूम आला आहे. आमचा सर्वात जुना व्यवहार कोणता आहे आणि त्याचा आयडी काय आहे हे त्यांनी डेटाबेसला विचारले. मला हा आयडी मिळाला, जो अनेक तासांपूर्वीचा, कदाचित दहा मिनिटांपूर्वीचा असेल. तुमच्या डेटाबेसवर किती भार आहे यावर ते अवलंबून आहे. आणि तो पुन्हा वापरलेल्या म्हणून चिन्हांकित करू शकणाऱ्या ओळी शोधत गेला. आणि मला आमच्या टेबलमध्ये अशा ओळी सापडल्या नाहीत.

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

प्रत्यक्षात, आम्हाला काम करण्यासाठी ग्रीन लाईनची आवश्यकता आहे. परंतु अशा समस्येच्या वेळी, हे दिसून येते की संपूर्ण टेबलमध्ये हिरव्या रेषांची टक्केवारी अत्यंत कमी आहे.

आणि जेव्हा आपण क्वेरी कार्यान्वित करतो, तेव्हा डेटाबेसला सर्व ओळींमधून जावे लागते: लाल आणि हिरव्या दोन्ही, इच्छित रेषा शोधण्यासाठी. आणि निरुपयोगी डेटासह टेबल फुगवण्याच्या परिणामास "ब्लोट" म्हणतात, जे आमच्या डिस्कची जागा देखील खाऊन टाकते. लक्षात ठेवा, ते 2 MB होते, ते 300 MB झाले? आता मेगाबाइट्स गीगाबाइट्समध्ये बदला आणि तुम्ही तुमची सर्व डिस्क संसाधने त्वरीत गमावाल.

आपल्यासाठी कोणते परिणाम होऊ शकतात?

• माझ्या उदाहरणात, टेबल आणि निर्देशांक 150 पट वाढले. आमच्या काही क्लायंटना जेव्हा डिस्क स्पेस संपुष्टात येऊ लागली तेव्हा त्यांना अधिक घातक प्रकरणे आली आहेत.
• टेबलचा आकार स्वतः कधीही कमी होणार नाही. काही प्रकरणांमध्ये केवळ मृत रेषा असल्यास ऑटोव्हॅक्यूम टेबलची शेपटी कापू शकते. परंतु सतत फिरत असल्याने, एक हिरवी ओळ शेवटी गोठू शकते आणि अद्यतनित केली जाणार नाही, तर इतर सर्व प्लेटच्या सुरुवातीला कुठेतरी लिहून ठेवल्या जातील. परंतु ही एक संभाव्य घटना आहे की आपले टेबल स्वतःच आकाराने लहान होईल, म्हणून आपण त्याची आशा करू नये.
• डेटाबेसला निरुपयोगी ओळींच्या संपूर्ण समूहाद्वारे क्रमवारी लावणे आवश्यक आहे. आणि आम्ही डिस्क संसाधने वाया घालवतो, आम्ही प्रोसेसर संसाधने आणि वीज वाया घालवतो.
• आणि याचा थेट परिणाम आमच्या अर्जावर होतो, कारण जर सुरुवातीला आम्ही विनंतीवर 10 मिलीसेकंद, आमच्या कोडवर 10 मिलीसेकंद खर्च केले, तर क्रॅशच्या वेळी आम्ही विनंतीवर एक सेकंद आणि कोडवर 10 मिलीसेकंद खर्च करू लागलो, म्हणजे ऑर्डर ऍप्लिकेशनच्या कार्यक्षमतेत मोठेपणा कमी झाला. आणि अपघाताचे निराकरण झाल्यावर, आम्ही एका विनंतीवर 20 मिलीसेकंद, कोडवर 10 मिलीसेकंद खर्च करू लागलो. याचा अर्थ उत्पादनात अजूनही दीड पटीने घसरण झाली आहे. आणि हे सर्व गोठवलेल्या एका व्यवहारामुळे झाले आहे, कदाचित आपल्या चुकांमुळे.
• आणि प्रश्न: "आम्ही सर्वकाही परत कसे मिळवू शकतो?" जेणेकरून आमच्याबरोबर सर्व काही ठीक आहे आणि अपघातापूर्वीच्या विनंत्या लवकरात लवकर येतात.

या उद्देशासाठी कार्याचे एक विशिष्ट चक्र आहे जे चालते.

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

एकदा तुम्हाला या सारण्या सापडल्या की, तुम्हाला त्या कॉम्प्रेस कराव्या लागतील. यासाठी आधीच साधने आहेत. आमच्या कंपनीत आम्ही तीन साधने वापरतो. पहिले अंगभूत व्हॅक्यूम फुल आहे. तो क्रूर, कठोर आणि निर्दयी आहे, परंतु कधीकधी तो खूप उपयुक्त असतो. Pg_repack и pgcompacttable - टेबल कॉम्प्रेस करण्यासाठी या तृतीय-पक्ष युटिलिटीज आहेत. आणि ते डेटाबेस अधिक काळजीपूर्वक हाताळतात.

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

आम्ही सर्वकाही दुरुस्त केल्यानंतर आणि सर्वकाही ठीक असल्याची खात्री केल्यानंतर, भविष्यात ही परिस्थिती कशी टाळायची हे आम्हाला माहित असणे आवश्यक आहे:

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

या आलेखांमध्ये, मला तुम्हाला दाखवायचे होते की या प्रकरणात VACUUM FULL सह चिन्हावर गेल्यानंतर डेटाबेसचे चिन्ह आणि वर्तन कसे बदलले. हे माझ्यासाठी उत्पादन नाही.

सारणीचा आकार ताबडतोब दोन मेगाबाइट्सच्या सामान्य ऑपरेटिंग स्थितीवर परत आला. याचा सर्व्हरच्या सरासरी प्रतिसाद वेळेवर फारसा परिणाम झाला नाही.

परंतु विशेषत: आमच्या चाचणी चिन्हासाठी, जेथे आम्ही खाते शिल्लक अद्यतनित केले, आम्ही पाहतो की साइनमधील डेटा अद्यतनित करण्याच्या विनंतीसाठी सरासरी प्रतिसाद वेळ पूर्व-आणीबाणी स्तरांवर कमी केला गेला आहे. ही विनंती पूर्ण करण्यासाठी प्रोसेसरने वापरलेली संसाधने देखील क्रॅशपूर्व पातळीपर्यंत खाली आली. आणि खालचा उजवा आलेख दर्शवितो की टेबल संकुचित होण्यापूर्वी तेथे असलेल्या मृत रेषांच्या ढिगाऱ्यातून न जाता आता आपल्याला आवश्यक असलेली रेषा लगेचच सापडते. आणि सरासरी विनंती वेळ अंदाजे समान पातळीवर राहिली. पण इथे माझ्या हार्डवेअरमध्ये एक त्रुटी आहे.

इथेच पहिली कथा संपते. हे सर्वात सामान्य आहे. आणि क्लायंटचा अनुभव आणि प्रोग्रामर किती पात्र आहेत याची पर्वा न करता हे प्रत्येकासाठी घडते. लवकरच किंवा नंतर हे घडते.

दुसरी कथा, ज्यामध्ये आम्ही लोड वितरित करतो आणि सर्व्हर संसाधने ऑप्टिमाइझ करतो

• आम्ही आधीच मोठे झालो आहोत आणि गंभीर मुले झालो आहोत. आणि आम्ही समजतो की आमच्याकडे एक प्रतिकृती आहे आणि भार संतुलित करणे आमच्यासाठी चांगले होईल: मास्टरला लिहा आणि प्रतिकृतीमधून वाचा. आणि सहसा ही परिस्थिती उद्भवते जेव्हा आम्हाला काही अहवाल किंवा ETL तयार करायचे असतात. आणि व्यवसाय याबद्दल खूप आनंदी आहे. त्याला खरोखर खूप जटिल विश्लेषणासह विविध प्रकारचे अहवाल हवे आहेत.
• अहवालांना बरेच तास लागतात, कारण जटिल विश्लेषणे मिलिसेकंदांमध्ये मोजली जाऊ शकत नाहीत. आम्ही, शूर मुलांप्रमाणे, कोड लिहितो. इन्सर्शन ऍप्लिकेशनमध्ये आम्ही मास्टरवर रेकॉर्डिंग करतो, आणि प्रतिकृतीवरील अहवाल कार्यान्वित करतो.
• भार वितरण.
• सर्व काही उत्तम प्रकारे कार्य करते. आम्ही महान आहोत.

आणि ही परिस्थिती कशी दिसते? विशेषत: या आलेखांवर, मी व्यवहार कालावधीसाठी प्रतिकृतीमधून व्यवहारांचा कालावधी देखील जोडला आहे. इतर सर्व आलेख फक्त मास्टर सर्व्हरचा संदर्भ घेतात.

तोपर्यंत माझा रिपोर्ट बोर्ड मोठा झाला होता. त्यापैकी अधिक आहेत. आम्ही पाहतो की सरासरी सर्व्हर प्रतिसाद वेळ स्थिर आहे. आम्ही पाहतो की प्रतिकृतीवर आमचा दीर्घकाळ चालणारा व्यवहार आहे जो 2 तास चालतो. आम्ही ऑटोव्हॅक्यूमचे शांत ऑपरेशन पाहतो, जे मृत रेषांवर प्रक्रिया करते. आणि आमच्याबरोबर सर्व काही ठीक आहे.

विशेषतः, चाचणी केलेल्या प्लेटनुसार, आम्ही तेथे खाते शिल्लक अद्यतनित करणे सुरू ठेवतो. आणि आमच्याकडे विनंत्यांसाठी स्थिर प्रतिसाद वेळ, स्थिर संसाधन वापर आहे. आमच्याबरोबर सर्व काही ठीक आहे.

प्रतिकृतीसह संघर्षामुळे हे अहवाल परत येऊ लागेपर्यंत सर्व काही ठीक आहे. आणि ते नियमित अंतराने परत गोळीबार करतात.

आम्ही ऑनलाइन जातो आणि हे का घडत आहे ते वाचायला सुरुवात करतो. आणि आम्ही एक उपाय शोधतो.

पहिला उपाय म्हणजे प्रतिकृती लेटन्सी वाढवणे. आम्हाला माहित आहे की आमचा अहवाल 3 तास चालतो. आम्ही प्रतिकृती विलंब 3 तासांवर सेट केला. आम्ही सर्वकाही लाँच करत आहोत, परंतु आम्हाला अजूनही काही वेळा रद्द केल्या जाणाऱ्या अहवालांमध्ये समस्या येत आहेत.

सर्वकाही परिपूर्ण असावे अशी आमची इच्छा आहे. आम्ही पुढे चढतो. आणि आम्हाला इंटरनेटवर एक छान सेटिंग सापडली - hot_standby_feedback. चला ते चालू करूया. हॉट_स्टँडबाय_फीडबॅक आम्हाला मास्टरवर ऑटोव्हॅक्यूम मागे ठेवण्याची परवानगी देतो. अशा प्रकारे, आम्ही प्रतिकृती संघर्षांपासून पूर्णपणे मुक्त होतो. आणि अहवालांसह सर्वकाही आमच्यासाठी चांगले कार्य करते.

आणि यावेळी मास्टर सर्व्हरचे काय होत आहे? आणि आम्ही मास्टर सर्व्हरसह संपूर्ण अडचणीत आहोत. आता या दोन्ही सेटिंग्ज सक्षम केल्यावर आम्ही आलेख पाहत आहोत. आणि आम्ही पाहतो की आमच्या प्रतिकृतीवरील सत्राचा मास्टर सर्व्हरवरील परिस्थितीवर कसा तरी प्रभाव पडू लागला. तिचा परिणाम होतो कारण तिने ऑटोव्हॅक्यूमला विराम दिला, ज्यामुळे मृत रेषा साफ होतात. आमच्या टेबलचा आकार पुन्हा गगनाला भिडला आहे. संपूर्ण डेटाबेसवर सरासरी क्वेरी एक्झिक्यूशन वेळ देखील गगनाला भिडला. ऑटोव्हॅक्यूम्स थोडेसे घट्ट झाले.

विशेषतः, आमच्या प्लेटवरून, आम्ही पाहतो की त्यावरील डेटा अपडेट देखील आकाशात झेप घेते. त्याचप्रमाणे CPU वापर मोठ्या प्रमाणात वाढला आहे. आम्ही पुन्हा मोठ्या संख्येने मृत, निरुपयोगी ओळींमधून जात आहोत. आणि या चिन्हासाठी प्रतिसाद वेळ आणि व्यवहारांची संख्या कमी झाली आहे.

मी आधी काय बोलत होतो हे आपल्याला माहित नसल्यास ते कसे दिसेल?

• आम्ही समस्या शोधू लागतो. जर आम्हाला पहिल्या भागात समस्या आल्या, तर आम्हाला माहित आहे की हे दीर्घ व्यवहारामुळे असू शकते आणि मास्टरकडे जा. आम्हाला मास्टर वर एक समस्या आहे. त्याला सॉसेज. ते गरम होते, त्याची लोड सरासरी सुमारे शंभर आहे.
• तेथे विनंत्या संथ आहेत, परंतु आम्हाला तेथे कोणतेही दीर्घकाळ चालणारे व्यवहार दिसत नाहीत. आणि काय आहे ते आम्हाला समजत नाही. कुठे बघायचे ते समजत नाही.
• आम्ही सर्व्हर उपकरणे तपासतो. कदाचित आमचा RAID क्रॅश झाला. कदाचित आमची मेमरी स्टिक जळून गेली असेल. होय, काहीही होऊ शकते. पण नाही, सर्व्हर नवीन आहेत, सर्व काही ठीक आहे.
• प्रत्येकजण धावत आहे: प्रशासक, विकासक आणि संचालक. काहीही मदत करत नाही.
• आणि काही क्षणी सर्वकाही अचानक स्वतःला दुरुस्त करण्यास सुरवात होते.

यावेळी, आमच्या प्रतिकृतीवरील विनंतीवर प्रक्रिया करून सोडण्यात आले. आम्हाला अहवाल मिळाला. व्यवसाय अजूनही आनंदी आहे. जसे आपण पाहू शकता, आमचे चिन्ह पुन्हा वाढले आहे आणि ते कमी होणार नाही. सत्रांसह आलेखावर, मी प्रतिकृतीमधून या दीर्घ व्यवहाराचा एक तुकडा सोडला आहे जेणेकरून परिस्थिती स्थिर होईपर्यंत किती वेळ लागेल याचा अंदाज लावता येईल.

सत्र संपले. आणि काही काळानंतर सर्व्हर कमी-अधिक क्रमाने येतो. आणि मास्टर सर्व्हरवरील विनंत्यांसाठी सरासरी प्रतिसाद वेळ सामान्य होतो. कारण, शेवटी, ऑटोव्हॅक्यूमला या मृत रेषा स्वच्छ करण्याची आणि चिन्हांकित करण्याची संधी असते. आणि तो आपले काम करू लागला. आणि तो किती लवकर करतो, इतक्या लवकर आपण क्रमाने येऊ.

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

कोणत्याही परिस्थितीत, आम्हाला पहिल्या प्रकरणाप्रमाणे, दीड ते दोन वेळा आणि काहीवेळा अधिक कामगिरी कमी होते.

आम्ही सर्वकाही व्यवस्थित केले आहे असे दिसते. लोड वितरित करा. उपकरणे निष्क्रिय नाहीत. आम्ही आमच्या मनाप्रमाणे विनंत्या विभागल्या, परंतु तरीही सर्व काही वाईट झाले.

• हॉट_स्टँडबाय_फीडबॅक सक्षम करू नका? होय, विशेषतः मजबूत कारणाशिवाय ते चालू करण्याची शिफारस केलेली नाही. कारण हा ट्विस्ट थेट मास्टर सर्व्हरवर परिणाम करतो आणि तेथील ऑटोव्हॅक्यूमचे ऑपरेशन निलंबित करतो. काही प्रतिकृतीवर ते सक्षम करून आणि त्याबद्दल विसरून, आपण मास्टरला मारू शकता आणि अनुप्रयोगासह मोठ्या समस्या मिळवू शकता.
• कमाल_स्टँडबाय_स्ट्रीमिंग_विलंब वाढवायचा? होय, अहवालांसाठी हे खरे आहे. तुमच्याकडे तीन तासांचा अहवाल असल्यास आणि प्रतिकृतीच्या विरोधामुळे तो क्रॅश होऊ नये असे तुम्हाला वाटत असेल, तर फक्त विलंब वाढवा. दीर्घकालीन अहवालासाठी डेटाबेसमध्ये आत्ता आलेल्या डेटाची कधीही आवश्यकता नसते. जर तुमच्याकडे ते तीन तासांसाठी असेल तर तुम्ही ते काही जुन्या डेटा कालावधीसाठी चालवत आहात. आणि तुमच्यासाठी, तीन तासांचा विलंब असो किंवा सहा तासांचा विलंब याने काही फरक पडणार नाही, परंतु तुम्हाला सातत्याने अहवाल प्राप्त होतील आणि ते पडण्यात कोणतीही अडचण येणार नाही.
• स्वाभाविकच, तुम्हाला प्रतिकृतींवर दीर्घ सत्रे नियंत्रित करण्याची आवश्यकता आहे, विशेषत: तुम्ही प्रतिकृतीवर हॉट_स्टँडबाय_फीडबॅक सक्षम करण्याचे ठरवल्यास. कारण काहीही होऊ शकते. आम्ही ही प्रतिकृती विकसकाला दिली आहे जेणेकरून तो प्रश्नांची चाचणी घेऊ शकेल. त्याने एक विलक्षण विनंती लिहिली. त्याने ते सुरू केले आणि चहा प्यायला निघून गेला आणि आम्हाला प्रस्थापित मास्टर मिळाला. किंवा कदाचित आम्ही तेथे चुकीचा अर्ज ठेवला आहे. परिस्थिती विविध आहेत. प्रतिकृतींवरील सत्रांचे मास्टर प्रमाणेच काळजीपूर्वक निरीक्षण करणे आवश्यक आहे.
• आणि जर तुमच्याकडे प्रतिकृतींवर वेगवान आणि लांब प्रश्न असतील, तर या प्रकरणात लोड वितरीत करण्यासाठी त्यांना विभाजित करणे चांगले आहे. streaming_delay ची ही लिंक आहे. वेगवान लोकांसाठी, थोड्या प्रतिकृती विलंबासह एक प्रतिकृती घ्या. दीर्घकाळ चालू असलेल्या अहवाल विनंत्यांसाठी, एक प्रतिकृती ठेवा जी 6 तास किंवा एक दिवस मागे राहू शकते. ही पूर्णपणे सामान्य स्थिती आहे.

आम्ही त्याच प्रकारे परिणाम काढून टाकतो:

• आम्हाला फुगलेल्या टेबल्स सापडतात.
• आणि आम्ही ते आमच्यासाठी अनुकूल असलेल्या सर्वात सोयीस्कर साधनासह संकुचित करतो.

दुसरी गोष्ट इथे संपते. तिसर्‍या कथेकडे वळू.

आमच्यासाठी अगदी सामान्य आहे ज्यामध्ये आम्ही स्थलांतर करतो.

• कोणतेही सॉफ्टवेअर उत्पादन वाढत आहे. त्यासाठीच्या गरजा बदलत आहेत. कोणत्याही परिस्थितीत आम्हाला विकास करायचा आहे. आणि असे घडते की आम्ही आमच्या विकासाचा भाग म्हणून सादर करत असलेल्या नवीन कार्यक्षमतेसाठी आमच्या स्थलांतराच्या संदर्भात अपडेट चालविण्यासाठी आम्हाला टेबलमधील डेटा अद्यतनित करणे आवश्यक आहे.
• जुने डेटा स्वरूप समाधानकारक नाही. आता आपण दुसऱ्या टेबलकडे वळू, जिथे माझे या खात्यांवर व्यवहार आहेत. आणि असे म्हणूया की ते रूबलमध्ये होते आणि आम्ही अचूकता वाढवण्याचा आणि कोपेक्समध्ये करण्याचा निर्णय घेतला. आणि यासाठी आम्हाला अपडेट करणे आवश्यक आहे: व्यवहाराच्या रकमेसह फील्ड शंभरने गुणाकार करा.
• आजच्या जगात, आम्ही स्वयंचलित डेटाबेस आवृत्ती नियंत्रण साधने वापरतो. चल बोलू 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 ला डेटा लिहिण्यासाठी अतिरिक्त डिस्क स्पेस आवश्यक आहे.
• पुढील साधन pg_repack. त्याच्या तत्त्वानुसार, ते व्हॅक्यूम फुल सारखेच आहे, कारण ते जुन्या फायलींमधून नवीन फाइल्समध्ये डेटा पुन्हा लिहिते आणि त्यांना टेबलमध्ये पुनर्स्थित करते. परंतु त्याच वेळी, ते त्याच्या कामाच्या अगदी सुरुवातीस टेबलवर एक विशेष लॉक घेत नाही, परंतु फायली पुनर्स्थित करण्यासाठी आधीच तयार डेटा असतानाच ते घेते. त्याची डिस्क संसाधन आवश्यकता 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, सुरू होताच, लगेचच एक एक्सक्लुझिव्ह लॉक घेतला. आणि जोपर्यंत तो सर्वकाही करत नाही तोपर्यंत तो तिला जाऊ देणार नाही. आणि pg_repack फाईल बदलण्याच्या वेळीच एक अनन्य लॉक घेते. या क्षणी आपण तेथे लिहिणार नाही, परंतु डेटा गमावला जाणार नाही, सर्व काही ठीक होईल.

नमस्कार! आपण कार व्हॅक्यूमच्या ऑपरेशनबद्दल बोललात. लाल, पिवळा आणि हिरवा रेकॉर्डिंग सेल असलेला आलेख होता. म्हणजेच, पिवळे - त्याने त्यांना हटवले म्हणून चिन्हांकित केले. आणि परिणामी, त्यांच्यामध्ये काहीतरी नवीन लिहिता येईल?

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

मला समजते. पण हाच प्रश्न नाही. मी पूर्ण केले नाही. समजा आपल्याकडे एक टेबल आहे. त्यात व्हेरिएबल आकाराचे फील्ड आहेत. आणि जर मी काहीतरी नवीन घालण्याचा प्रयत्न केला तर ते कदाचित जुन्या सेलमध्ये बसणार नाही.

नाही, कोणत्याही परिस्थितीत संपूर्ण ओळ तेथे अद्यतनित केली जाते. Postgres मध्ये दोन डेटा स्टोरेज मॉडेल्स आहेत. ते डेटा प्रकारातून निवडते. टेबलमध्ये थेट संग्रहित केलेला डेटा आहे आणि टॉस डेटा देखील आहे. हे मोठ्या प्रमाणात डेटा आहेत: मजकूर, json. ते स्वतंत्र प्लेट्समध्ये साठवले जातात. आणि या गोळ्यांनुसार, ब्लोटसह समान कथा उद्भवते, म्हणजे सर्व काही समान आहे. ते फक्त स्वतंत्रपणे सूचीबद्ध आहेत.

अहवालाबद्दल धन्यवाद! कालावधी मर्यादित करण्यासाठी स्टेटमेंट टाइमआउट क्वेरी वापरणे स्वीकार्य आहे का?

अगदी मान्य. आम्ही हे सर्वत्र वापरतो. आणि आमच्याकडे आमच्या स्वतःच्या सेवा नसल्यामुळे, आम्ही रिमोट सपोर्ट प्रदान करतो, आमच्याकडे बरेच क्लायंट आहेत. आणि प्रत्येकजण याबद्दल पूर्णपणे समाधानी आहे. म्हणजेच, आमच्याकडे क्रॉन जॉब्स आहेत जे तपासतात. सत्रांचा कालावधी क्लायंटशी फक्त सहमत आहे, ज्यापूर्वी आम्ही सहमत नाही. हे एक मिनिट असू शकते, ते 10 मिनिटे असू शकते. हे बेसवरील भार आणि त्याच्या उद्देशावर अवलंबून असते. पण आपण सर्वजण pg_stat_activity वापरतो.

अहवालाबद्दल धन्यवाद! मी तुमचा अहवाल माझ्या अर्जांवर लागू करण्याचा प्रयत्न करत आहे. आणि असे दिसते की आपण सर्वत्र व्यवहार सुरू करतो आणि तो सर्वत्र स्पष्टपणे पूर्ण करतो. काही अपवाद असल्यास, रोलबॅक अजूनही होतो. आणि मग मी विचार करू लागलो. सर्व केल्यानंतर, व्यवहार स्पष्टपणे सुरू होऊ शकत नाही. हा बहुधा मुलीला इशारा आहे. मी फक्त रेकॉर्ड अपडेट केल्यास, व्यवहार PostgreSQL मध्ये सुरू होईल आणि कनेक्शन डिस्कनेक्ट झाल्यावरच पूर्ण होईल का?

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

म्हणजेच, ते अद्यतनानंतर लगेच बंद होते?

हे सेटिंग्जवर अवलंबून असते. मी एक सेटिंग नाव दिले. हे ऑटो कमिट ऑन आहे. हे अगदी सामान्य आहे. ते सक्षम असल्यास, व्यवहार उघडला आणि बंद झाला. जोपर्यंत तुम्ही स्पष्टपणे "व्यवहार सुरू करा" आणि "व्यवहार समाप्त करा" असे म्हटले नाही, परंतु केवळ सत्रात विनंती सुरू केली.

नमस्कार! अहवालाबद्दल धन्यवाद! चला कल्पना करूया की आपल्याकडे एक डेटाबेस आहे जो सूज आणि सूज आहे आणि नंतर सर्व्हरवरील जागा संपते. या परिस्थितीचे निराकरण करण्यासाठी काही साधने आहेत का?

सर्व्हरवरील जागेचे योग्य निरीक्षण करणे आवश्यक आहे.

उदाहरणार्थ, डीबीए चहासाठी गेला होता, रिसॉर्टमध्ये होता इ.

जेव्हा फाइल सिस्टम तयार केली जाते, तेव्हा कमीतकमी काही प्रकारची बॅकअप जागा तयार केली जाते जिथे डेटा लिहिला जात नाही.

ते पूर्णपणे शून्याच्या खाली असल्यास काय?

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

इतर काही साधने आहेत का?

हे नेहमी हाताने बनवलेले असते. आणि स्थानिक पातळीवर हे स्पष्ट होते की तेथे काय करणे चांगले आहे, कारण काही डेटा गंभीर आहे आणि काही गैर-गंभीर आहे. आणि प्रत्येक डेटाबेस आणि त्यासोबत काम करणार्‍या ऍप्लिकेशनसाठी ते व्यवसायावर अवलंबून असते. हे नेहमीच स्थानिक पातळीवर ठरवले जाते.

अहवालाबद्दल धन्यवाद! माझे दोन प्रश्न आहेत. प्रथम, तुम्ही स्लाईड्स दाखवल्या ज्याने हे दाखवले की जेव्हा व्यवहार अडकतात तेव्हा टेबलस्पेस आकार आणि निर्देशांक आकार दोन्ही वाढतात. आणि पुढे अहवालात टॅब्लेट पॅकेज करणाऱ्या उपयुक्ततांचा समूह होता. निर्देशांकाचे काय?

तेही पॅक करतात.

पण व्हॅक्यूम निर्देशांकावर परिणाम करत नाही?

काही इंडेक्ससह काम करतात. उदाहरणार्थ, pg_rapack, pgcompacttable. व्हॅक्यूम अनुक्रमणिका पुन्हा तयार करतो आणि त्यांना प्रभावित करतो. VACUUM FULL सह कल्पना म्हणजे सर्वकाही ओव्हरराईट करणे, म्हणजेच ते प्रत्येकासह कार्य करते.

आणि दुसरा प्रश्न. प्रतिकृतींवरील अहवाल प्रतिकृतीवरच इतके अवलंबून का असतात हे मला समजत नाही. मला असे वाटले की अहवाल वाचले जातात आणि प्रतिकृती लिहिली जातात.

प्रतिकृती संघर्ष कशामुळे होतो? आमच्याकडे एक मास्टर आहे ज्यावर प्रक्रिया होतात. आमच्याकडे कार व्हॅक्यूम चालू आहे. ऑटोव्हॅक्यूम प्रत्यक्षात काय करते? तो काही जुन्या ओळी कापत आहे. यावेळी आमच्याकडे या जुन्या ओळी वाचणार्‍या प्रतिकृतीवर विनंती असल्यास आणि मास्टरवर अशी परिस्थिती उद्भवली की ऑटोव्हॅक्यूमने या ओळी ओव्हरराईटिंगसाठी शक्य तितक्या चिन्हांकित केल्या, तर आम्ही त्या ओव्हरराईट केल्या. आणि आम्हाला एक डेटा पॅकेट प्राप्त झाले, जेव्हा आम्हाला प्रतिकृतीवर विनंती आवश्यक असलेल्या ओळी पुन्हा लिहिण्याची आवश्यकता असेल, तेव्हा प्रतिकृती प्रक्रिया तुम्ही कॉन्फिगर केलेल्या कालबाह्यतेची प्रतीक्षा करेल. आणि मग PostgreSQL ठरवेल की त्यात काय अधिक महत्त्वाचे आहे. आणि विनंतीपेक्षा प्रतिकृती त्याच्यासाठी अधिक महत्त्वाची आहे आणि प्रतिकृतीवर हे बदल करण्यासाठी तो विनंती शूट करेल.

आंद्रे, मला एक प्रश्न आहे. सादरीकरणादरम्यान तुम्ही दाखवलेले हे अप्रतिम आलेख, हे तुमच्याच कोणत्यातरी उपयुक्ततेच्या कार्याचे फलित आहेत का? आलेख कसे तयार केले गेले?

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

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

होय. हे एक व्यावसायिक उत्पादन आहे.

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