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

फिर हमने इन-पेज वैक्यूम (और HOT अपडेट) और वैक्यूम की खोज की । अब हम ऑटोवैक्युम में देखेंगे।

Autovacuum

हमने पहले ही उल्लेख किया है कि आम तौर पर (यानी, जब कुछ भी लंबे समय तक लेन-देन क्षितिज नहीं रखता है) VACUUM आमतौर पर अपना काम करता है। समस्या यह है कि इसे कितनी बार कॉल किया जाए।

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

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

ध्यान दें कि किसी भी तरह से शेड्यूल पर VACUUM लॉन्च करना समस्या का समाधान नहीं करता है क्योंकि समय के साथ कार्यभार बदल सकता है। यदि तालिका अधिक तीव्रता से बदलना शुरू करती है, तो इसे अधिक बार वैक्यूम किया जाना चाहिए।

ऑटोवैक्यूम ठीक वैसी ही तकनीक है जो हमें तालिका में परिवर्तन के आधार पर वैक्यूमिंग शुरू करने में सक्षम बनाती है।

जब ऑटोवैक्यूम चालू होता है ( ऑटोवैक्यूम कॉन्फ़िगरेशन पैरामीटर सेट), तो ऑटोवैक्यूम लांचर डेमॉन प्रक्रिया शुरू की जाती है, जो काम की योजना बनाती है। वैक्यूमिंग स्वयं ऑटोवैक्यूम कार्यकर्ता प्रक्रियाओं द्वारा किया जाता है, जिनमें से कई उदाहरण समानांतर में चल सकते हैं।

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

एक बार प्रत्येक ऑटोवैक्यूम_नैपिटेक सेकंड में, ऑटोवैक्यूम लॉन्चर शुरू होता है ( पोस्टमास्टर प्रक्रिया का उपयोग करके) सूची के प्रत्येक डेटाबेस के लिए एक कार्यकर्ता प्रक्रिया। दूसरे शब्दों में, यदि किसी डेटाबेस में कुछ गतिविधि है, तो ऑटोवेक्यूम_नैप्टीम सेकंड के अंतराल पर कार्यकर्ता प्रक्रियाओं को इसमें भेजा जाएगा। यह अंत करने के लिए, यदि कुछ (एन) सक्रिय डेटाबेस उपलब्ध हैं, तो श्रमिक प्रक्रियाओं को एन बार लॉन्च किया जाता है, जैसा कि प्रत्येक ऑटोवैक्यूम_नैपिटाइम सेकंड में होता है। लेकिन एक साथ चलने वाली श्रमिक प्रक्रियाओं की कुल संख्या ऑटोवैकोम_मैक्स_वर्कर्स पैरामीटर द्वारा सीमित है।

जब शुरू किया जाता है, तो एक कार्यकर्ता प्रक्रिया इसे सौंपे गए डेटाबेस से जोड़ती है और इसकी सूची तैयार करने के साथ शुरू होती है:

• सभी तालिकाओं, भौतिक विचारों और टोस्ट तालिकाओं में वैक्यूमिंग की आवश्यकता होती है।
• सभी तालिकाओं और भौतिक विचारों में विश्लेषण की आवश्यकता होती है (टोस्ट तालिका का विश्लेषण नहीं किया जाता है क्योंकि वे हमेशा सूचकांक पहुंच के साथ पहुंच जाते हैं)।

फिर कार्यकर्ता एक बार में सूची पर वस्तुओं को रिक्तियों और / या विश्लेषण करता है और वैक्यूमिंग समाप्त होने पर पूरा करता है।

यदि प्रक्रिया autovacuum_naptime सेकंड में नियोजित सभी कार्य नहीं कर पाई , तो ऑटोवैक्यूम लॉन्चर प्रक्रिया इस डेटाबेस में एक और कार्यकर्ता प्रक्रिया को भेज देगी, और वे एक साथ काम करेंगे। "एक साथ" बस का अर्थ है कि दूसरी प्रक्रिया अपनी सूची बनाएगी और इसके माध्यम से काम करेगी। इसलिए, समानांतर में केवल अलग-अलग तालिकाओं को संसाधित किया जाएगा, लेकिन एक तालिका के स्तर पर कोई समानता नहीं है - यदि कार्यकर्ता प्रक्रियाओं में से एक पहले से ही एक तालिका को संभाल रहा है, तो दूसरी प्रक्रिया इसे छोड़ देगी और आगे बढ़ेगी।

