PostgreSQL धीमा चल रहा है? स्रोत तक पहुंचने के लिए टिप्स और ट्रिक्स

PostgreSQL डेटाबेस एडमिनिस्ट्रेटर के रूप में, बैकअप की जांच करने, DDL परिवर्तन लागू करने, लॉग्स में कोई गेम ब्रेकिंग ERROR नहीं है, और डेवलपर्स से घबराए हुए कॉल का जवाब देने की दैनिक अपेक्षाएं हैं, जिनकी रिपोर्ट सामान्य से दोगुनी लंबी चल रही है और वे दस मिनट में मीटिंग करें।

यहां तक ​​​​कि प्रबंधित डेटाबेस के स्वास्थ्य की अच्छी समझ के साथ, प्रदर्शन से संबंधित नए मामले और नए मुद्दे हमेशा सामने आएंगे और डेटाबेस कैसा महसूस करेगा। चाहे वह एक घबराया हुआ ईमेल हो, या "डेटाबेस धीमा लगता है" के लिए एक खुला टिकट हो, इस सामान्य कार्य का पालन आमतौर पर कुछ चरणों के साथ किया जा सकता है ताकि यह जांचा जा सके कि PostgreSQL में कोई समस्या है या नहीं, और वह समस्या क्या हो सकती है।

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

नोट: निष्पादित किए जाने वाले प्रश्नों को एक सुपरयुसर के रूप में किया जाना चाहिए, जैसे कि 'पोस्टग्रेज' या किसी डेटाबेस उपयोगकर्ता को सुपरयूजर अनुमतियां दी गई हैं। सीमित उपयोगकर्ताओं को या तो अस्वीकार कर दिया जाएगा या डेटा छोड़ दिया जाएगा।

चरण 0 - जानकारी एकत्र करना

जितना संभव हो उतना जानकारी प्राप्त करें जो कहता है कि डेटाबेस धीमा लगता है; विशिष्ट प्रश्न, जुड़े हुए एप्लिकेशन, प्रदर्शन में सुस्ती की समय-सीमा, आदि। वे जितनी अधिक जानकारी देंगे, समस्या को ढूंढना उतना ही आसान होगा।

चरण 1 - pg_stat_activity जांचें

अनुरोध कई अलग-अलग रूपों में आ सकता है, लेकिन अगर "धीमापन" सामान्य समस्या है, तो pg_stat_activity की जाँच करना यह समझने के लिए पहला कदम है कि क्या हो रहा है। pg_stat_activity व्यू (इस दृश्य में प्रत्येक कॉलम के लिए दस्तावेज़ यहां पाया जा सकता है) में क्लाइंट से डेटाबेस से प्रत्येक सर्वर प्रक्रिया/कनेक्शन के लिए एक पंक्ति होती है। इस दृष्टिकोण में कुछ उपयोगी जानकारी है जो मदद कर सकती है।

नोट: pg_stat_activity को समय के साथ संरचना को बदलने के लिए जाना जाता है, यह प्रस्तुत डेटा को परिष्कृत करता है। कॉलम की समझ भविष्य में आवश्यकतानुसार गतिशील रूप से क्वेरी बनाने में मदद करेगी।

pg_stat_activity में उल्लेखनीय कॉलम हैं:

