PostgreSQL के लिए ट्यूनिंग इनपुट/आउटपुट (I/O) संचालन

PostgreSQL दुनिया में सबसे लोकप्रिय ओपन-सोर्स डेटाबेस में से एक है और विभिन्न डोमेन में कई मिशन-महत्वपूर्ण वातावरणों में सफल कार्यान्वयन है, जो रीयल-टाइम हाई-एंड OLTP एप्लिकेशन का उपयोग करके प्रति दिन लाखों और अरबों लेनदेन करता है। PostgreSQL I/O काफी विश्वसनीय, स्थिर और क्लाउड सहित किसी भी हार्डवेयर पर काफी अच्छा प्रदर्शन करने वाला है।

यह सुनिश्चित करने के लिए कि डेटाबेस अपेक्षित प्रतिक्रिया समय के साथ अपेक्षित पैमाने पर प्रदर्शन करते हैं, कुछ प्रदर्शन इंजीनियरिंग की आवश्यकता है। खैर, अच्छे डेटाबेस प्रदर्शन की उपलब्धि विभिन्न कारकों पर निर्भर करती है। डेटाबेस का प्रदर्शन विभिन्न कारणों से खराब हो सकता है जैसे कि बुनियादी ढांचे का आकार बदलना, अक्षम डेटाबेस रखरखाव रणनीति, खराब SQL कोड या बुरी तरह से कॉन्फ़िगर की गई डेटाबेस प्रक्रियाएं जो सभी उपलब्ध संसाधनों - CPU, मेमोरी, नेटवर्क बैंडविड्थ और डिस्क I/O का उपयोग करने में विफल रहती हैं।

डेटाबेस के प्रदर्शन में गिरावट का क्या कारण हो सकता है?

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

तो यह बहुत सारे संभावित क्षेत्र हैं जो प्रदर्शन समस्याओं का कारण बन सकते हैं। इस ब्लॉग में मैं जिन महत्वपूर्ण क्षेत्रों पर ध्यान केंद्रित करना चाहूंगा उनमें से एक यह है कि PostgreSQL I/O (इनपुट/आउटपुट) प्रदर्शन को कैसे ट्यून किया जाए। PostgreSQL के इनपुट / आउटपुट संचालन को ट्यून करना आवश्यक है, विशेष रूप से OLTP जैसे उच्च-लेनदेन वाले वातावरण में या बड़े आकार के डेटा सेट पर जटिल डेटा विश्लेषण के साथ डेटा वेयरहाउसिंग वातावरण में।

अधिकांश समय, डेटाबेस प्रदर्शन समस्याएँ मुख्य रूप से उच्च I/O के कारण होती हैं। इसका मतलब है, डेटाबेस प्रक्रियाएं डिस्क पर लिखने या पढ़ने में अधिक समय व्यतीत कर रही हैं। कोई भी रीयल-टाइम डेटा ऑपरेशन I/O बाध्य है, यह सुनिश्चित करना अनिवार्य है कि डेटाबेस I/O ट्यून किया गया है। इस ब्लॉग में, मैं सामान्य I/O समस्याओं पर ध्यान केंद्रित करूँगा जो PostgreSQL डेटाबेस वास्तविक समय के उत्पादन वातावरण में सामना कर सकते हैं।

PostgreSQL I/O को ट्यून करना

उच्च प्रदर्शन और स्केलेबल डेटाबेस आर्किटेक्चर के निर्माण के लिए पोस्टग्रेएसक्यूएल I/O ट्यूनिंग अनिवार्य है। आइए हम I/O प्रदर्शन को प्रभावित करने वाले विभिन्न कारकों को देखें:

• अनुक्रमण
• विभाजन
• चेकपॉइंट
• वैक्यूम, विश्लेषण (फ़िलफैक्टर के साथ)
• अन्य I/O समस्याएं
• बादल पर PostgreSQL I/O
• उपकरण

अनुक्रमण

इंडेक्सिंग कोर ट्यूनिंग तकनीकों में से एक है जो डेटाबेस I/O प्रदर्शन को बेहतर बनाने में एक अनिवार्य भूमिका निभाता है। यह वास्तव में किसी भी डेटाबेस पर लागू होता है। PostgreSQL विभिन्न इंडेक्स प्रकारों का समर्थन करता है जो काफी हद तक पढ़ने के संचालन को तेज कर सकते हैं, अनुप्रयोगों के लिए बढ़ी हुई मापनीयता प्रदान करते हैं। जबकि इंडेक्स बनाना काफी सरल और सीधा है, डीबीए और डेवलपर्स के लिए यह जानना जरूरी है कि किस प्रकार के इंडेक्स को चुनना है, और किस कॉलम पर। उत्तरार्द्ध विभिन्न कारकों जैसे क्वेरी जटिलता, डेटा प्रकार, डेटा कार्डिनैलिटी, लिखने की मात्रा, डेटा आकार, डिस्क आर्किटेक्चर, बुनियादी ढांचे (सार्वजनिक क्लाउड, निजी क्लाउड या ऑन-प्रिमाइसेस), आदि पर आधारित है।

