VACUUM और ANALYZE दो सबसे महत्वपूर्ण PostgreSQL डेटाबेस रखरखाव संचालन हैं।
एक तालिका में "मृत टुपल्स" के कब्जे वाले स्थान को पुनर्प्राप्त करने के लिए एक वैक्यूम का उपयोग किया जाता है। एक मृत टपल तब बनाया जाता है जब कोई रिकॉर्ड या तो हटा दिया जाता है या अपडेट किया जाता है (एक डिलीट के बाद एक इंसर्ट)। PostgreSQL तालिका से पुरानी पंक्ति को भौतिक रूप से नहीं हटाता है, लेकिन उस पर एक "मार्कर" डालता है ताकि क्वेरी उस पंक्ति को वापस न करें। जब एक निर्वात प्रक्रिया चलती है, तो इन मृत ट्यूपल्स द्वारा कब्जा किए गए स्थान को अन्य ट्यूपल्स द्वारा पुन:प्रयोज्य के रूप में चिह्नित किया जाता है।
एक "विश्लेषण" ऑपरेशन वही करता है जो उसका नाम कहता है - यह डेटाबेस की तालिकाओं की सामग्री का विश्लेषण करता है और प्रत्येक तालिका के प्रत्येक कॉलम में मूल्यों के वितरण के बारे में आंकड़े एकत्र करता है। PostgreSQL क्वेरी इंजन इन आँकड़ों का उपयोग सर्वोत्तम क्वेरी योजना खोजने के लिए करता है। जैसे-जैसे पंक्तियों को डेटाबेस में डाला जाता है, हटाया जाता है और अद्यतन किया जाता है, कॉलम आंकड़े भी बदलते हैं। विश्लेषण - या तो डीबीए द्वारा मैन्युअल रूप से चलाया जाता है या ऑटोवैक्यूम के बाद PostgreSQL द्वारा स्वचालित रूप से चलाया जाता है - यह सुनिश्चित करता है कि आंकड़े अद्यतित हैं।
हालांकि वे अपेक्षाकृत सीधे लगते हैं, परदे के पीछे, वैक्यूमिंग और विश्लेषण दो जटिल प्रक्रियाएं हैं। सौभाग्य से, डीबीए को अपने आंतरिक के बारे में ज्यादा चिंता करने की ज़रूरत नहीं है। हालांकि, वे अक्सर इन प्रक्रियाओं को मैन्युअल रूप से चलाने या कॉन्फ़िगरेशन पैरामीटर के लिए इष्टतम मान सेट करने के बारे में भ्रमित होते हैं।
इस लेख में, हम वैक्यूम और विश्लेषण के लिए कुछ सर्वोत्तम अभ्यास साझा करेंगे।
टिप 1:बिना कारण के मैन्युअल वैक्यूम या विश्लेषण न चलाएं
PostgreSQL वैक्यूमिंग (ऑटोवैक्यूम या मैनुअल वैक्यूम) टेबल ब्लोट को कम करता है और ट्रांजेक्शन आईडी रैपअराउंड को रोकता है। ऑटोवैक्यूम मृत टुपल्स द्वारा लिए गए डिस्क स्थान को पुनर्प्राप्त नहीं करता है। हालांकि, वैक्यूम पूर्ण running चल रहा है आदेश ऐसा करेगा। हालांकि, VACUUM FULL का प्रदर्शन निहितार्थ है। लक्ष्य तालिका को विशेष रूप से ऑपरेशन के दौरान बंद कर दिया जाता है, जिससे तालिका पर पढ़ने को भी रोका जा सकता है। प्रक्रिया तालिका की एक पूर्ण प्रतिलिपि भी बनाती है, जिसे चलाने पर अतिरिक्त डिस्क स्थान की आवश्यकता होती है। हम अनुशंसा करते हैं कि VACUUM FULL को तब तक न चलाएं जब तक कि ब्लोट का प्रतिशत बहुत अधिक न हो, और क्वेरीज़ बुरी तरह प्रभावित हों। हम इसके लिए न्यूनतम डेटाबेस गतिविधि की अवधियों का उपयोग करने की भी अनुशंसा करते हैं।
संपूर्ण डेटाबेस पर बहुत बार मैन्युअल वैक्यूम नहीं चलाना भी एक सर्वोत्तम अभ्यास है; लक्ष्य डेटाबेस को ऑटोवैक्यूम प्रक्रिया द्वारा पहले से ही बेहतर तरीके से वैक्यूम किया जा सकता है। नतीजतन, एक मैनुअल वैक्यूम किसी भी मृत टुपल्स को नहीं हटा सकता है, लेकिन अनावश्यक I/O लोड या CPU स्पाइक्स का कारण बन सकता है। यदि आवश्यक हो, तो मैनुअल वैक्यूम केवल टेबल-दर-टेबल के आधार पर चलाया जाना चाहिए, जब इसकी आवश्यकता हो, जैसे लाइव पंक्तियों के मृत पंक्तियों के कम अनुपात, या ऑटोवैक्यूम के बीच बड़े अंतराल। साथ ही, उपयोगकर्ता की गतिविधि न्यूनतम होने पर मैनुअल वैक्यूम चलाना चाहिए।
Autovacuum तालिका के डेटा वितरण आंकड़ों को भी अद्यतित रखता है (यह उनका पुनर्निर्माण नहीं करता है)। मैन्युअल रूप से चलने पर, विश्लेषण कमांड वास्तव में इन आँकड़ों को अद्यतन करने के बजाय उनका पुनर्निर्माण करता है। फिर से, आँकड़ों का पुनर्निर्माण जब वे पहले से ही एक नियमित ऑटोवैक्यूम द्वारा बेहतर रूप से अपडेट किए जाते हैं, तो सिस्टम संसाधनों पर अनावश्यक दबाव हो सकता है।
वह समय जब आपको ANALYZE को मैन्युअल रूप से चलाना होगा, लक्ष्य तालिका में डेटा को बल्क लोड करने के तुरंत बाद होता है। मौजूदा तालिका में नई पंक्तियों की एक बड़ी संख्या (यहां तक कि कुछ सौ) इसके कॉलम डेटा वितरण को महत्वपूर्ण रूप से कम कर देगी। नई पंक्तियों के कारण कोई भी मौजूदा स्तंभ आँकड़े पुराने हो जाएंगे। जब क्वेरी ऑप्टिमाइज़र ऐसे आँकड़ों का उपयोग करता है, तो क्वेरी प्रदर्शन वास्तव में धीमा हो सकता है। इन मामलों में, आंकड़ों के पूरी तरह से पुनर्निर्माण के लिए डेटा लोड के तुरंत बाद ANALYZE कमांड चलाना ऑटोवैक्यूम के शुरू होने की प्रतीक्षा करने से बेहतर विकल्प है।
टिप 2:ऑटोवैक्यूम थ्रेसहोल्ड को फाइन-ट्यून करें
postgresql.conf में ऑटोवैक्यूम को जांचना या ट्यून करना और कॉन्फ़िगरेशन पैरामीटर का विश्लेषण करना आवश्यक है फ़ाइल या व्यक्तिगत तालिका गुणों में ऑटोवैक्यूम और प्रदर्शन लाभ के बीच संतुलन बनाने के लिए।
PostgreSQL दो कॉन्फ़िगरेशन पैरामीटर का उपयोग यह तय करने के लिए करता है कि ऑटोवैक्यूम कब शुरू किया जाए:
- autovacuum_vacuum_threshold :इसका डिफ़ॉल्ट मान 50 . है
- autovacuum_vacuum_scale_factor :इसका डिफ़ॉल्ट मान 0.2 है
साथ में, ये पैरामीटर पोस्टग्रेएसक्यूएल को ऑटोवैक्यूम शुरू करने के लिए कहते हैं जब किसी तालिका में मृत पंक्तियों की संख्या उस तालिका में पंक्तियों की संख्या से अधिक हो जाती है, साथ ही वैक्यूम थ्रेशोल्ड से गुणा किया जाता है। दूसरे शब्दों में, PostgreSQL एक टेबल पर ऑटोवैक्यूम शुरू करेगा जब:
pg_stat_user_tables.n_dead_tup > (pg_class.reltuples x autovacuum_vacuum_scale_factor) + autovacuum_vacuum_threshold
छोटे से मध्यम आकार की तालिकाओं के लिए, यह पर्याप्त हो सकता है। उदाहरण के लिए, 10,000 पंक्तियों वाली एक तालिका, ऑटोवैक्यूम शुरू होने से पहले मृत पंक्तियों की संख्या 2,050 ((10,000 x 0.2) + 50) से अधिक होनी चाहिए।
डेटाबेस में प्रत्येक तालिका डेटा संशोधन की समान दर का अनुभव नहीं करती है। आमतौर पर, कुछ बड़ी तालिकाओं में बार-बार डेटा संशोधन का अनुभव होगा, और परिणामस्वरूप, मृत पंक्तियों की संख्या अधिक होगी। ऐसी तालिकाओं के लिए डिफ़ॉल्ट मान काम नहीं कर सकते हैं। उदाहरण के लिए, डिफ़ॉल्ट मानों के साथ, 1 मिलियन पंक्तियों वाली तालिका में ऑटोवैक्यूम शुरू होने से पहले 200,050 से अधिक मृत पंक्तियों की आवश्यकता होगी ((1000,000 x 0.2) + 50)। इसका मतलब यह हो सकता है कि ऑटोवैक्यूम के बीच लंबे अंतराल, तेजी से लंबे ऑटोवैक्यूम समय, और बदतर, ऑटोवैक्यूम बिल्कुल भी नहीं चल रहा है अगर टेबल पर सक्रिय लेनदेन इसे लॉक कर रहे हैं।
इसलिए, लक्ष्य इन थ्रेसहोल्ड को इष्टतम मूल्यों पर सेट करना होना चाहिए ताकि ऑटोवैक्यूम नियमित अंतराल पर हो सके और मृत पंक्तियों की संख्या को अपेक्षाकृत कम रखते हुए लंबा समय न लें (और उपयोगकर्ता सत्रों को प्रभावित करें)।
एक दृष्टिकोण एक या दूसरे पैरामीटर का उपयोग करना है। इसलिए, यदि हम autovacuum_vacuum_scale_factor को 0 पर सेट करते हैं और इसके बजाय autovacuum_vacuum_threshold को 5,000 पर सेट करते हैं, तो एक तालिका स्वतः खाली हो जाएगी जब उसकी मृत पंक्तियों की संख्या 5,000 से अधिक होगी।
टिप 3:थ्रेसहोल्ड को अपने आप विश्लेषण करने के लिए फ़ाइन-ट्यून करें
ऑटोवैक्यूम की तरह, ऑटोवैक्यूम भी दो मापदंडों का उपयोग करता है जो यह तय करते हैं कि ऑटोवैक्यूम भी ऑटोएनालिसिस को कब ट्रिगर करेगा:
- autovacuum_analyze_threshold :इसका डिफ़ॉल्ट मान 50 . है
- autovacuum_analyze_scale_factor :इसका डिफ़ॉल्ट मान 0.1 है
ऑटोवैक्यूम की तरह, autovacuum_analyze_threshold पैरामीटर को एक ऐसे मान पर सेट किया जा सकता है जो एक स्वतः विश्लेषण शुरू होने से पहले एक तालिका में सम्मिलित, हटाए गए या अपडेट किए गए ट्यूपल्स की संख्या को निर्धारित करता है। हम इस पैरामीटर को बड़े और उच्च-लेनदेन तालिकाओं पर अलग से सेट करने की अनुशंसा करते हैं। तालिका कॉन्फ़िगरेशन postgresql.conf मानों को ओवरराइड कर देगा।
नीचे दिया गया कोड स्निपेट तालिका के लिए autovacuum_analyze_threshold सेटिंग को संशोधित करने के लिए SQL सिंटैक्स दिखाता है।
ALTER TABLE <table_name> SET (autovacuum_analyze_threshold = <threshold rows>)
टिप 4:ऑटोवैक्यूम वर्कर्स को फाइन-ट्यून करें
एक अन्य पैरामीटर जिसे अक्सर डीबीए द्वारा अनदेखा किया जाता है वह है autovacuum_max_workers , जिसका डिफ़ॉल्ट मान 3 है। ऑटोवैक्यूम एक एकल प्रक्रिया नहीं है, बल्कि समानांतर में चलने वाले कई अलग-अलग वैक्यूम थ्रेड हैं। एकाधिक श्रमिकों को निर्दिष्ट करने का कारण यह सुनिश्चित करना है कि बड़ी तालिकाओं को खाली करने से छोटी तालिकाओं और उपयोगकर्ता सत्रों को खाली नहीं किया जा रहा है। Autovacuum_max_workers पैरामीटर PostgreSQL को क्लीनअप करने के लिए ऑटोवैक्यूम वर्कर थ्रेड्स की संख्या बढ़ाने के लिए कहता है।
PostgreSQL डीबीए द्वारा एक सामान्य अभ्यास इस उम्मीद में अधिकतम कार्यकर्ता धागे की संख्या में वृद्धि करना है कि यह ऑटोवैक्यूम को गति देगा। यह काम नहीं करता है क्योंकि सभी थ्रेड समान autovacuum_vacuum_cost_limit साझा करते हैं , जिसका डिफ़ॉल्ट मान 200 है। प्रत्येक ऑटोवैक्यूम थ्रेड को नीचे दिखाए गए इस सूत्र का उपयोग करके एक लागत सीमा दी गई है:
individual thread’s cost_limit = autovacuum_vacuum_cost_limit / autovacuum_max_workers
ऑटोवैक्यूम थ्रेड द्वारा किए गए कार्य की लागत की गणना तीन मापदंडों का उपयोग करके की जाती है:
- vacuum_cost_page_hit :इसका डिफ़ॉल्ट मान 1 . है
- vacuum_cost_page_miss :इसका डिफ़ॉल्ट मान 10 . है
- vacuum_cost_page_dirty :इसका डिफ़ॉल्ट मान 20 . है
इन मापदंडों का मतलब यह है:
- जब वैक्यूम थ्रेड को डेटा पेज मिल जाता है जिसे साझा बफर में साफ करना है, तो लागत 1 है।
- यदि डेटा पृष्ठ साझा बफर में नहीं है, लेकिन OS कैश में है, तो लागत 10 होगी।
- यदि पृष्ठ को गंदा चिह्नित करना है क्योंकि वैक्यूम थ्रेड को मृत पंक्तियों को हटाना है, तो लागत 20 होगी।
वर्कर थ्रेड्स की बढ़ी हुई संख्या प्रत्येक थ्रेड के लिए लागत सीमा को कम कर देगी। चूंकि प्रत्येक थ्रेड को कम लागत सीमा सौंपी जाती है, इसलिए यह अधिक बार सो जाएगा क्योंकि लागत सीमा आसानी से पहुंच जाती है, अंततः पूरी वैक्यूम प्रक्रिया धीमी गति से चलती है। हम अनुशंसा करते हैं कि autovacuum_vacuum_cost_limit को 2000 जैसे उच्च मान तक बढ़ाएँ, और फिर वर्कर थ्रेड्स की अधिकतम संख्या को समायोजित करें।
एक बेहतर तरीका यह है कि इन मापदंडों को केवल आवश्यक होने पर अलग-अलग तालिकाओं के लिए ट्यून किया जाए। उदाहरण के लिए, यदि एक बड़ी लेन-देन तालिका का ऑटोवैक्यूम बहुत अधिक समय ले रहा है, तो तालिका को अस्थायी रूप से अपनी वैक्यूम लागत सीमा और लागत विलंब का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। लागत सीमा और विलंब postgresql.conf में सेट किए गए सिस्टम-वाइड मानों को ओवरराइड कर देगा।
नीचे दिया गया कोड स्निपेट दिखाता है कि अलग-अलग तालिकाओं को कैसे कॉन्फ़िगर किया जाए।
ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_limit = <large_value>) ALTER TABLE <table_name> SET (autovacuum_vacuum_cost_delay = <lower_cost_delay>)
पहले पैरामीटर का उपयोग करने से यह सुनिश्चित होगा कि टेबल को सौंपा गया ऑटोवैक्यूम धागा सोने से पहले अधिक काम करेगा। autovacuum_vacuum_cost_delay . को कम करना इसका मतलब यह भी होगा कि धागा कम समय में सो रहा है।
अंतिम विचार
जैसा कि आप देख सकते हैं, वैक्यूम और विश्लेषण के लिए कॉन्फ़िगरेशन पैरामीटर बदलना सीधा है, लेकिन इसे पहले सावधानीपूर्वक अवलोकन की आवश्यकता है। प्रत्येक डेटाबेस अपने आकार, यातायात पैटर्न और लेनदेन की दर के मामले में भिन्न होता है। हम अनुशंसा करते हैं कि पैरामीटर बदलने या मैन्युअल वैक्यूम/विश्लेषण व्यवस्था शुरू करने से पहले डीबीए अपने डेटाबेस के बारे में पर्याप्त जानकारी एकत्र करके शुरू करें। ऐसी जानकारी हो सकती है:
- प्रत्येक तालिका में पंक्तियों की संख्या
- प्रत्येक तालिका में मृत टुपल्स की संख्या
- हर टेबल के लिए आखिरी वैक्यूम का समय
- प्रत्येक तालिका के लिए अंतिम विश्लेषण का समय
- प्रत्येक तालिका में डेटा डालने/अपडेट/हटाने की दर
- प्रत्येक टेबल के लिए ऑटोवैक्यूम द्वारा लिया गया समय
- टेबल को वैक्यूम न करने की चेतावनी
- सबसे महत्वपूर्ण क्वेरी और उनके द्वारा एक्सेस की जाने वाली टेबल का वर्तमान प्रदर्शन
- मैन्युअल वैक्यूम/विश्लेषण के बाद समान क्वेरी का प्रदर्शन
यहां से, डीबीए अनुकूलन शुरू करने के लिए कुछ "पायलट" तालिकाओं का चयन कर सकते हैं। वे टेबल के लिए वैक्यूम/विश्लेषण गुणों को बदलना शुरू कर सकते हैं और प्रदर्शन की जांच कर सकते हैं। PostgreSQL एक स्मार्ट डेटाबेस इंजन है - DBA को अक्सर यह सबसे अच्छा लगेगा कि PostgreSQL को मैन्युअल रूप से करने के बजाय वैक्यूमिंग और विश्लेषण करने दें।
