चेकप्वाइंट राइट-हैवी पोस्टग्रेएसक्यूएल इंस्टॉलेशन पर एक प्रमुख ड्रैग हो सकता है। इस क्षेत्र में मुद्दों की पहचान करने की दिशा में पहला कदम यह निगरानी करना है कि वे कितनी बार होते हैं, जो हाल ही में डेटाबेस में जोड़े गए इंटरफ़ेस का उपयोग करना आसान हो गया है।
चेकपॉइंट आवधिक रखरखाव संचालन हैं जो डेटाबेस यह सुनिश्चित करने के लिए करता है कि यह सब कुछ जो मेमोरी में कैशिंग कर रहा है वह डिस्क के साथ सिंक्रनाइज़ किया गया है। विचार यह है कि एक बार जब आप एक पूरा कर लेते हैं, तो आप डेटाबेस के राइट-फॉरवर्ड लॉग में रखी गई पुरानी प्रविष्टियों के बारे में चिंता करने की आवश्यकता को समाप्त कर सकते हैं। इसका मतलब है कि दुर्घटना के बाद ठीक होने में कम समय लगता है।
चेकपॉइंट्स के साथ समस्या यह है कि वे बहुत गहन हो सकते हैं, क्योंकि एक को पूरा करने के लिए डेटाबेस के बफर कैशे में हर एक बदले हुए डेटा को डिस्क पर लिखने की आवश्यकता होती है। PostgreSQL 8.3 में कई सुविधाएँ जोड़ी गईं जो आपको चेकपॉइंट ओवरहेड की बेहतर निगरानी करने और गतिविधि को लंबी अवधि में फैलाकर इसे कम करने की अनुमति देती हैं। मैंने उन परिवर्तनों के बारे में एक लंबा लेख लिखा, जिन्हें चेकपॉइंट्स और बैकग्राउंड राइटर कहा जाता है, जो कि बदल जाता है, लेकिन यह बहुत शुष्क पठन है।
आप शायद यह जानना चाहते हैं कि अपने उत्पादन प्रणाली पर चौकियों की निगरानी कैसे करें, और कैसे बताएं अगर वे बहुत बार हो रहे हैं। हालांकि चीजों में सुधार हुआ है, "चेकपॉइंट स्पाइक्स" जहां डिस्क I/O वास्तव में भारी हो जाती है, वर्तमान PostgreSQL संस्करणों में भी अभी भी संभव है। और यह मदद नहीं करता है कि डिफ़ॉल्ट कॉन्फ़िगरेशन प्रदर्शन के बजाय बहुत कम डिस्क स्थान और तेज़ क्रैश पुनर्प्राप्ति के लिए ट्यून किया गया है। checkpoint_segments पैरामीटर, जो एक इनपुट है कि चेकपॉइंट कितनी बार होता है, डिफ़ॉल्ट रूप से 3 हो जाता है, जो केवल 48MB लिखने के बाद चेकपॉइंट को बाध्य करता है।
आप चेकपॉइंट आवृत्ति को दो तरीकों से ढूंढ सकते हैं। आप log_checkpoints चालू कर सकते हैं और देख सकते हैं कि लॉग में क्या होता है। आप pg_stat_bgwriter दृश्य का भी उपयोग कर सकते हैं, जो चौकियों के लिए दो स्रोतों में से प्रत्येक की एक गिनती देता है (समय बीतता है और लिखता है) साथ ही आंकड़ों के बारे में बताता है कि उन्होंने कितना काम किया।
इसे आसान बनाने के साथ मुख्य समस्या क्या यह है कि कुछ समय पहले तक, pg_stat_bgwriter के अंदर काउंटरों को रीसेट करना असंभव था। इसका मतलब है कि आपको टाइमस्टैम्प के साथ एक स्नैपशॉट लेना है, थोड़ी देर प्रतीक्षा करें, एक और स्नैपशॉट लें, फिर डेटा से कोई भी उपयोगी आंकड़े प्राप्त करने के लिए सभी मानों को घटाएं। यह एक दर्द है।
एक दर्द के लिए पर्याप्त है कि मैंने इसे आसान बनाने के लिए एक पैच लिखा। डेटाबेस के वर्तमान विकास संस्करण के साथ, अब आप pg_stat_reset_shared('bgwriter') पर कॉल कर सकते हैं और इन सभी मानों को फिर से 0 पर पॉप कर सकते हैं। यह एक अभ्यास का पालन करने की अनुमति देता है जो PostgreSQL पर आम हुआ करता था। 8.3 से पहले, stats_reset_on_server_start नाम का एक पैरामीटर था जिसे आप चालू कर सकते थे। हर बार जब आप इसे शुरू करते हैं तो सर्वर के सभी आंतरिक आंकड़े रीसेट हो जाते हैं। इसका मतलब है कि आप आसान pg_postmaster_start_time() फ़ंक्शन को कॉल कर सकते हैं, वर्तमान समय के साथ तुलना कर सकते हैं, और सिस्टम पर उपलब्ध किसी भी आंकड़े के संचालन/सेकंड के संदर्भ में हमेशा सटीक गणना कर सकते हैं।
यह अभी भी स्वचालित नहीं है, लेकिन अब कि इन साझा किए गए टुकड़ों को रीसेट करना संभव है, आप इसे स्वयं कर सकते हैं। पहली कुंजी आपके सर्वर स्टार्टअप अनुक्रम में समाशोधन के आंकड़ों को एकीकृत करना है। इस तरह की एक स्क्रिप्ट काम करेगी:
pg_ctl start -l $PGLOG -w
psql -c "select pg_stat_reset();"
psql -c "select pg_stat_reset_shared('bgwriter');"
वहां स्टार्ट कमांड पर "-w" नोट करें- जो सर्वर के वापस आने से पहले शुरू होने तक pg_ctl प्रतीक्षा करेगा, जो महत्वपूर्ण है यदि आप इसके खिलाफ तुरंत एक स्टेटमेंट निष्पादित करना चाहते हैं।
यदि आपने किया है वह, और आपका सर्वर प्रारंभ समय अनिवार्य रूप से वही है जब पृष्ठभूमि लेखक आंकड़े संग्रह शुरू करते हैं, अब आप इस मजेदार क्वेरी का उपयोग कर सकते हैं:
SELECT
total_checkpoints,
seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints
FROM
(SELECT
EXTRACT(EPOCH FROM (now() - pg_postmaster_start_time())) AS seconds_since_start,
(checkpoints_timed+checkpoints_req) AS total_checkpoints
FROM pg_stat_bgwriter
) AS sub;
और एक साधारण रिपोर्ट प्राप्त करें कि आपके सिस्टम पर कितनी बार चौकियां हो रही हैं। आउटपुट इस तरह दिखता है:
total_checkpoints | 9
minutes_between_checkpoints | 3.82999310740741
आप इस जानकारी के साथ जो करते हैं वह औसत समय अंतराल पर घूरना है और देखें कि क्या यह बहुत तेज़ लगता है। आम तौर पर, आप चाहते हैं कि एक चेकपॉइंट हर पांच मिनट से अधिक न हो, और व्यस्त सिस्टम पर आपको इसे बनाए रखने की आशा रखने के लिए इसे दस मिनट या उससे अधिक तक धकेलने की आवश्यकता हो सकती है। इस उदाहरण के साथ, हर 3.8 मिनट शायद बहुत तेज़ है—यह एक ऐसी प्रणाली है जिसके लिए checkpoint_segments अधिक होना आवश्यक है।
चेकपॉइंट अंतराल को मापने के लिए इस तकनीक का उपयोग करने से आपको पता चलता है कि आपको checkpoint_segments और checkpoint_timeout पैरामीटर को क्रम में बढ़ाने की आवश्यकता है या नहीं। उस लक्ष्य को प्राप्त करने के लिए। आप अभी मैन्युअल रूप से संख्याओं की गणना कर सकते हैं, और एक बार 9.0 शिप होने के बाद आप इसे पूरी तरह से स्वचालित बनाने पर विचार कर सकते हैं-जब तक कि आपको हर बार सर्वर के पुनरारंभ होने पर अपने आँकड़ों के दूर जाने पर कोई आपत्ति न हो।
कुछ अन्य दिलचस्प तरीके हैं डेटा का विश्लेषण करने के लिए पृष्ठभूमि लेखक आपको pg_stat_bgwriter में प्रदान करता है, लेकिन मैं आज अपनी सभी तरकीबें नहीं बताने जा रहा हूं।