जबकि अनुक्रमण क्वेरी पढ़ने के प्रदर्शन में नाटकीय रूप से सुधार कर सकता है, यह अनुक्रमित कॉलम को मारने वाले लेखन को भी धीमा कर सकता है। आइए एक उदाहरण देखें:

पढ़ने के संचालन पर अनुक्रमणिका का प्रभाव

लगभग 1 मिलियन पंक्तियों वाली एक तालिका जिसे Emp कहा जाता है।

सूचकांक के बिना प्रदर्शन पढ़ें

postgres=# select * from emp where eid=10;

 eid | ename    | peid | did  |    doj
-----+---------------+--------+------+------------
  10 | emp        |          |   1   | 2018-06-06
(1 row)
 
Time: 70.020 ms => took about 70+ milli-seconds to respond with on row

इंडेक्स के साथ प्रदर्शन पढ़ें

आइए ईद कॉलम पर एक इंडेक्स लगाएं और अंतर देखें

postgres=# create index indx001 on emp ( eid );
CREATE INDEX

postgres=# select * from emp where eid=10;

 eid | ename  | peid | did |    doj
------+-------------+-------+------+------------
  10 | emp      |          |   1   | 2018-06-06
(1 row)
 
Time: 0.454 ms =>  0.4+ milli-seconds!!! thats a huge difference - isn’t it?

इसलिए, अनुक्रमण महत्वपूर्ण है।

WRITE संचालन पर अनुक्रमणिका का प्रभाव

अनुक्रमणिका लेखन के प्रदर्शन को धीमा कर देती है। जबकि अनुक्रमणिका का सभी प्रकार के लेखन कार्यों पर प्रभाव पड़ता है, आइए INSERTs पर अनुक्रमणिका के प्रभाव पर कुछ विश्लेषण देखें

सूचकांक के बिना तालिका में 1 मिलियन पंक्तियों को सम्मिलित करना

postgres=# do $$
postgres$# declare
postgres$# i integer;
postgres$# begin
postgres$# for i in 1..1000000 loop
postgres$# insert into emp values (i,'emp',null,1,current_date);
postgres$# end loop;
postgres$# end $$;
DO

Time: 4818.470 ms (00:04.818) => Takes about 4.8 seconds

समान 1 मिलियन पंक्तियों को अनुक्रमणिका के साथ सम्मिलित करना

आइए पहले एक इंडेक्स बनाएं

postgres=# create index indx001 on emp ( eid );
CREATE INDEX

postgres=# do $$
postgres$# declare
postgres$# i integer;
postgres$# begin
postgres$# for i in 1..1000000 loop
postgres$# insert into emp values (i,'emp',null,1,current_date);
postgres$# end loop;
postgres$# end $$;
DO

Time: 7825.494 ms (00:07.825) =>  Takes about 7.8 seconds

इसलिए, जैसा कि हम देख सकते हैं, INSERT के समय में केवल एक इंडेक्स के साथ 80% की वृद्धि हुई है और कई इंडेक्स होने पर समाप्त होने में बहुत अधिक समय लग सकता है। फ़ंक्शन आधारित इंडेक्स होने पर यह और भी खराब हो सकता है। यही डीबीए के साथ रहना है! इंडेक्स लिखने के प्रदर्शन को बढ़ाएंगे। हालांकि इस समस्या से निपटने के तरीके हैं, जो डिस्क आर्किटेक्चर पर निर्भर है। यदि डेटाबेस सर्वर एकाधिक डिस्क फ़ाइल सिस्टम का उपयोग कर रहा है, तो अनुक्रमणिका और तालिकाओं को एकाधिक डिस्क फ़ाइल सिस्टम में बैठे कई टेबलस्पेस में रखा जा सकता है। इस तरह, बेहतर I/O प्रदर्शन प्राप्त किया जा सकता है।

सूचकांक प्रबंधन युक्तियाँ

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

विभाजन

एक प्रभावी विभाजन रणनीति I/O प्रदर्शन समस्याओं को काफी हद तक कम कर सकती है। व्यावसायिक तर्क के आधार पर बड़ी तालिकाओं को विभाजित किया जा सकता है। PostgreSQL तालिका विभाजन का समर्थन करता है। हालांकि यह इस समय सभी सुविधाओं का पूरी तरह से समर्थन नहीं करता है, यह केवल कुछ वास्तविक समय के उपयोग-मामलों में मदद कर सकता है। PostgreSQL में, विभाजित चाइल्ड टेबल मास्टर टेबल के लिए पूरी तरह से अलग हैं जो एक अड़चन है। उदाहरण के लिए, मास्टर टेबल पर बनाई गई बाधाएं स्वचालित रूप से चाइल्ड टेबल में इनहेरिट नहीं की जा सकतीं।