1. क्वेरी:एक टेक्स्ट कॉलम जो उस क्वेरी को दिखाता है जिसे वर्तमान में निष्पादित किया जा रहा है, निष्पादित होने की प्रतीक्षा कर रहा है, या अंतिम बार निष्पादित किया गया था (राज्य के आधार पर)। इससे यह पता लगाने में मदद मिल सकती है कि डेवलपर किस क्वेरी/क्वेरी की रिपोर्ट कर रहा है जो धीरे-धीरे चल रही है।
2. client_addr:वह IP पता जिसके लिए यह कनेक्शन और क्वेरी उत्पन्न हुई है। अगर खाली (या नल) है, तो यह लोकलहोस्ट से उत्पन्न हुआ है।
3. बैकएंड_स्टार्ट, xact_start, query_start:ये तीनों एक टाइमस्टैम्प प्रदान करते हैं जब प्रत्येक क्रमशः शुरू होता है। बैकएंड_स्टार्ट यह दर्शाता है कि डेटाबेस से कनेक्शन कब स्थापित किया गया था, xact_start तब होता है जब वर्तमान लेनदेन शुरू होता है, और query_start तब होता है जब वर्तमान (या अंतिम) क्वेरी शुरू होती है।
4. राज्य:डेटाबेस से कनेक्शन की स्थिति। सक्रिय का अर्थ है कि यह वर्तमान में एक क्वेरी निष्पादित कर रहा है, 'निष्क्रिय' का अर्थ है कि यह ग्राहक से आगे इनपुट की प्रतीक्षा कर रहा है, 'लेनदेन में निष्क्रिय' का अर्थ है कि यह खुले लेनदेन के दौरान ग्राहक से आगे इनपुट की प्रतीक्षा कर रहा है। (अन्य भी हैं, हालांकि उनकी संभावना दुर्लभ है, अधिक जानकारी के लिए दस्तावेज़ीकरण देखें)।
5. डेटानाम:उस डेटाबेस का नाम जिससे कनेक्शन वर्तमान में जुड़ा हुआ है। एकाधिक डेटाबेस समूहों में, यह समस्याग्रस्त कनेक्शनों को अलग करने में मदद कर सकता है।
6. wait_event_type और Wait_event:जब कोई क्वेरी प्रतीक्षा नहीं कर रही होती है, तो ये कॉलम शून्य हो जाएंगे, लेकिन अगर यह प्रतीक्षा कर रहा है तो उनमें इस बारे में जानकारी होगी कि क्वेरी क्यों प्रतीक्षा कर रही है, और pg_locks की खोज से यह पता चल सकता है कि यह किस चीज़ का इंतज़ार कर रहा है। (PostgreSQL 9.5 और इससे पहले में केवल 'वेटिंग' नामक एक बूलियन कॉलम होता है, यदि प्रतीक्षा कर रहा है तो सत्य है, यदि नहीं तो गलत है।

1.1. क्‍या क्‍वेरी प्रतीक्षारत/अवरुद्ध है?

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

PostgreSQL 9.5 और पुराने संस्करण:

SELECT * FROM pg_stat_activity WHERE waiting = TRUE;

पोस्टग्रेएसक्यूएल 9.6:

SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL;

PostgreSQL 10 और बाद के संस्करण (?):

SELECT * FROM pg_stat_activity WHERE wait_event IS NOT NULL AND backend_type = 'client backend';

इस क्वेरी के परिणाम किसी ऐसे कनेक्शन को दिखाएंगे जो वर्तमान में किसी अन्य कनेक्शन पर प्रतीक्षा कर रहा है ताकि किसी आवश्यक संबंध पर लॉक जारी किया जा सके।

यदि क्वेरी किसी अन्य कनेक्शन द्वारा अवरुद्ध है, तो यह पता लगाने के कुछ तरीके हैं कि वे क्या हैं। PostgreSQL 9.6 और बाद के संस्करण में, फ़ंक्शन pg_blocking_pids () एक प्रक्रिया आईडी के इनपुट की अनुमति देता है जिसे अवरुद्ध किया जा रहा है, और यह प्रक्रिया आईडी की एक सरणी लौटाएगा जो इसे अवरुद्ध करने के लिए जिम्मेदार हैं।

PostgreSQL 9.6 और बाद के संस्करण:

SELECT * FROM pg_stat_activity 
WHERE pid IN (SELECT pg_blocking_pids(<pid of blocked query>));

PostgreSQL 9.5 और पुराने संस्करण:

SELECT blocked_locks.pid     AS blocked_pid,
         blocked_activity.usename  AS blocked_user,
         blocking_locks.pid     AS blocking_pid,
         blocking_activity.usename AS blocking_user,
         blocked_activity.query    AS blocked_statement,
         blocking_activity.query   AS current_statement_in_blocking_process
   FROM  pg_catalog.pg_locks         blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks         blocking_locks 
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
   WHERE NOT blocked_locks.GRANTED;

(पोस्टग्रेएसक्यूएल विकी से उपलब्ध)।

ये क्वेरीज़ किसी खास पीआईडी ​​को ब्लॉक करने वाली किसी भी चीज़ की ओर इशारा करेंगी। इसके साथ, अवरुद्ध क्वेरी या कनेक्शन को समाप्त करने या इसे चलने देने का निर्णय लिया जा सकता है।

चरण 2 - यदि प्रश्न चल रहे हैं, तो उनमें इतना समय क्यों लग रहा है?

2.1. क्या योजनाकार प्रश्नों को कुशलतापूर्वक चला रहा है?

यदि किसी प्रश्न (या प्रश्नों के समूह) की स्थिति 'सक्रिय' है, तो वह वास्तव में चल रही है। यदि पूरी क्वेरी pg_stat_activity में उपलब्ध नहीं है, तो इसे डेवलपर्स या पोस्टग्रेस्क्ल लॉग से प्राप्त करें और क्वेरी प्लानर की खोज शुरू करें।

EXPLAIN SELECT * FROM postgres_stats.table_stats t JOIN hosts h ON (t.host_id = h.host_id) WHERE logged_date >= '2018-02-01' AND logged_date < '2018-02-04' AND t.india_romeo = 569;
Nested Loop  (cost=0.280..1328182.030 rows=2127135 width=335)
  ->  Index Scan using six on victor_oscar echo  (cost=0.280..8.290 rows=1 width=71)
          Index Cond: (india_romeo = 569)
  ->  Append  (cost=0.000..1306902.390 rows=2127135 width=264)
        ->  Seq Scan on india_echo romeo  (cost=0.000..0.000 rows=1 width=264)
                Filter: ((logged_date >= '2018-02-01'::timestamp with time zone) AND (logged_date < '2018-02-04'::timestamp with time zone) AND (india_romeo = 569))
        ->  Seq Scan on juliet victor_echo  (cost=0.000..437153.700 rows=711789 width=264)
                Filter: ((logged_date >= '2018-02-01'::timestamp with time zone) AND (logged_date < '2018-02-04'::timestamp with time zone) AND (india_romeo = 569))
        ->  Seq Scan on india_papa quebec_bravo  (cost=0.000..434936.960 rows=700197 width=264)
                Filter: ((logged_date >= '2018-02-01'::timestamp with time zone) AND (logged_date < '2018-02-04'::timestamp with time zone) AND (india_romeo = 569))
        ->  Seq Scan on two oscar  (cost=0.000..434811.720 rows=715148 width=264)
                Filter: ((logged_date >= '2018-02-01'::timestamp with time zone) AND (logged_date < '2018-02-04'::timestamp with time zone) AND (india_romeo = 569))

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

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

2.2. क्या शामिल टेबल फूला हुआ है?

यदि क्वेरी प्लानर के बिना कुछ भी स्पष्ट बताए बिना प्रश्न अभी भी धीमा महसूस कर रहे हैं, तो इसमें शामिल तालिकाओं के स्वास्थ्य की जांच करने का समय है। क्या वे बहुत बड़े हैं? क्या वे फूले हुए हैं?

SELECT n_live_tup, n_dead_tup from pg_stat_user_tables where relname = ‘mytable’;
n_live_tup  | n_dead_tup
------------+------------
      15677 |    8275431
(1 row)

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

चरण 3 - लॉग की जांच करें

अगर समस्या अभी भी नहीं मिलती है, तो किसी भी सुराग के लिए लॉग की जांच करें।

घातक / त्रुटि संदेश:

उन संदेशों की तलाश करें जो समस्याएँ पैदा कर सकते हैं, जैसे कि गतिरोध या लॉक प्राप्त करने के लिए लंबा प्रतीक्षा समय।

चेकपॉइंट

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

चरण 4 - होस्ट सिस्टम का स्वास्थ्य क्या है?

यदि डेटाबेस में ही कोई सुराग नहीं है, तो शायद होस्ट स्वयं अतिभारित है या समस्याएँ हैं। ओवरलोडेड IO चैनल से लेकर डिस्क तक, मेमोरी ओवरफ्लो से स्वैप तक, या यहां तक ​​​​कि एक फेलिंग ड्राइव से कुछ भी, इनमें से कोई भी समस्या हमारे द्वारा पहले देखी गई किसी भी चीज़ से स्पष्ट नहीं होगी। यह मानते हुए कि डेटाबेस *nix आधारित ऑपरेटिंग सिस्टम पर चल रहा है, यहां कुछ चीजें हैं जो मदद कर सकती हैं।

4.1. सिस्टम लोड

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

load average: 3.43, 5.25, 4.85

4.2. सिस्टम मेमोरी और स्वैप

'निःशुल्क' का उपयोग करते हुए, यह देखने के लिए जांचें कि क्या SWAP का उपयोग किया गया है। PostgreSQL डेटाबेस वातावरण में SWAP के लिए अतिप्रवाह मेमोरी प्रदर्शन के लिए बेहद खराब है, और कई DBA डेटाबेस होस्ट से SWAP को भी समाप्त कर देंगे, क्योंकि 'स्मृति से बाहर' त्रुटि कई लोगों के लिए एक सुस्त सिस्टम की तुलना में अधिक बेहतर है।

यदि SWAP का उपयोग किया जा रहा है, तो सिस्टम का रीबूट इसे साफ़ कर देगा, और PostgreSQL के लिए कुल सिस्टम मेमोरी बढ़ाना या मेमोरी उपयोग को फिर से कॉन्फ़िगर करना (जैसे कि शेयर्ड_बफ़र्स या वर्क_मेम को कम करना) क्रम में हो सकता है।

[[email protected] ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7986         225        1297          12        6462        7473
Swap:          7987        2048        5939

4.3. डिस्क एक्सेस

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

'iostat' या 'iotop' जैसे टूल यह पता लगाने में मदद कर सकते हैं कि डिस्क में कोई अड़चन है या नहीं और यह कहां से आ रहा है।

4.4. लॉग जांचें

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

चरण 5 - कुछ अभी भी समझ में नहीं आ रहा है?

यहां तक ​​​​कि सबसे अनुभवी प्रशासक भी कुछ नया करेंगे जिसका कोई मतलब नहीं है। यहीं से वैश्विक PostgreSQL समुदाय मदद के लिए आ सकता है। चरण #0 की तरह, समुदाय को जितनी अधिक स्पष्ट जानकारी दी जाती है, वे उतनी ही आसानी से मदद कर सकते हैं।

5.1. PostgreSQL मेलिंग सूचियाँ

चूंकि PostgreSQL को ओपन सोर्स समुदाय द्वारा विकसित और प्रबंधित किया गया है, ऐसे हजारों लोग हैं जो मेलिंग सूचियों के माध्यम से सुविधाओं, त्रुटियों और प्रदर्शन मुद्दों सहित अनगिनत विषयों पर चर्चा करने के लिए बात करते हैं। मेलिंग सूचियां यहां पाई जा सकती हैं, जिसमें pgsql-admin और pgsql-performance सबसे महत्वपूर्ण हैं जो प्रदर्शन संबंधी समस्याओं में मदद की तलाश में हैं।

5.2. आईआरसी

फ़्रीनोड दुनिया भर में डेवलपर्स और प्रशासकों के साथ कई पोस्टग्रेएसक्यूएल चैनलों को होस्ट करता है, और यह पता लगाने के लिए एक सहायक व्यक्ति को ढूंढना मुश्किल नहीं है कि समस्याएँ कहाँ से आ रही हैं। अधिक जानकारी PostgreSQL IRC पृष्ठ पर पाई जा सकती है।