एक वैक्यूम / ऑटोवैक्यूम ऑपरेशन में कितना समय लगेगा?

Question

मैं विभिन्न भूमिकाओं वाली तालिकाओं वाले एक बड़े (कुछ सैकड़ों गिग्स) डेटाबेस का प्रबंधन करता हूं, उनमें से कुछ लाखों रिकॉर्ड रखते हैं। कुछ तालिकाओं में केवल बड़ी संख्या में आवेषण और हटाए जाते हैं, कुछ अन्य आवेषण और बड़ी संख्या में अपडेट होते हैं।

डेटाबेस 16 जीबी गीगाबाइट रैम के साथ एक डेबियन 6.0 amd64 सिस्टम पर PostgreSQL 8.4 पर चलता है।

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

संपादित करें:

मैं बुलेट-प्रूफ समाधान की तलाश में नहीं हूं। मृत ट्यूल या आवश्यक I / O बाइट्स की संख्या पर बस एक मोटा संकेत तय करने के लिए पर्याप्त है। यह वास्तव में कष्टप्रद है कि कब, क्या VACUUMहोगा कोई सुराग नहीं है।

मैंने देखा है कि pg_catalog.pg_stat_all_tablesमृत टुपल्स की संख्या के लिए एक कॉलम है। इसलिए अनुमान लगाना संभव है, भले ही इसका मतलब है कि किसी को ANALYZEपहले टेबल पर रखना होगा । दूसरी ओर, autovacuum_vacuum_thresholdऔर autovacuum_vacuum_scale_factorसेटिंग्स अकेले साबित करती हैं कि पोस्टग्रेज खुद ही टेबल पर बदलाव की मात्रा के बारे में कुछ जानता है और शायद इसे डीबीए के हाथों में भी रखता है।

मुझे यकीन नहीं है कि किस क्वेरी को चलाना है, क्योंकि जब मैं दौड़ता VACUUM VERBOSEहूं, तो मैं देखता हूं कि न केवल टेबल, बल्कि उन पर अनुक्रमित भी संसाधित किए जा रहे हैं।

Answer 1

मेरे PostgreSQL (8.3) पर मैं इस ट्रिक का उपयोग करता हूं:

1. मुझे तालिका के डिस्क आकार का उपयोग करना है pg_total_relation_size()- इसमें अनुक्रमित और टोस्ट आकार शामिल है, जो कि VACUUMप्रक्रियाएं हैं। इससे मुझे यह पता चलता है कि कितने बाइट्स VACUUMको पढ़ना है।
2. मैं VACUUMटेबल पर दौड़ता हूं ।
3. मुझे लगता है pidकी VACUUM(में प्रक्रिया pg_catalog.pg_stat_activity)।
4. लिनक्स शेल में मैं चलाता हूं while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(जहां 123पीआईडी ​​है) - यह मुझे डिस्क से प्रक्रिया द्वारा पढ़ी गई बाइट दिखाता है।

इससे मुझे यह पता चलता है कि हर मिनट कितने बाइट संसाधित होते हैं (पढ़ें) VACUUM। मुझे लगता है कि VACUUMपूरे तालिका (अनुक्रमित और टोस्ट सहित) के माध्यम से पढ़ना चाहिए, जिसका डिस्क आकार मुझे चरण 1 से पता है।

मुझे लगता है कि तालिका इतनी बड़ी है कि इसमें से अधिकांश पृष्ठों को डिस्क से पढ़ा जाना चाहिए (वे पोस्टग्रैज साझा मेमोरी में मौजूद नहीं हैं), इसलिए read_bytesफ़ील्ड प्रगति काउंटर के रूप में उपयोग करने के लिए पर्याप्त है।

हर बार मैंने ऐसा किया, प्रक्रिया द्वारा पढ़े गए कुल बाइट्स कुल संबंध आकार से 5% से अधिक नहीं थे, इसलिए मुझे लगता है कि यह दृष्टिकोण आपके लिए काफी अच्छा हो सकता है।

Comments

गंदा :) बाद के संस्करणों के लिए भी यह काम करता है? और, अधिक महत्वपूर्ण बात, ऑटोवैक्यूम के लिए?

— dezso

मैंने इसे नए संस्करणों के लिए आज़माया नहीं है। यह VACUUM FULL9.0+ पर काम करना चाहिए , क्योंकि यह पूरी तरह से तालिका को फिर से लिखता है। यह नियमित रूप VACUUMसे भी काम करना चाहिए , लेकिन मैंने अभी तक इसका परीक्षण नहीं किया है। इसके लिए autovacuumयह काम करेगा यदि आप दिए गए टेबल पर ऑटोवैक्यूम कार्यकर्ता प्रक्रिया को पकड़ने में सक्षम थे, लेकिन मुझे नहीं पता कि यह कैसे प्राप्त किया जाए।