हालाँकि, I/O के दृष्टिकोण से संतुलन बनाने से, विभाजन वास्तव में मदद कर सकता है। सभी चाइल्ड पार्टीशन को कई टेबलस्पेस और डिस्क फाइल सिस्टम में विभाजित किया जा सकता है। दिनांक सीमा के आधार पर विभाजित तालिका को हिट करने वाले "कहां" खंड में दिनांक सीमा वाली क्वेरी, पूर्ण तालिका के बजाय केवल एक या दो विभाजनों को स्कैन करके विभाजन से लाभ उठा सकती हैं।

चेकपॉइंटिंग

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

चेकपॉइंट क्या करता है?

सरल शब्दों में, चौकियां सुनिश्चित करेंगी:

• सभी प्रतिबद्ध डेटा डिस्क पर डेटा फ़ाइलों को लिखा जाता है।
• क्लॉग फ़ाइलें प्रतिबद्ध स्थिति के साथ अपडेट की जाती हैं।
• pg_xlog (अब pg_wal) निर्देशिका में लेन-देन लॉग फ़ाइलें पुनर्नवीनीकरण की जाती हैं।

यह बताता है कि I/O गहन चौकियां कैसी हैं। Postgresql.conf में पैरामीटर हैं जिन्हें चेकपॉइंट व्यवहार को नियंत्रित करने के लिए कॉन्फ़िगर/ट्यून किया जा सकता है और वे पैरामीटर max_wal_size, min_wal_size, checkpoint_timeout और checkpoint_completion_target हैं। ये पैरामीटर तय करेंगे कि कितनी बार चौकियां होनी चाहिए, और कितने समय में चौकियों को खत्म करना है।

कैसे समझें कि चौकियों के लिए कौन सा कॉन्फ़िगरेशन बेहतर है? उन्हें कैसे ट्यून करें?

यहां कुछ युक्तियां दी गई हैं:

• डेटाबेस टीपीएस का मूल्यांकन करें। एक व्यावसायिक दिन में डेटाबेस में होने वाले लेन-देन की कुल मात्रा का मूल्यांकन करें और यह भी पहचानें कि किस समय सबसे अधिक लेन-देन डेटाबेस से टकराते हैं।
• डेटाबेस लेनदेन दर आंकड़ों के साथ-साथ भावी लेनदेन वृद्धि को समझने के लिए एप्लिकेशन डेवलपर्स और अन्य तकनीकी टीमों के साथ नियमित रूप से चर्चा करें।
• यह डेटाबेस के अंत से भी किया जा सकता है:

  • डेटाबेस की निगरानी करें और दिन के दौरान होने वाले लेनदेन की संख्या का मूल्यांकन करें। यह pg_stat_user_tables जैसी pgcatalog तालिकाओं को क्वेरी करके किया जा सकता है।

  • प्रति दिन जेनरेट की गई वॉल आर्काइव फाइलों की संख्या का मूल्यांकन करें

  • यह समझने के लिए निगरानी करें कि log_checkpoint पैरामीटर सक्षम करके चौकियां कैसा प्रदर्शन कर रही हैं

    2018-06-06 15:03:16.446 IST [2111] LOG:  checkpoint starting: xlog
    2018-06-06 15:03:22.734 IST [2111] LOG:  checkpoint complete: wrote 12112 buffers (73.9%); 0 WAL file(s) added, 0 removed, 25 recycled; write=6.058 s, sync=0.218 s, total=6.287 s; sync files=4, longest=0.178 s, average=0.054 s; distance=409706 kB, estimate=412479 kB

  • समझें कि क्या वर्तमान चेकपॉइंट कॉन्फ़िगरेशन डेटाबेस के लिए पर्याप्त है। पोस्टग्रेज़ लॉग फ़ाइलों में नीचे दी गई चेतावनियों को देखने के लिए checkpoint_warning पैरामीटर (डिफ़ॉल्ट रूप से 30 सेकंड के लिए कॉन्फ़िगर किया गया) कॉन्फ़िगर करें।

    2018-06-06 15:02:42.295 IST [2111] LOG:  checkpoints are occurring too frequently (11 seconds apart)
    2018-06-06 15:02:42.295 IST [2111] HINT:  Consider increasing the configuration parameter "max_wal_size".

उपरोक्त चेतावनी का क्या अर्थ है?

चेकपॉइंट आमतौर पर तब होते हैं जब max_wal_size (डिफ़ॉल्ट रूप से 1 जीबी जिसका अर्थ है 64 WAL फाइलें) लायक लॉगफाइल्स भर जाती हैं या जब checkpoint_timeout (हर 5 मिनट में हर डिफ़ॉल्ट) तक पहुंच जाता है। उपरोक्त चेतावनी का मतलब है कि कॉन्फ़िगर किया गया max_wal_size पर्याप्त नहीं है और हर 11 सेकंड में चौकियां हो रही हैं, इसका मतलब है कि PG_WAL निर्देशिका में 64 WAL फाइलें केवल 11 सेकंड में भर रही हैं, जो कि बहुत बार होती है। दूसरे शब्दों में, यदि कम बार-बार लेन-देन होते हैं, तो हर 5 मिनट में चेकपॉइंट होंगे। इसलिए, जैसा कि संकेत से पता चलता है, max_wal_size पैरामीटर को एक उच्च मान तक बढ़ाएं, max_min_size पैरामीटर को उसी या पूर्व की तुलना में कम तक बढ़ाया जा सकता है।

