2017-01-18 12 views
9

मैं एक बहुत बड़ी मेज पर वैक्यूम चला रहा हूं।"पूर्ण" होने के बाद वैक्यूम पूरी प्रतीक्षा क्यों करता है?

जब मैंने इसे चलाने के लिए, यह कहते हैं:

bacula=# VACUUM FULL VERBOSE file_partition_19 
bacula-# ; 
INFO: vacuuming "public.file_partition_19" 
INFO: "file_partition_19": found 16242451 removable, 21024161 nonremovable row versions in 900380 pages 
DETAIL: 0 dead row versions cannot be removed yet. 
CPU 5.14s/14.42u sec elapsed 19.61 sec. 
VACUUM 
Time: 163784.767 ms 
bacula=# 

जब यह ऐसा करता है, तो यह काफी जल्दी CPU लाइन के लिए आता है, तो एक लंबे समय से पहले यह अंतिम दो पंक्तियों से पता चलता (+ शीघ्र इंतजार कर रहा है)। यह 163 सेकेंड के "समय:" की तुलना में समय में अंतर में दिखाई देता है - "1 9 .6 सेकेंड से अधिक" (दिखाया गया है क्योंकि मैंने \timing on सेट किया है)।

जबकि मैंने उन्हें समय नहीं दिया है, दोनों बार सही हैं - कमांड शुरू करें, 20 सेकंड प्रतीक्षा करें, फिर यह "सीपीयू" रेखा तक दिखाई देता है, फिर लगभग 3 मिनट तक प्रतीक्षा करता है, फिर बाकी प्रिंट करता है।

क्या यह सामान्य है? ऐसा क्यों हो रहा है?

उत्तर

3

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

AFAICT, सीपीयू उपयोग लाइन एक सामान्य दिनचर्या द्वारा मुद्रित की जाती है जो अन्य (गैर-पूर्ण) वैक्यूम मोड के लिए अधिकांश काम करता है। यह "वैक्यूम पूर्ण" मामले में व्यर्थ है।

यदि आप चिंतित हैं कि इसमें बहुत अधिक समय लगता है, तो मैं अनुशंसा करता हूं कि आपको PostgreSQL विकी से "When to use VACUUM FULL and when not to" पर नज़र डालें। 10 में से 9 बार जब लोग वैक्यूम पूर्ण का उपयोग कर रहे हैं तो उन्हें वास्तव में नहीं करना चाहिए।

2

"पोस्टग्रेस-9.3" टैग के आधार पर आपने अपने प्रश्न के लिए उपयोग किया है, मुझे लगता है कि आपके पास पोस्टग्रेस 9.3 संस्करण है।

आप पोस्टग्रेस के पूर्व-9.0 संस्करणों के लिए "VACUUM" और "VACUUM FULL" के बारे में अपने स्वयं के ज्ञान के लिए इस लिंक को संदर्भित कर सकते हैं।

VACUUM VS VACUUM FULL For Pre-9.0 versions of Postgres

तो आप के रूप में Postgres-9.3, प्रलेखन निम्नलिखित कहते हैं:

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

वर्तमान प्रलेखन के अनुसार, वैक्यूम पूर्ण संचालन न केवल तालिका जहां रिकॉर्ड नष्ट चिह्नित कर रहे हैं से अंतरिक्ष को पुन: प्राप्त लेकिन यह भी तालिका में हर वैध रिकॉर्ड को छूता है और इतना है कि यह कैसे है उन्हें डीबी पन्नों में पुनर्निर्माण की कोशिश करता है बस वैक्यूम ऑपरेशन के बाद और अधिक जगह मुक्त करता है। Verbos परिणाम में तो जब हम लाइन

CPU 5.14s/14.42u sec elapsed 19.61 sec 

देखें कि यह समय सिस्टम प्रक्रिया द्वारा उठाए गए तालिका के माध्यम से जाने के लिए और तालिका का विश्लेषण करने और अंतरिक्ष कि पहले से ही चिह्नित है पुनः प्राप्त करने के लिए है। फिर यह पृष्ठ फ़ाइल में रिकॉर्ड व्यवस्थित करना शुरू करता है और इसलिए इस पर निर्भर करता है कि तालिका पृष्ठों को कितना खंडित किया गया है, प्रक्रिया में समय लगेगा।

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

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

जांच निम्न नमूना उत्पादन,

VACUMM FULL Output

मैं बहुत छोटी डमी तालिका के लिए भाग गया। भले ही इसमें केवल 7 पंक्तियां हों। Vacume प्रक्रिया (प्रथम चरण) 0.03sec (30ms) में खत्म लेकिन कुल क्वेरी 61ms में समाप्त करने के लिए सूचना दी। ताकि मुझसे कहता है, भले ही प्रक्रिया पुनर्निर्माण करने के लिए कुछ भी नहीं है अभी भी जाँच करता है अगर यह पुनर्गठित किया जा सकता है कि कितना और इसलिए समय लगता है। लेकिन अगर मेरे पास वास्तव में बहुत विखंडन है और पुनर्गठन होता है तो पृष्ठ विखंडन के आधार पर यह अधिक पूरा समय होगा।

संबंधित मुद्दे