अब आइए अधिक विस्तार से स्पष्ट करें कि "वैक्यूमिंग की आवश्यकता" और "विश्लेषण की आवश्यकता है" से क्या मतलब है।

हाल ही में पैच को प्रतिबद्ध किया गया था जो वैक्यूम को पृष्ठभूमि के श्रमिकों के साथ अनुक्रमणिका को संसाधित करने की अनुमति देता है।

क्या तालिकाओं को वैक्यूमिंग की आवश्यकता होती है?

यदि मृतक की संख्या (यानी, पुरानी) ट्यूपल्स निर्दिष्ट सीमा से अधिक हो तो वैक्यूमिंग आवश्यक माना जाता है। आँकड़े संग्राहक स्थायी रूप से मृत pg_stat_all_tables की संख्या पर नज़र रख रहे हैं, जो pg_stat_all_tables तालिका में संग्रहीत है। और दो पैरामीटर सीमा को निर्दिष्ट करते हैं:

• autovacuum_vacuum_threshold एक निरपेक्ष मान (ट्यूपल्स की संख्या) को परिभाषित करता है।
• autovacuum_vacuum_scale_factor तालिका में पंक्तियों के हिस्से को परिभाषित करता है।

सारांश में: यदि pg_stat_all_tables.n_dead_tup > = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor - pg_class.reltupes यदि pg_stat_all_tables.n_dead_tup आवश्यक है।

डिफ़ॉल्ट सेटिंग्स के साथ, autovacuum_vacuum_threshold = 50 और autovacuum_vacuum_scale_factor = 0.2। autovacuum_vacuum_scale_factor , निश्चित रूप से, यहां सबसे महत्वपूर्ण है - यह यह पैरामीटर है जो बड़ी तालिकाओं के लिए महत्वपूर्ण है (और यह उन्हें संभव मुद्दों के साथ जुड़े हुए हैं)। 20% का मूल्य बहुत अधिक लगता है, और सबसे अधिक संभावना है कि इसे बहुत कम करने की आवश्यकता होगी।

मापदंडों के इष्टतम मान अलग-अलग तालिकाओं के लिए भिन्न हो सकते हैं और तालिका आकार और परिवर्तनों की बारीकियों पर निर्भर करते हैं। यह आम तौर पर उपयुक्त मूल्यों को सेट करने के लिए समझ में आता है और, यदि आवश्यकता होती है, तो भंडारण मापदंडों के माध्यम से कुछ तालिकाओं के स्तर पर मापदंडों की विशेष ट्विकिंग करें:

• autovacuum_vacuum_threshold और toast.autovacuum_vacuum_threshold ।
• autovacuum_vacuum_scale_factor और toast.autovacuum_vacuum_scale_factor ।

भ्रमित होने से बचने के लिए, यह केवल कुछ तालिकाओं के लिए करना उचित है जो कि शेष राशि और परिवर्तनों की तीव्रता के बीच प्रतिष्ठित हैं और केवल जब विश्व स्तर पर निर्धारित मान ठीक काम करने में विफल होते हैं।

इसके अलावा, आप टेबल स्तर पर ऑटोवैक्यूम को बंद कर सकते हैं (हालांकि हम शायद ही एक कारण के बारे में सोच सकते हैं कि यह आवश्यक क्यों हो सकता है):

• autovacuum_enabled और toast.autovacuum_enabled ।

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

 => ALTER TABLE vac SET (autovacuum_enabled = off); 

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

 => CREATE FUNCTION get_value(param text, reloptions text[], relkind "char") RETURNS float AS $$ SELECT coalesce( -- if the storage parameter is set, we take its value (SELECT option_value FROM pg_options_to_table(reloptions) WHERE option_name = CASE -- for TOAST tables, the parameter name differs WHEN relkind = 't' THEN 'toast.' ELSE '' END || param ), -- otherwise, we take the value of the configuration parameter current_setting(param) )::float; $$ LANGUAGE sql; 