I/O प्रदर्शन परिप्रेक्ष्य से विचार करने के लिए एक और महत्वपूर्ण पैरामीटर checkpoint_completion_target है जो डिफ़ॉल्ट रूप से 0.5 पर कॉन्फ़िगर किया गया है।

checkpoint_completion_target =0.5 x checkpoint_timeout =2.5 मिनट

इसका मतलब है कि, गंदे ब्लॉक को डिस्क में सिंक करने के लिए चौकियों को 2.5 मिनट का समय मिला है। क्या 2.5 मिनट पर्याप्त हैं? इसका मूल्यांकन करने की जरूरत है। यदि लिखे जाने वाले गंदे ब्लॉकों की संख्या बहुत अधिक है, तो 2.5 मिनट बहुत आक्रामक लग सकते हैं और वह तब होता है जब एक I/O स्पाइक देखा जा सकता है। पूर्णता_लक्ष्य पैरामीटर को कॉन्फ़िगर करना max_wal_size और checkpoint_timeout मानों के आधार पर किया जाना चाहिए। यदि इन मापदंडों को उच्च मान तक बढ़ा दिया जाता है, तो तदनुसार checkpoint_completion_target बढ़ाने पर विचार करें।

वैक्यूम, विश्लेषण (फ़िलफैक्टर के साथ)

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

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

ऑटोवैक्यूम पैरामीटर

ऑटोवैक्यूम प्रक्रिया शुरू करने के लिए सीमा निर्धारित करने वाले पैरामीटर

ऑटोवैक्यूम कार्य एक निश्चित सीमा तक पहुंचने पर शुरू हो जाता है। नीचे वे पैरामीटर दिए गए हैं जिनका उपयोग एक निश्चित सीमा निर्धारित करने के लिए किया जा सकता है, जिसके आधार पर, ऑटोवैक्यूम प्रक्रिया शुरू हो जाएगी।

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

मेरा सुझाव है कि पूरी तरह से ऑटोवैक्यूम प्रक्रिया पर निर्भर न रहें, सबसे अच्छा तरीका यह है कि रात में एक वैक्यूम विश्लेषण कार्य निर्धारित किया जाए ताकि ऑटोवैक्यूम पर बोझ कम हो। आरंभ करने के लिए, उच्च-लेनदेन दर वाली बड़ी तालिकाओं को मैन्युअल रूप से खाली करने पर विचार करें।

वैक्यूम भरा हुआ

VACUUM FULL टेबल और इंडेक्स में फूले हुए स्थान को पुनः प्राप्त करने में मदद करता है। इस उपयोगिता का उपयोग तब नहीं किया जा सकता जब डेटाबेस ऑनलाइन हो क्योंकि यह तालिका को लॉक कर देता है। टेबल्स को केवल तभी VACUUM FULL के अधीन किया जाना चाहिए जब एप्लिकेशन शटडाउन हों। VACUUM FULL के दौरान तालिकाओं के साथ-साथ अनुक्रमणिका को भी पुनर्व्यवस्थित किया जाएगा।

आइए वैक्यूम विश्लेषण के प्रभाव पर एक नज़र डालें

ब्लोट्स:ब्लोट की पहचान कैसे करें? ब्लोट कब उत्पन्न होते हैं?

यहां कुछ परीक्षण दिए गए हैं:

मेरे पास 1 जीबी आकार की एक तालिका है जिसमें 10 मिलियन पंक्तियां हैं।

postgres=# select pg_relation_size('pgbench_accounts')/1024/1024/1024;

 ?column? 
----------------
        1

postgres=# select count(*) From pgbench_accounts ;
  count   
-----------------
 10000000

आइए एक साधारण क्वेरी पर ब्लोट के प्रभाव को देखें:pgbench_accounts से * चुनें;

क्वेरी के लिए व्याख्या योजना नीचे दी गई है:

postgres=# explain analyze select * from pgbench_accounts;

QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on pgbench_accounts  (cost=0.00..263935.00 rows=10000000 width=97) 
 (actual time=0.033..1054.257 rows=10000000 loops=1)
 Planning time: 0.255 ms
 Execution time: 1494.448 ms

अब, तालिका की सभी पंक्तियों को अपडेट करते हैं और उपरोक्त SELECT क्वेरी के प्रभाव को देखते हैं।

postgres=# update pgbench_accounts set abalance=1;
UPDATE 10000000

postgres=# select count(*) From pgbench_accounts ;
  count   
-----------------
 10000000

अद्यतन निष्पादन के बाद क्वेरी की व्याख्या योजना नीचे दी गई है।

postgres=# explain analyze select * from pgbench_accounts;

QUERY PLAN                                                             
----------------------------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on pgbench_accounts  (cost=0.00..527868.39 rows=19999939 width=97) 
 (actual time=404.474..1520.175 rows=10000000 loops=1)
 Planning time: 0.051 ms
 Execution time: 1958.532 ms

