मैं उपयोग सॉफ्टवेयर है जो एक बड़ा PostgreSQL डेटाबेस (उसमें एक लाख पंक्तियों के साथ एक मेज है) और डेवलपर्स बनाता है कहता है कि मैं चाहिए VACUUMऔर ANALYZEसमय-समय पर। लेकिन PostgreSQL डेटाबेस डिफ़ॉल्ट autovacuumचालू है।
क्या मुझे वैक्यूम / विश्लेषण करना चाहिए? क्या लाभ हैं? स्वचालित और मैन्युअल वैक्यूम में क्या अंतर है
उदाहरण के लिए, Pgadmin3 में, मेरे पास यह है:
जवाबों:
मैं ईटीएल से सहमत हूं कि कोई छोटा जवाब नहीं है। आकार केवल एक चीज नहीं है जो मायने रखता है - हम भारी लोड के तहत काफी बड़े पोस्टग्रेक्लेस ओएलटीपी डेटाबेस (कुछ तालिकाओं के साथ 100.000.000 पंक्तियों) चलाते हैं और वर्तमान में हम केवल ऑटोवैक्यूम पर भरोसा करते हैं।
फिर भी, दो बातें मेरे लिए महत्वपूर्ण हैं:
ऐसा प्रतीत होता है कि आम सहमति है, कि ऑटोवैक्यूम को कभी भी बंद नहीं किया जाना चाहिए , जब तक कि आपके डेटाबेस पर बहुत अच्छी तरह से परिभाषित कार्यभार न हो और आपको ठीक-ठीक पता हो कि आप क्या कर रहे हैं। लेकिन, स्वाभाविक रूप से, आप अतिरिक्त VACUUMऔर / या ANALYZEरन कर सकते हैं ।
अतिरिक्त VACUUMरन पर विचार करने से पहले , मैं जांच करूंगा कि ऑटोकैसम कैसे बना रहता है। आप जाँच कर सकते हैं कि क्या क्वेरी के द्वारा कोई भी तालिका ऑटोवेक्यूम की सीमा से परे है pg_stat_user_tablesऔर pg_class। मैंने एक और धागे पर ऐसी क्वेरी पोस्ट की है, जो ब्याज की हो सकती है: PostgreSQL पर आक्रामक ऑटोवैक्यूम ।
दुर्भाग्य से, यह आसान नहीं है (फिलहाल संभव नहीं है) ऑटोलिलेज थ्रेसहोल्ड के लिए एक समान जांच करना। हालाँकि, ऑटोअनलीज़ डिफॉल्ट रूप से ऑटोवैक्यूम से पहले लंबे समय तक चलता है और यह बहुत सस्ता है। तो, मूल रूप से यदि आपका डेटाबेस ऑटोवैसम के साथ रख सकता है, तो यह संभवत: ऑटोइंजलिज़ के साथ भी ठीक होगा। अंतिम स्वप्रतिरक्षा की तारीखों को भी कहा जा सकता है pg_stat_user_tables।
(सबसे उत्कृष्ट) पोस्टग्रेक्यूएल प्रलेखन के कुछ भाग, जो मुझे मददगार लगे:
जब तक आप किसी चीज़ को गलत तरीके से कॉन्फ़िगर नहीं करते हैं तब तक ऑटोवैक्यूम को बहुत अच्छी तरह से कवर करना चाहिए। अन्य उत्तर पहले से ही कवर हैं।
मैनुअल VACUUM (और अधिक महत्वपूर्ण रूप से: मैनुअल ANALYZE) के लिए एक स्पष्ट रूप से परिभाषित मामला है, हालांकि: अस्थायी टेबल , वे ऑटोवैक्यूम दानव द्वारा नहीं माना जाता है। मैं मैनुअल CREATE TABLEयहाँ पर उद्धृत करता हूं :
Autovacuum डेमॉन का उपयोग नहीं कर सकते हैं और इसलिए निर्वात या अस्थायी तालिकाओं का विश्लेषण नहीं कर सकते। इस कारण से, सत्र SQL कमांड के माध्यम से उपयुक्त वैक्यूम और विश्लेषण कार्यों का प्रदर्शन किया जाना चाहिए। उदाहरण के लिए, यदि जटिल प्रश्नों में एक अस्थायी तालिका का उपयोग किया जा रहा है, तो
ANALYZEयह आबादी के बाद अस्थायी तालिका पर चलने के लिए बुद्धिमान है।
इसका कोई संक्षिप्त उत्तर नहीं है क्योंकि यह बहुत सारे कारक पर निर्भर करता है। क्या सिस्टम धीमा है? क्या ऑटो-वैक्यूम वास्तव में इस तालिका को छू रहा है? आदि।
यहाँ इस विषय पर कुछ अच्छे लिंक दिए गए हैं:
स्पष्ट निर्णय लेने के लिए डेटाबेस की स्वयं समझ और जो चल रहा है उस पर अधिक विवरण की आवश्यकता होती है।
मुझे नहीं लगता कि आपको मैन्युअल रूप से वैक्यूम करने की आवश्यकता है, जब तक कि आप प्रदर्शन में गिरावट नहीं देखना शुरू करते हैं। हालाँकि, मैं आपके वैक्यूम और ऑटोवैक्युम सेटिंग्स की समीक्षा करने और इसे अपनी आवश्यकताओं के अनुरूप करने की जोरदार सिफारिश करूंगा
अपनी वर्तमान सेटिंग देखने के लिए, यह क्वेरी चलाएँ:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'अधिकांश क्षेत्र आत्म-व्याख्यात्मक हैं, लेकिन यहाँ उन पर प्रलेखन है: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
मैं कहूंगा, कि आपका लक्ष्य लगातार कचरा साफ करने के लिए ऑटोवैक्यूम को कॉन्फ़िगर करना होना चाहिए, लेकिन ऑटोवैक्युम को लगातार न चलाएं
सबसे महत्वपूर्ण सेटिंग्स हैं:
थ्रेसहोल्ड सफाई की प्रक्रिया को रोकने के लिए मदद करता है जिस तरह से अक्सर छोटे तालिकाओं के लिए ट्रिगर किया जाता है।
डिफ़ॉल्ट सेटिंग्स ठीक काम करती हैं, जब तक कि आपके पास बहुत बड़ी टेबल न हों। सीधे शब्दों में कहें, अगर आपके पास टेबल है जो 100GB लेता है, तो आप 20GB कचरा जमा करने जा रहे हैं, इससे पहले कि ऑटोवैक्लम ट्रिगर हो जाएगा। इस प्रकार, मैं आमतौर पर स्केल फैक्टर को कम करने की सलाह देता हूं। आपको अपने लिए कितना कम निर्धारित करना चाहिए। मैं अपने वर्तमान प्रोजेक्ट पर 0.05 का उपयोग करता हूं
थ्रेसहोल्ड भी बढ़ाया जा सकता है। कई अनुप्रयोगों में कुछ जोड़े होते हैं, जिन्हें अक्सर अपडेट किया जाता है और 50 ट्यूपल इतने अधिक नहीं होते हैं। 1000 तक बढ़ने से किसी भी समस्या का सामना नहीं करना चाहिए, लेकिन निश्चित रूप से, आपको अपने मामले पर विचार करना चाहिए
आप ऑटोवैक्यूम को भी ठीक कर सकते हैं और अपनी कुछ तालिकाओं के लिए अलग-अलग सेटिंग्स रख सकते हैं
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);यदि आप scale_factor और थ्रेसहोल्ड कॉन्फ़िगर करते हैं, तो आपको ठीक होना चाहिए। आप यह भी बढ़ा सकते हैं autovacuum_vacuum_cost_limit, जो डिफ़ॉल्ट रूप से बराबर है vacuum_cost_limit, जो 200 पर सेट है। यह वैक्यूम की एक बहुत ही महत्वपूर्ण विशेषता है, जो इसे सभी संसाधनों को खाने की अनुमति नहीं देता है और आपके आवेदन को वैक्यूमिंग प्रक्रिया के दौरान भी डेटा के साथ संचालित करने की अनुमति देता है। , लेकिन डिफ़ॉल्ट मान बहुत कम है। इसे 1000 तक बढ़ाने से कोई महत्वपूर्ण विलंब नहीं होना चाहिए, लेकिन वैक्यूम प्रक्रिया को बहुत तेज़ी से समाप्त करने की अनुमति देगा
बेशक, आप मैन्युअल रूप से वैक्यूम भी चला सकते हैं। सबसे सरल मामले में, आपके पास एक साधारण क्रोन नौकरी हो सकती है, जो हर रात को पूरी तरह से साफ कर देगी, जब आपका डीबी सुरक्षित नहीं होगा।
उम्मीद है की वो मदद करदे!