और यह दृश्य है:

 => CREATE VIEW need_vacuum AS SELECT st.schemaname || '.' || st.relname tablename, st.n_dead_tup dead_tup, get_value('autovacuum_vacuum_threshold', c.reloptions, c.relkind) + get_value('autovacuum_vacuum_scale_factor', c.reloptions, c.relkind) * c.reltuples max_dead_tup, st.last_autovacuum FROM pg_stat_all_tables st, pg_class c WHERE c.oid = st.relid AND c.relkind IN ('r','m','t'); 

विश्लेषण के लिए किन तालिकाओं की आवश्यकता है?

स्वचालित विश्लेषण के साथ स्थिति समान है। उन तालिकाओं को विश्लेषण की आवश्यकता माना जाता है जिनके अद्यतन (अंतिम विश्लेषण के बाद से) ट्यूपल्स दो समान मापदंडों द्वारा निर्दिष्ट सीमा से अधिक हैं: pg_stat_all_tables.n_mod_since_analyze > = autotacuum_analyze_threshold + autovacuum_analyze_scale_factor / fg / pg_class.reltupes

स्वचालित विश्लेषण की डिफ़ॉल्ट सेटिंग्स कुछ अलग होती हैं: ऑटोवैक्यूम_अनलीज़_थ्रेशोल्ड = 50 और ऑटोवैक्यूम_आनालीज़_सेले_फैक्टर = 0.1। उन्हें अलग-अलग तालिकाओं के भंडारण मापदंडों के स्तर पर भी परिभाषित किया जा सकता है:

• autovacuum_analyze_threshold
• autovacuum_analyze_scale_factor

चूंकि टोस्ट तालिकाओं का विश्लेषण नहीं किया गया है, इसलिए उनके पास ऐसे पैरामीटर नहीं हैं।

आइए विश्लेषण के लिए एक दृश्य भी बनाएं:

 => CREATE VIEW need_analyze AS SELECT st.schemaname || '.' || st.relname tablename, st.n_mod_since_analyze mod_tup, get_value('autovacuum_analyze_threshold', c.reloptions, c.relkind) + get_value('autovacuum_analyze_scale_factor', c.reloptions, c.relkind) * c.reltuples max_mod_tup, st.last_autoanalyze FROM pg_stat_all_tables st, pg_class c WHERE c.oid = st.relid AND c.relkind IN ('r','m'); 

उदाहरण

प्रयोगों के लिए निम्न मान मान सेट करें:

 => ALTER SYSTEM SET autovacuum_naptime = '1s'; -- to aviod waiting long => ALTER SYSTEM SET autovacuum_vacuum_scale_factor = 0.03; -- 3% => ALTER SYSTEM SET autovacuum_vacuum_threshold = 0; => ALTER SYSTEM SET autovacuum_analyze_scale_factor = 0.02; -- 2% => ALTER SYSTEM SET autovacuum_analyze_threshold = 0; 

 => SELECT pg_reload_conf(); 

  pg_reload_conf ---------------- t (1 row) 

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

 => CREATE TABLE autovac( id serial, s char(100) ) WITH (autovacuum_enabled = off); => INSERT INTO autovac SELECT g.id,'A' FROM generate_series(1,1000) g(id); 

वैक्यूमिंग के लिए हमारा नज़रिया यही है:

 => SELECT * FROM need_vacuum WHERE tablename = 'public.autovac'; 

  tablename | dead_tup | max_dead_tup | last_autovacuum ----------------+----------+--------------+----------------- public.autovac | 0 | 0 | (1 row) 