अद्यतन के बाद तालिका का आकार बढ़कर 2 जीबी हो गया

postgres=# select pg_relation_size('pgbench_accounts')/1024/1024/1024;

 ?column? 
-----------------
        2

यदि आप पहले की व्याख्या योजना की लागत संख्याओं का अवलोकन और तुलना कर सकते हैं, तो बहुत बड़ा अंतर है। लागत में बड़े अंतर से वृद्धि हुई है। इससे भी महत्वपूर्ण बात यह है कि यदि आप ध्यान से देखें, तो अद्यतन के बाद स्कैन की जा रही पंक्तियों की संख्या (सिर्फ 19 मिलियन से अधिक) अधिक है जो वास्तविक मौजूदा पंक्तियों (10 मिलियन) से लगभग दो गुना अधिक है। इसका मतलब है, फूली हुई पंक्तियों की संख्या 9+ मिलियन है और वास्तविक समय में भी वृद्धि हुई है और निष्पादन समय 1.4 सेकंड से बढ़कर 1.9 सेकंड हो गया है।

तो, यह अद्यतन के बाद तालिका को खाली न करने का प्रभाव है। उपरोक्त व्याख्या योजना संख्या का सटीक अर्थ है, तालिका फूली हुई है।

कैसे पहचानें कि टेबल फूला हुआ है? pgstattuple योगदान मॉड्यूल का उपयोग करें:

postgres=# select * from pgstattuple('pgbench_accounts');
 table_len  | tuple_count | tuple_len  | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
------------+-------------+------------+---------------+------------------+----------------+--------------------+------------+--------------
 2685902848 |    10000000 | 1210000000 |         45.05 |          9879891 |     1195466811 |              44.51 |   52096468 |         1.94

उपरोक्त संख्या इंगित करती है कि तालिका का आधा भाग फूला हुआ है।

आइए हम तालिका का विश्लेषण करें और अब प्रभाव देखें:

postgres=# VACUUM ANALYZE pgbench_accounts ;
VACUUM

postgres=# explain analyze select * from pgbench_accounts;

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on pgbench_accounts  (cost=0.00..428189.05 rows=10032005 width=97) 
 (actual time=400.023..1472.118 rows=10000000 loops=1)
 Planning time: 4.374 ms
 Execution time: 1913.541 ms

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

postgres=# select * from pgstattuple('pgbench_accounts');

 table_len  | tuple_count | tuple_len  | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent 
------------+-------------+------------+---------------+------------------+----------------+--------------------+------------+--------------
 2685902848 |    10000000 | 1210000000 |         45.05 |             0 |              0 |                  0 | 1316722516 |        49.02

उपरोक्त संख्या इंगित करती है कि सभी ब्लोट (मृत टुपल्स) गायब हो गए हैं।

आइए हम वैक्यूम पूर्ण विश्लेषण के प्रभाव को देखें और देखें कि क्या होता है:

postgres=# vacuum full analyze pgbench_accounts ;
VACUUM

postgres=# explain analyze select * from pgbench_accounts;

                            QUERY PLAN                                                            
---------------------------------------------------------------------------
 Seq Scan on pgbench_accounts  (cost=0.00..263935.35 rows=10000035 width=97) 
(actual time=0.015..1089.726 rows=10000000 loops=1)
 Planning time: 0.148 ms
 Execution time: 1532.596 ms

यदि आप देखें, तो वास्तविक समय और निष्पादन समय संख्याएँ UPDATE से पहले की संख्याओं के समान हैं। साथ ही, टेबल का आकार अब 2 जीबी से घटाकर 1 जीबी कर दिया गया है।

postgres=# select pg_relation_size('pgbench_accounts')/1024/1024/1024;

 ?column? 
-----------------
        1

यह VACUUM FULL का प्रभाव है।

फिलफैक्टर

FILLFACTOR एक बहुत ही महत्वपूर्ण विशेषता है जो तालिका और सूचकांक स्तर पर डेटाबेस रखरखाव रणनीति में वास्तविक अंतर ला सकती है। यह मान डेटा ब्लॉक के भीतर INSERTs द्वारा उपयोग किए जाने वाले स्थान की मात्रा को इंगित करता है। FILLFACTOR मान डिफ़ॉल्ट रूप से 100% हो जाता है, जिसका अर्थ है कि INSERT डेटा ब्लॉक में उपलब्ध सभी स्थान का उपयोग कर सकते हैं। इसका अर्थ यह भी है कि अद्यतन के लिए कोई स्थान उपलब्ध नहीं है। भारी अद्यतन तालिकाओं के लिए इस मान को एक निश्चित मान तक घटाया जा सकता है।

यह पैरामीटर प्रत्येक तालिका और एक अनुक्रमणिका में कॉन्फ़िगर किया जा सकता है। यदि FILLFACTOR को इष्टतम मान के लिए कॉन्फ़िगर किया गया है, तो आप VACUUM प्रदर्शन और क्वेरी प्रदर्शन में भी वास्तविक अंतर देख सकते हैं। संक्षेप में, इष्टतम FILLFACTOR मान सुनिश्चित करते हैं कि अनावश्यक संख्या में ब्लॉक आवंटित नहीं किए गए हैं।

