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

तब हमने इन-पेज क्लीनिंग (और HOT अपडेट), नियमित सफाई पर ध्यान दिया , लेकिन आज हम स्वचालित सफाई को देखते हैं।

ऑटो सफाई (ऑटोवैक्यूम)

हम पहले ही कह चुके हैं कि सामान्य परिस्थितियों में सामान्य सफाई (जब कोई भी लंबे समय तक लेन-देन क्षितिज नहीं रखता है) को अपने काम का सामना करना होगा। सवाल यह है कि इसे कितनी बार बुलाना है।

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

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

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

स्वचालित सफाई केवल बहुत ही तंत्र है जो आपको तालिकाओं में परिवर्तन की गतिविधि के आधार पर, सफाई शुरू करने की अनुमति देता है।

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

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

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

प्रारंभ करने के बाद, वर्कफ़्लो उसके द्वारा निर्दिष्ट डेटाबेस से जुड़ता है और सूची के निर्माण से शुरू होता है:

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

इसके अलावा, वर्कफ़्लो बदले में चयनित वस्तुओं को साफ और / या विश्लेषण करता है और जब सफाई पूरी हो जाती है।

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

लंबे समय से समानांतर प्रसंस्करण की आवश्यकता पर चर्चा हुई है, लेकिन पैच अभी तक नहीं अपनाया गया है।

अब "क्या सफाई की आवश्यकता है" और "विश्लेषण की आवश्यकता है" पर करीब से नज़र डालते हैं।

किस टेबल को सफाई की जरूरत है

यह माना जाता है कि अगर "मृत", अर्थात् अप्रासंगिक, संख्याओं के संस्करण एक निर्धारित सीमा से अधिक हो तो सफाई आवश्यक है। मृत कलेक्टरों की संख्या लगातार आंकड़े संग्राहक द्वारा एकत्र की जाती है और pg_stat_all_tables तालिका में संग्रहीत की जाती है। और सीमा दो मापदंडों द्वारा निर्धारित की जाती है:

• autovacuum_vacuum_threshold निरपेक्ष मान (टुकड़ों में) को परिभाषित करता है,
• autovacuum_vacuum_scale_factor एक तालिका में पंक्तियों के अनुपात को निर्धारित करता है।

अंतिम सूत्र है: अगर pg_stat_all_tables.n_dead_tup> = autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factale * pg_class.reltupes पर सफाई आवश्यक है।

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

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

• ऑटोवैक्यूम_वैक्युम_थ्रेशोल्ड और टोस्ट.ओटोवैक्युलम_वास्कूम_थ्रॉल्ड ,
• 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( --    ,    (SELECT option_value FROM pg_options_to_table(reloptions) WHERE option_name = CASE --  toast-    WHEN relkind = 't' THEN 'toast.' ELSE '' END || param ), --      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> = autovacuum_analyze_threshold + autovacuum_analyze_scalyze_scalyze_scalyz।

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

• ऑटोवैकुम_यानालीज़_थ्रेशोल्ड ,
• 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'; --     => 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. हालांकि, आइए विश्लेषण के लिए दूसरे दृष्टिकोण पर एक नज़र डालें:

 => 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 लाइनें देखते हैं:

 => 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) 

लोड विनियमन

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

नियमित सफाई के लिए नियमन

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

डिफ़ॉल्ट सेटिंग वैक्यूम_कोस्ट_लिमिट = 200 सेट करती हैं , वैक्यूम_कोस्ट_डेल = = अंतिम शून्य का वास्तव में अर्थ है कि (सामान्य) सफाई सो नहीं जाती है, इसलिए वैक्यूम_कोस्ट_लिमिट का विशिष्ट मूल्य कोई भूमिका नहीं निभाता है। यह इस कारण से किया जाता है कि यदि प्रशासक को मैन्युअल रूप से VACUUM शुरू करना था, तो वह संभवत: जल्द से जल्द सफाई करना चाहता है।

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

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

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

ऑटो की सफाई के लिए नियमन

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

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

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

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

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

पिछली बार, हमने देखा कि कैसे सफाई के लिए पंक्तियों के संस्करण पहचानकर्ताओं को संग्रहीत करने के लिए आकार मेंटेनेंस_वर्क_म की रैम मेमोरी का उपयोग किया जाता है।

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

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

हमने देखा कि सफाई की निगरानी के लिए, आप 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 

सभी आवश्यक जानकारी यहाँ मौजूद है।

याद रखें कि अक्सर आपको स्मृति के आकार में वृद्धि नहीं करनी चाहिए, लेकिन सफाई के लिए सीमा को कम करना चाहिए ताकि एक समय में कम डेटा संसाधित हो।

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

जारी रखा जाए ।