यहाँ ध्यान दो बातों पर दिया जाना चाहिए। सबसे पहले, max_dead_tup = 0 हालांकि 1000 पंक्तियों के 3% 30 पंक्तियों को बनाते हैं। बात यह है कि हमारे पास अभी तक मेज पर आँकड़े नहीं हैं क्योंकि INSERT इसे अपने आप अपडेट नहीं करता है। जब तक तालिका का विश्लेषण नहीं हो जाता, तब तक शून्य pg_class.reltuples = 0. से pg_class.reltuples रहेगा, लेकिन विश्लेषण के लिए दूसरा दृश्य देखें:

 => SELECT * FROM need_analyze WHERE tablename = 'public.autovac'; 

  tablename | mod_tup | max_mod_tup | last_autoanalyze ----------------+---------+-------------+------------------ public.autovac | 1000 | 0 | (1 row) 

चूंकि तालिका में 1000 पंक्तियों को बदल दिया गया है (जोड़ा गया है), जो शून्य से अधिक है, स्वचालित विश्लेषण को ट्रिगर किया जाना चाहिए। आइए इसकी जाँच करें:

 => ALTER TABLE autovac SET (autovacuum_enabled = on); 

एक छोटे से ठहराव के बाद हम देख सकते हैं कि तालिका का विश्लेषण किया गया है और सही 20 पंक्तियों को शून्य के बजाय max_dead_tup में दिखाया गया है:

 => SELECT * FROM need_analyze WHERE tablename = 'public.autovac'; 

  tablename | mod_tup | max_mod_tup | last_autoanalyze ----------------+---------+-------------+------------------------------- public.autovac | 0 | 20 | 2019-05-21 11:59:48.465987+03 (1 row) 

 => SELECT reltuples, relpages FROM pg_class WHERE relname = 'autovac'; 

  reltuples | relpages -----------+---------- 1000 | 17 (1 row) 

आइए ऑटोबैक्युमिंग पर वापस जाएं:

 => SELECT * FROM need_vacuum WHERE tablename = 'public.autovac'; 

  tablename | dead_tup | max_dead_tup | last_autovacuum ----------------+----------+--------------+----------------- public.autovac | 0 | 30 | (1 row) 

जैसा कि हम देख सकते हैं, max_dead_tup पहले ही तय हो चुका है। ध्यान देने वाली एक और बात यह है कि dead_tup = 0. आंकड़े बताते हैं कि टेबल में डेड ट्यूपल नहीं हैं ... और यह सच है। अभी तक तालिका में निर्वात के लिए कुछ भी नहीं है। एपेंड-ओनली मोड में विशेष रूप से उपयोग की गई किसी भी तालिका को वैक्यूम नहीं किया जाएगा और इसलिए, दृश्यता मानचित्र को इसके लिए अपडेट नहीं किया जाएगा। लेकिन यह सूचकांक-केवल स्कैन के उपयोग को असंभव बनाता है।

(अगली बार हम देखेंगे कि वैक्यूमिंग जल्दी या बाद में एक परिशिष्ट-केवल तालिका तक पहुंच जाएगा, लेकिन ऐसा बहुत कम ही होगा।)

एक सबक सीखा गया: यदि इंडेक्स-केवल स्कैन महत्वपूर्ण है, तो मैन्युअल रूप से वैक्यूम प्रक्रिया को कॉल करना आवश्यक हो सकता है।

अब चलो फिर से ऑटोवैक्मूम को बंद करें और 31 लाइनों को अपडेट करें, जो कि एक सीमा से अधिक है।

 => ALTER TABLE autovac SET (autovacuum_enabled = off); => UPDATE autovac SET s = 'B' WHERE id <= 31; => SELECT * FROM need_vacuum WHERE tablename = 'public.autovac'; 

  tablename | dead_tup | max_dead_tup | last_autovacuum ----------------+----------+--------------+----------------- public.autovac | 31 | 30 | (1 row) 

अब वैक्यूम ट्रिगर की स्थिति पूरी हो गई है। चलिए ऑटोवैसमैन चालू करते हैं और एक छोटे विराम के बाद हम देखेंगे कि तालिका संसाधित हो गई है:

 => ALTER TABLE autovac SET (autovacuum_enabled = on); => SELECT * FROM need_vacuum WHERE tablename = 'public.autovac'; 

  tablename | dead_tup | max_dead_tup | last_autovacuum ----------------+----------+--------------+------------------------------- public.autovac | 0 | 30 | 2019-05-21 11:59:52.554571+03 (1 row) 