आइए हम ऊपर उसी उदाहरण को देखें -

तालिका में दस लाख पंक्तियां हैं

postgres=# select count(*) From pgbench_accounts ;
  count   
-----------------
 10000000

अद्यतन करने से पहले तालिका का आकार 1 जीबी है

postgres=# select pg_relation_size('pgbench_accounts')/1024/1024/1024;

?column? 
--------
   1

postgres=# update pgbench_accounts set abalance=1;
UPDATE 10000000

अद्यतन के बाद, अद्यतन के बाद तालिका का आकार बढ़कर 2 जीबी हो गया

postgres=# select pg_relation_size('pgbench_accounts')/1024/1024/1024;

?column? 
---------
    2

इसका मतलब है कि तालिका में आवंटित ब्लॉकों की संख्या में 100% की वृद्धि हुई है। यदि FILLFACTOR कॉन्फ़िगर किया गया था, तो हो सकता है कि तालिका का आकार उस मार्जिन से नहीं बढ़ा हो।

कैसे पता करें कि FILLFACTOR में किस मान को कॉन्फ़िगर करना है?

यह सब इस बात पर निर्भर करता है कि कौन से कॉलम अपडेट किए जा रहे हैं और अपडेट किए गए कॉलम का आकार क्या है। सामान्य तौर पर, UAT डेटाबेस में इसका परीक्षण करके FILLFACTOR मूल्य का मूल्यांकन करना अच्छा होगा। यदि अद्यतन किए जा रहे स्तंभ संपूर्ण तालिका के 10% हैं, तो फ़िलफ़ैक्टर को 90% या 80% पर कॉन्फ़िगर करने पर विचार करें।

महत्वपूर्ण नोट:
यदि आप डेटा के साथ मौजूदा तालिका के लिए FILLFACTOR मान बदलते हैं, तो आपको मौजूदा डेटा के लिए FILLFACTOR मान प्रभावी है, यह सुनिश्चित करने के लिए तालिका का एक VACUUM पूर्ण या पुन:संगठन करने की आवश्यकता होगी।

वैक्यूमिंग टिप्स

• जैसा कि ऊपर कहा गया है, ऑटोवैक्यूम सक्षम होने पर भी भारी उपयोग की जाने वाली टेबल पर हर रात मैन्युअल रूप से वैक्यूम विश्लेषण कार्य चलाने पर विचार करें।
• बल्क INSERT के बाद टेबल पर VACUUM ANALYZE चलाने पर विचार करें। यह महत्वपूर्ण है क्योंकि बहुत से लोग मानते हैं कि INSERTs के बाद VACUUMing की आवश्यकता नहीं हो सकती है।
• यह सुनिश्चित करने के लिए निगरानी करें कि तालिका pg_stat_user_tables को क्वेरी करके अत्यधिक सक्रिय तालिकाओं को नियमित रूप से VACUUMed किया जा रहा है।
• तालिका खंडों के भीतर फूला हुआ स्थान के आकार की पहचान करने के लिए pg_stattuple contrib मॉड्यूल का उपयोग करें।
• वैक्यूम पूर्ण उपयोगिता का उपयोग उत्पादन डेटाबेस सिस्टम पर नहीं किया जा सकता है। pg_reorg या pg_repack जैसे टूल का उपयोग करने पर विचार करें जो बिना लॉक के टेबल और इंडेक्स को ऑनलाइन पुनर्व्यवस्थित करने में मदद करेंगे।
• सुनिश्चित करें कि AUTOVACUUM प्रक्रिया व्यवसाय (उच्च ट्रैफ़िक) घंटों के दौरान अधिक समय तक चलती है।
• AUTOVACUUM प्रक्रियाओं के समय और अवधि को लॉग करने के लिए log_autovacuum_min_duration पैरामीटर सक्षम करें।
• महत्वपूर्ण रूप से, सुनिश्चित करें कि FILLFACTOR उच्च लेनदेन तालिका और अनुक्रमणिका पर इष्टतम मान के लिए कॉन्फ़िगर किया गया है।

अन्य I/O समस्याएं

डिस्क सॉर्टिंग

छँटाई करने वाली क्वेरी वास्तविक समय के उत्पादन डेटाबेस में एक और सामान्य घटना है और इनमें से अधिकांश को टाला नहीं जा सकता है। GROUP BY, ORDER BY, DISTINCT, CREATE INDEX, VACUUM FULL आदि जैसे क्लॉज का उपयोग करने वाली क्वेरी सॉर्टिंग करती हैं और सॉर्टिंग डिस्क पर हो सकती है। यदि अनुक्रमित स्तंभों के आधार पर चयन और छँटाई की जाती है तो स्मृति में छँटाई होती है। यह वह जगह है जहाँ समग्र-सूचकांक एक महत्वपूर्ण भूमिका निभाते हैं। इंडेक्स को आक्रामक रूप से मेमोरी में कैश किया जाता है। अन्यथा, यदि डिस्क पर डेटा को सॉर्ट करने की आवश्यकता होती है, तो प्रदर्शन काफी धीमा हो जाएगा।

