क्या नियमित VACUUM ANALYZE अभी भी 9.1 के तहत अनुशंसित हैं?

Question

मैं Ubuntu पर PostgreSQL 9.1 का उपयोग कर रहा हूं। क्या VACUUM ANALYZEअभी भी सिफारिश की गई है, या सभी जरूरतों का ध्यान रखने के लिए ऑटोवैक्यूम पर्याप्त है?

यदि उत्तर "यह निर्भर करता है", तो:

• मेरे पास एक लार्जिश डेटाबेस है (30 GiB संपीड़ित डंप आकार, 200 GiB डेटा निर्देशिका)
• मैं डेटाबेस में ETL करता हूं, जो प्रति सप्ताह लगभग 3 मिलियन पंक्तियों का आयात करता है
• सबसे लगातार परिवर्तन वाली तालिकाएं सभी को एक मास्टर टेबल से विरासत में मिली हैं, जिसमें मास्टर टेबल में कोई डेटा नहीं है (डेटा सप्ताह द्वारा विभाजित किया गया है)
• मैं प्रति घंटा रोलअप बनाता हूं, और वहां से, दैनिक, साप्ताहिक और मासिक रिपोर्ट करता हूं

मैं पूछ रहा हूं क्योंकि अनुसूचित VACUUM ANALYZEमेरी रिपोर्टिंग को प्रभावित कर रहा है। यह 5 घंटे से अधिक समय तक चलता है, और मुझे इसे इस सप्ताह में दो बार मारना पड़ा है, क्योंकि यह नियमित डेटाबेस आयातों को प्रभावित कर रहा था। check_postgresडेटाबेस पर किसी भी महत्वपूर्ण ब्लोट की रिपोर्ट नहीं करता है, इसलिए यह वास्तव में कोई समस्या नहीं है।

डॉक्स से, ऑटोवैक्यूम को लेन-देन आईडी रैप का ध्यान रखना चाहिए। सवाल खड़ा है: क्या मुझे अभी भी एक की जरूरत है VACUUM ANALYZE?

Comments

खैर, मैं 'नहीं' कहूंगा, लेकिन इस जवाब को विस्तृत करना (उदाहरण के लिए ऑटोवैक्यूम मापदंडों को सेट करना) एक प्रतिकृति डीबी पर कुछ प्रयोगों की आवश्यकता होगी।

— dezso

Answer 1

गैर-अस्थायी तालिकाओं में केवल अद्यतित या हटाई गई पंक्तियों पर VACUUM की आवश्यकता होती है। जाहिर है कि आप बहुत सारे INSERT कर रहे हैं, लेकिन इस विवरण से यह स्पष्ट नहीं है कि आप बहुत सारे UPDATE या DELETEs भी कर रहे हैं।

ये ऑपरेशन pg_stat_all_tablesदृश्य, विशेष रूप से कॉलम n_tup_updऔर n_tup_delकॉलम से देखे जा सकते हैं। इसके अलावा, इस बिंदु पर और भी, एक n_dead_tupस्तंभ है जो बताता है, प्रति तालिका, कितनी पंक्तियों को वैक्यूम करने की आवश्यकता है। ( आंकड़ों के एकत्रीकरण से संबंधित कार्यों और विचारों के लिए डॉक्टर में निगरानी आँकड़े देखें )।

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

लेकिन हमेशा नए आँकड़े रखने के लिए अनुकूलक के लिए ANALYZE चलाते रहें।

Comments

ऑटोवैक्यूम भी ANALYZE का ख्याल रखता है। बल्क UPDATE / INSERT / DELETE के बीच मैन्युअल ANALYZE चलाना और बड़े प्रश्नों का तुरंत अनुसरण करना अभी भी एक अच्छा विचार है। हालांकि अच्छी सलाह के लिए +1।

— एरविन ब्रैंडस्टैटर

N_dead_tup और दोस्तों के लिए सूचक के लिए धन्यवाद। मेरे पास रोलअप टेबल हैं, जिन पर मैं अक्सर (प्रति घंटा) नष्ट करता हूं और हजारों पंक्तियों को फिर से बनाता हूं। मैं मूल्यों की जाँच करूँगा और उचित रूप से अनुसूची करूँगा। इसका उत्तर हमेशा "मॉनिटर, थिंक, एक्ट" होता है, वैसे भी :)

— फ्रांस्वा ब्यूसोइल

Answer 2

मुझे आपके सवाल में ऐसा कुछ नहीं दिख रहा है, जिसका autovacuumध्यान न रखा जाए। यह काफी हद तक आपकी लेखन गतिविधियों के पैटर्न पर निर्भर करता है । आप प्रति सप्ताह 3 मिलियन नई पंक्तियों का उल्लेख करते हैं , लेकिन INSERT(या COPY) आमतौर पर टेबल और इंडेक्स ब्लोट नहीं बनाते हैं। ( autovacuumकेवल कॉलम के आंकड़ों , दृश्यता मानचित्र और कुछ मामूली नौकरियों का ध्यान रखना होगा )। UPDATEऔर DELETEविशेष रूप से यादृच्छिक पंक्तियों को लक्षित करते समय टेबल और इंडेक्स ब्लोट का प्रमुख कारण है। मुझे आपके प्रश्न में से कोई भी दिखाई नहीं दे रहा है।

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

यदि आपके पास बहुत सारे रैंडम हैं UPDATE, तो आप FILLFACTORहॉट अपडेट्स को तुरंत 100 से कम पर सेट करना चाहते हैं , ताकि HOT अपडेट तुरंत मिल सकें और ज़रूरत को कम किया जा सके VACUUM। HOT अपडेट्स पर अधिक:

• अपडेट स्टेटमेंट में अनावश्यक डेटा

यह भी ध्यान दें, कि अस्थायी तालिकाओं को मैनुअल VACUUMऔर की जरूरत है ANALYZE। मैं मैनुअल कोCREATE TABLE उद्धृत करता हूं :

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

Answer 3

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

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

इसका समाधान उन तालिकाओं में जाना है जो बहुत अधिक उपयोग किए जाते हैं और बड़े प्रश्नों के अधीन होते हैं और उन तालिकाओं के लिए ऑटो विश्लेषण सेटिंग्स सेट करते हैं जहां वे एक या हर दूसरे दिन विश्लेषण कर रहे हैं।

आप ऑटो वैक्यूम टैब पर gui में प्रति तालिका सेटिंग्स पर जा सकते हैं और आप वहां सेटिंग्स का विश्लेषण देखेंगे जिसे आप वैक्यूम से स्वतंत्र रूप से सेट कर सकते हैं।

सेटिंग्स रिलैप्स टेबल में समाप्त हो जाती हैं और क्वेरी के साथ देखी जा सकती हैं

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

और एग्रेसिव एनालिसिस का एक नमूना मूल्य हो सकता है

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

यह देखने के लिए कि पिछली बार आपकी तालिकाओं का स्वतः विश्लेषण क्वेरी कब हुई थी

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;

Comments

यदि आप नहीं करते हैं ANALYZE, तो PostgreSQL को कैसे पता चलेगा कि आँकड़े बदल गए हैं? और आप यह कैसे निर्धारित कर सकते हैं कि यह ANALYZEएक लंबा समय है? उसी समय, जबकि यह बिल्कुल स्पष्ट नहीं है कि आप जिस जीयूआई का उल्लेख करते हैं, आप सही हैं कि विशिष्ट प्रति-तालिका सेटिंग्स उपयोगी हो सकती हैं।

— dezso