लोड थ्रॉटलिंग

VACUUM अन्य प्रक्रियाओं को ब्लॉक नहीं करता है क्योंकि यह पेज द्वारा पेज का काम करता है, लेकिन यह सिस्टम पर अतिरिक्त भार उत्पन्न करता है और प्रदर्शन को काफी प्रभावित कर सकता है।

वैक्यूम के लिए कुचलना

वैक्यूम तीव्रता को नियंत्रित करने में सक्षम होने के लिए और इसलिए, सिस्टम पर इसका प्रभाव, प्रक्रिया काम और प्रतीक्षा को वैकल्पिक करती है। प्रक्रिया वैक्यूम_कोस्ट_लिमिट कार्य की पारंपरिक इकाइयों के बारे में करेगी और फिर यह वैक्यूम_कोस्ट_डेल्ले एमएस के लिए सो जाएगी।

डिफ़ॉल्ट सेटिंग्स वैक्यूम_कोस्ट_लिमिट = 200 हैं और वैक्यूम_कोस्ट_डेल = 0. अंतिम शून्य का वास्तव में मतलब है कि VACUUM नहीं सोता है, इसलिए वैक्यूम_कोस्ट_लिमिट का एक विशिष्ट मूल्य बिल्कुल भी मायने नहीं रखता है। इसके पीछे तर्क यह है कि अगर किसी प्रशासक को मैन्युअल रूप से VACUUM लॉन्च करना है, तो वह जितनी जल्दी हो सके वैक्यूमिंग करने की इच्छा रखता है।

फिर भी, अगर हम सोने का समय निर्धारित करते हैं, तो वैक्यूम_कोस्ट_लिमिट में निर्दिष्ट कार्य बफर बफर में पृष्ठों के साथ काम की लागत से बना होगा। प्रत्येक पृष्ठ का उपयोग निम्नानुसार अनुमानित है:

• यदि पृष्ठ बफर कैश में पाया जाता है, तो वैक्यूम_कोस्ट_पेज_हाइट = 1।
• यदि यह नहीं मिला, तो वैक्यूम_कोस्ट_पेज_मिस = 10।
• यदि यह नहीं मिला और एक गंदे पृष्ठ को अतिरिक्त रूप से बफर कैश, वैक्यूम_कोस्ट_पेज_डर्टी = 20 से निकालना पड़ा ।

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

ऑटोवैस्क्यूमिंग के लिए थ्रॉटलिंग

वैक्यूम प्रक्रियाओं के लिए, लोड थ्रोटलिंग वैकुम के लिए उसी तरह काम करती है। लेकिन ऑटोवैक्यूम प्रक्रियाओं के लिए और अलग-अलग तीव्रता के साथ काम करने के लिए मैन्युअल रूप से VACUUM लॉन्च किया गया है, ऑटोवैक्यूम के अपने पैरामीटर हैं: ऑटोवैक्यूम_वैकुम_कोस्ट_लिमिट और ऑटोवैक्यूम_वेकुमन_कोस्ट_सेल । यदि इन मापदंडों में -1 का मान है, तो वैक्यूम_कोस्ट_लिमिट और / या वैक्यूम_कोस्ट_डेल के मूल्य का उपयोग किया जाता है।

डिफ़ॉल्ट रूप से autovacuum_vacuum_cost_limit = -1 ( अर्थात , वैक्यूम_cost_limit = 200 का मान उपयोग किया जाता है) और autovacuum_vacuum_cost_delay - 20 ms। आधुनिक हार्डवेयर पर, ऑटोवैक्यूम वास्तव में धीमा होगा।

संस्करण 12 में, ऑटोवैक्यूम_वैकुम_कोस्ट_डेल का मूल्य 2 एमएस तक कम हो जाता है, जिसे अधिक उपयुक्त पहले सन्निकटन के लिए लिया जा सकता है।