मेमोरी में छँटाई सुनिश्चित करने के लिए, work_mem पैरामीटर का उपयोग किया जा सकता है। इस पैरामीटर को एक मान के लिए कॉन्फ़िगर किया जा सकता है जैसे कि संपूर्ण सॉर्टिंग मेमोरी में की जा सकती है। इस पैरामीटर का मुख्य लाभ यह है कि इसे postgresql.conf में कॉन्फ़िगर करने के अलावा, इसे सत्र स्तर, उपयोगकर्ता स्तर या डेटाबेस स्तर पर भी कॉन्फ़िगर किया जा सकता है। Work_mem का मान कितना होना चाहिए? कैसे पता करें कि कौन सी क्वेरी डिस्क सॉर्टिंग कर रही हैं? रीयल-टाइम प्रोडक्शन डेटाबेस पर डिस्क सॉर्टिंग करने वाले प्रश्नों की निगरानी कैसे करें?

उत्तर है - log_temp_files पैरामीटर को एक निश्चित मान पर कॉन्फ़िगर करें। मान बाइट्स में है, 0 का मान डिस्क सॉर्टिंग के कारण डिस्क पर उत्पन्न सभी अस्थायी फ़ाइलों (उनके आकार के साथ) को लॉग करता है। एक बार पैरामीटर कॉन्फ़िगर हो जाने पर, आप लॉग फ़ाइलों में निम्न संदेश देख सकेंगे

2018-06-07 22:48:02.358 IST [4219] LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp4219.0", size 200425472
2018-06-07 22:48:02.358 IST [4219] STATEMENT:  create index bid_idx on pgbench_accounts(bid);
2018-06-07 22:48:02.366 IST [4219] LOG:  duration: 6421.705 ms  statement: create index bid_idx on pgbench_accounts(bid);

उपरोक्त संदेश का अर्थ है कि CREATE INDEX क्वेरी डिस्क सॉर्टिंग कर रही थी और इसने 200425472 बाइट्स की एक फ़ाइल बनाई है जो 191+ एमबी है। इसका सटीक अर्थ यह है कि इस विशेष क्वेरी के लिए मेमोरी सॉर्टिंग करने के लिए वर्क_मेम पैरामीटर को 191+ एमबी या उससे ऊपर के लिए कॉन्फ़िगर किया जाना चाहिए।

ठीक है, एप्लिकेशन प्रश्नों के लिए, work_mem पैरामीटर केवल उपयोगकर्ता स्तर पर कॉन्फ़िगर किया जा सकता है। ऐसा करने से पहले, उपयोगकर्ता द्वारा डेटाबेस से किए जा रहे कनेक्शनों की संख्या और उस उपयोगकर्ता द्वारा निष्पादित किए जा रहे सॉर्टिंग प्रश्नों की संख्या से सावधान रहें। क्योंकि PostgreSQL प्रत्येक कनेक्शन में प्रत्येक प्रक्रिया (सॉर्टिंग प्रदर्शन) के लिए work_mem आवंटित करने का प्रयास करता है जो संभावित रूप से डेटाबेस सर्वर पर मेमोरी को भूखा कर सकता है।

डेटाबेस फ़ाइल-सिस्टम लेआउट

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

इसके लिए यहां कुछ टिप्स दिए गए हैं:

• सुनिश्चित करें कि डेटाबेस में कई टेबल स्पेस हैं, जिसमें टेबल और इंडेक्स लेनदेन दरों के आधार पर समूहीकृत हैं।
• टेबलस्पेस को संतुलित I/O के लिए एकाधिक डिस्क फ़ाइल सिस्टम में रखा जाना चाहिए। यह यह भी सुनिश्चित करेगा कि कई डिस्क में लेनदेन करने के लिए कई सीपीयू चलन में आ जाएं।
• एक उच्च लेनदेन डेटाबेस पर एक अलग डिस्क पर pg_xlog या pg_wal निर्देशिका रखने पर विचार करें।
• सुनिश्चित करें कि *_लागत पैरामीटर बुनियादी ढांचे के आधार पर कॉन्फ़िगर किए गए हैं
• सभी डिस्क में I/O आँकड़ों को समझने के लिए iostat, mpstat और अन्य I/O मॉनिटरिंग टूल का उपयोग करें और उसके अनुसार डेटाबेस ऑब्जेक्ट को आर्किटेक्ट/प्रबंधित करें।

बादल पर PostgreSQL

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

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

थोक डेटा लोड

डेटाबेस की दुनिया में ऑफलाइन बल्क डेटा लोडिंग ऑपरेशन काफी आम हैं। वे महत्वपूर्ण I/O लोड उत्पन्न कर सकते हैं, जो बदले में डेटा लोड प्रदर्शन को धीमा कर देता है। मैंने डीबीए के रूप में अपने अनुभव में ऐसी चुनौतियों का सामना किया है। अक्सर, डेटा लोड बहुत धीमा हो जाता है और इसे ट्यून करना पड़ता है। यहाँ कुछ युक्तियाँ हैं। ध्यान रहे, ये केवल ऑफ़लाइन डेटा लोडिंग संचालन पर लागू होते हैं और लाइव उत्पादन डेटाबेस पर डेटा लोड करने के लिए इन पर विचार नहीं किया जा सकता है।