— रोमन होके

क्या आपके पास आरडीएस के साथ इसे प्राप्त करने के लिए कोई सुझाव है? आरडीएस का उपयोग करते समय स्वाभाविक रूप से हमारे पास एक लिनक्स शेल तक पहुंच नहीं होती है, लेकिन हम बहुत अच्छी तरह से यह अनुमान लगाने में सक्षम होना पसंद करेंगे।

— jwg2s

@ jwg2s "RDS" से आपका क्या मतलब है, कृपया अमेज़ॅन की डेटाबेस सेवाएं? यदि हां, तो मैं दुर्भाग्य से परिचित नहीं हूँ :-( शायद उनके समर्थन से मदद मिलेगी।

— रोमन होके

पूरी तरह से वैक्यूम के साथ पीजी 10 पर अच्छी तरह से काम करने लगता है।

— डायलनयुंग

Answer 2

यह निर्धारित करना बहुत कठिन है। आप अधिक एग्रेसिव होने के लिए ऑटोवैसम्यूइंग को ट्यून कर सकते हैं या मिलर हो सकते हैं । लेकिन जब इसे हल्के में सेट किया जाता है और यह पिछड़ जाता है और आधार I / O लोड बहुत अधिक होता है, तो ऐसा हो सकता है कि यह कभी भी एक उचित वैक्यूम स्थिति तक नहीं पहुंचता है - फिर आप प्रक्रिया को चालू करते हुए और दौड़ते हुए देखते हैं। इसके अलावा, बाद में PostreSQL संस्करणों में बहुत सुधार हुआ है ऑटोवैक्यूम क्षमताओं, यह अकेले उनमें से एक को स्थानांतरित करने के लिए पर्याप्त हो सकता है (अधिमानतः 9.2 सबसे हाल के एक के रूप में)।

प्रगति बार एक अच्छा विचार लगता है लेकिन मुझे लगता है कि इसे लागू करना आसान नहीं है। जैसा कि आपकी तालिकाओं पर निरंतर भार है, यह काफी संभव है कि प्रगति स्पष्ट रूप से पीछे की ओर जा रही है (मेरा मतलब है कि मृत पंक्ति की संख्या / प्रतिशत घटने के बजाय बढ़ जाती है) - फिर आप किस निष्कर्ष पर आते हैं?

Comments

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

— zaadeh

VACUUM ANALYZE VERBOSEकम से कम कुछ गतिविधि को कंसोल पर प्रिंट करता है क्योंकि यह बात करता है। यह बेहतर है तो बस एक स्थिर संकेत पर सोच रहा है कि कुछ घंटों के लिए अटक गया है।

— फर्जी नाम

सवाल "वैक्यूम / ऑटोवैक्यूम" के बारे में पूछता है। उपरोक्त केवल VACUUMऑटोवेक्यूम के लिए उपयोगी है , लेकिन यह अभी भी कुछ है।

— नकली नाम

@ फेकनेम एह, मैंने सवाल को गलत बताया - मैनुअल वैक्यूम भाग को याद किया। क्षमा करें, मैं अपनी टिप्पणी हटा रहा हूं।

— dezso

Answer 3

हमारे उत्पादन में सबसे बड़ी तालिकाओं में से एक में यह लॉग था:

pages: 0 removed, 1801722 remain
tuples: 238912 removed, 42582083 remain, 1396 are dead but not yet removable
buffer usage: 9477565 hits, 3834218 misses, 2220101 dirtied
avg read rate: 2.976 MB/s, avg write rate: 1.723 MB/s
system usage: CPU 68.47s/177.49u sec elapsed 10065.08 sec

यह अब तक की सबसे खराब संसाधन खपत है, अन्य सभी तालिकाओं में 2 एस से कम लिया गया है।

इस प्रकार के लॉग देखने के लिए आपको इस पर अमल करना चाहिए:

alter system set log_autovacuum_min_duration TO 5; 

(5 एमएस के लिए), कॉन्फ़िगरेशन फ़ाइल को फिर से लोड करें।

Answer 4

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

मैं इस क्वेरी का उपयोग वैक्यूम की टेबल स्कैनिंग की प्रगति की निगरानी करने के लिए करता हूं, जो कि काम का बड़ा हिस्सा लगता है:

SELECT heap_blks_scanned/cast(heap_blks_total as numeric)*100 as heap_blks_percent, progress.*, activity.query
FROM pg_stat_progress_vacuum AS progress
INNER JOIN pg_stat_activity AS activity ON activity.pid = progress.pid;

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