इसके अलावा, हमें ध्यान देना चाहिए कि इन सेटिंग्स द्वारा निर्दिष्ट सीमा सभी कार्यकर्ता प्रक्रियाओं के लिए सामान्य है। दूसरे शब्दों में, जब एक साथ श्रमिक प्रक्रियाओं की संख्या बदल जाती है, तो समग्र भार अपरिवर्तित रहता है। इसलिए, ऑटोवैक्यूम के प्रदर्शन को बढ़ाने के लिए, जब कार्यकर्ता प्रक्रियाओं को जोड़ते हैं, तो यह भी मतलब है कि ऑटोवैक्यूम_वैकुम_कोस्ट_लिमिट को बढ़ाएं ।

स्मृति और निगरानी का उपयोग

पिछली बार हमने देखा था कि कैसे VACUUM ने tid s को वैक्यूम करने के लिए साइज़ मेन्टेनेंस_वर्क_म की रैम का इस्तेमाल किया।

ऑटोवैक्यूम बिल्कुल वैसा ही करता है। लेकिन कई युगपत कार्यकर्ता प्रक्रियाएं हो सकती हैं यदि ऑटोवैकुम_मैक्स_वर्कर्स एक बड़े मूल्य पर सेट है। इसके अलावा, जरूरत पड़ने पर सभी मेमोरी एक बार में आवंटित की जाती हैं। इसलिए, एक कार्यकर्ता प्रक्रिया के लिए, अपनी सीमा को ऑटोकैसम_वर्क_मम पैरामीटर के माध्यम से निर्धारित किया जा सकता है। इस पैरामीटर का डिफ़ॉल्ट मान -1 है, अर्थात, इसका उपयोग नहीं किया गया है।

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

हमने देखा है कि VACUUM की निगरानी करने के लिए, VERBOSE विकल्प का उपयोग किया जा सकता है (जो ऑटोवैक्यूम के लिए निर्दिष्ट नहीं किया जा सकता है) या pg_stat_progress_vacuum दृश्य (जो, हालांकि, केवल वर्तमान जानकारी दिखाता है)। इसलिए, ऑटोवैक्यूमिंग की निगरानी करने का मुख्य साधन log_autovacuum_min_duration पैरामीटर का उपयोग करना है, जो सर्वर संदेश लॉग में जानकारी को आउटपुट करता है। इसे डिफ़ॉल्ट रूप से बंद कर दिया जाता है (-1 पर सेट)। इस पैरामीटर को चालू करना उचित है (0 के मान के साथ, सभी ऑटोवैक्यूम रन पर जानकारी आउटपुट होगी) और आंकड़े देखें।

यह आउटपुट जानकारी जैसा दिखता है:

 => ALTER SYSTEM SET log_autovacuum_min_duration = 0; => SELECT pg_reload_conf(); 

  pg_reload_conf ---------------- t (1 row) 

 => UPDATE autovac SET s = 'C' WHERE id <= 31; 

 student$ tail -n 7 /var/log/postgresql/postgresql-11-main.log 

 2019-05-21 11:59:55.675 MSK [9737] LOG: automatic vacuum of table "test.public.autovac": index scans: 0 pages: 0 removed, 18 remain, 0 skipped due to pins, 0 skipped frozen tuples: 31 removed, 1000 remain, 0 are dead but not yet removable, oldest xmin: 4040 buffer usage: 78 hits, 0 misses, 0 dirtied avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s 2019-05-21 11:59:55.676 MSK [9737] LOG: automatic analyze of table "test.public.autovac" system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s 

सभी आवश्यक जानकारी यहाँ उपलब्ध है।

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

वैक्यूमिंग की आवश्यकता वाली तालिकाओं की सूची की लंबाई की निगरानी करने के लिए उपरोक्त विचारों का उपयोग करना भी उचित हो सकता है। सूची की लंबाई बढ़ाने से संकेत मिलता है कि ऑटोवैक्यूम प्रक्रियाओं को अपना काम करने के लिए समय की कमी है और सेटिंग्स को बदलने की आवश्यकता है।

जारी रखा जाए।