• चूंकि अधिकांश डेटा लोड संचालन बंद व्यावसायिक घंटों के दौरान किए जाते हैं, इसलिए सुनिश्चित करें कि डेटा लोड के दौरान निम्नलिखित पैरामीटर कॉन्फ़िगर किए गए हैं -
  • चेकपॉइंट से संबंधित मानों को इतना बड़ा कॉन्फ़िगर करें कि चेकपॉइंट्स के कारण कोई प्रदर्शन समस्या न हो।
  • पूर्ण_पृष्ठ_लेखन बंद करें
  • वाल संग्रह बंद करें
  • सिंक्रोनस_प्रतिबद्ध पैरामीटर को "बंद" करने के लिए कॉन्फ़िगर करें
  • डेटा लोड के अधीन उन तालिकाओं के लिए ड्रॉप बाधाएं और अनुक्रमणिकाएं (बाधाएं और अनुक्रमणिका को बड़े वर्क_मेम मान के साथ डेटा लोड के बाद फिर से बनाया जा सकता है)
  • यदि आप CSV फ़ाइल से डेटा लोड कर रहे हैं, तो बड़ा मेंटेनेंस_वर्क_मेम आपको अच्छे परिणाम दे सकता है।
  • हालांकि एक महत्वपूर्ण प्रदर्शन लाभ होगा, fsync पैरामीटर को बंद न करें क्योंकि इससे डेटा भ्रष्टाचार हो सकता है।

क्लाउड प्रदर्शन विश्लेषण के लिए टिप्स

• pgbench का उपयोग करके संपूर्ण I/O विलंबता परीक्षण करें। मेरे अनुभव में, टीपीएस मूल्यांकन के हिस्से के रूप में डिस्क विलंबता जांच करते समय मेरे पास सामान्य प्रदर्शन परिणाम थे। कुछ सार्वजनिक क्लाउड इंस्टेंस पर कैशे प्रदर्शन के साथ समस्याएँ थीं। यह डेटाबेस के लिए चुने गए क्लाउड इंस्टेंस के लिए उपयुक्त विशिष्टताओं को चुनने में मदद करेगा।
• क्लाउड इंस्टेंस एक क्षेत्र से दूसरे क्षेत्र में अलग-अलग प्रदर्शन कर सकते हैं। एक क्षेत्र में विशिष्ट विशिष्टताओं के साथ एक क्लाउड इंस्टेंस दूसरे क्षेत्र में समान स्पेक्स वाले क्लाउड इंस्टेंस की तुलना में अलग-अलग प्रदर्शन परिणाम दे सकता है। विभिन्न क्षेत्रों में कई क्लाउड इंस्टेंस (एक ही क्लाउड विक्रेता के साथ सभी समान चश्मा) पर निष्पादित मेरे pgbench परीक्षणों ने मुझे उनमें से कुछ पर अलग-अलग परिणाम दिए। यह विशेष रूप से तब महत्वपूर्ण है जब आप क्लाउड में माइग्रेट कर रहे हों।
• क्लाउड पर क्वेरी प्रदर्शन के लिए एक अलग ट्यूनिंग दृष्टिकोण की आवश्यकता हो सकती है। स्वस्थ क्वेरी निष्पादन योजनाओं को सुनिश्चित करने के लिए डीबीए को *_कॉस्ट पैरामीटर का उपयोग करने की आवश्यकता होगी।

Tools to Monitor PostgreSQL Performance

There are various tools to monitor PostgreSQL performance. Let me highlight some of those.

• pg_top is a GREAT tool to monitor PostgreSQL database dynamically. I would highly recommend this tool for DBAs for various reasons. This tool has numerous advantages, let me list them out:
  • pg_top tool uses textual interface and is similar to Unix “top” utility.
  • Will clearly list out the processes and the hardware resources utilized. What excites me with this tool is that it will clearly tell you if a particular process is currently on DISK or CPU - in my view that’s excellent. DBAs can clearly pick the process running for longer time on the disk.
  • You can check the EXPLAIN PLAN of the top SQLs dynamically or instantly
  • You can also find out what Tables or Indexes are being scanned instantly
• Nagios is a popular monitoring tool for PostgreSQL which has both open-source and commercial versions. Open source version should suffice for monitoring. Custom Perl scripts can be built and plugged into Nagios module.
• Pgbadger is a popular tool which can be used to analyze PostgreSQL log files and generate performance reports. This report can be used to analyze the performance of checkpoints, disk sorting.
• Zabbix is another popular tool used for PostgreSQL monitoring.

ClusterControl is an up-and-coming management platform for PostgreSQL. Apart from monitoring, it also has functionality to deploy replication setups with load balancers, automatic failover, backup management, among others.