PostgreSQL में मॉनिटर करने के लिए मुख्य चीजें - आपके कार्यभार का विश्लेषण

PostgreSQL में मॉनिटर करने के लिए मुख्य चीजें - आपके कार्यभार का विश्लेषण करना

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

निगरानी हमें समस्याओं की पहचान करने और उन समस्याओं पर प्रतिक्रिया करने में मदद करती है जो कई क्षेत्रों से संबंधित हैं जैसे:

• इन्फ्रास्ट्रक्चर/हार्डवेयर (भौतिक या आभासी)
• नेटवर्क
• भंडारण
• सिस्टम सॉफ़्टवेयर
• एप्लिकेशन सॉफ़्टवेयर
• सुरक्षा

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

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

PostgreSQL डेटा एकत्र करने और विश्लेषण करने में हमारी सहायता करने के लिए कई आउट ऑफ़ द बॉक्स टूल प्रदान करता है। इसके अलावा, इसकी एक्स्टेंसिबिलिटी के कारण, यह नए मॉड्यूल को कोर सिस्टम में विकसित करने के साधन प्रदान करता है।

PostgreSQL उस सिस्टम (हार्डवेयर और सॉफ्टवेयर) पर अत्यधिक निर्भर है जिस पर वह चलता है। अगर सिस्टम के बाकी हिस्सों में किसी भी महत्वपूर्ण घटक में कोई समस्या है तो हम पोस्टग्रेएसक्यूएल सर्वर के अच्छे प्रदर्शन की उम्मीद नहीं कर सकते हैं। तो PostgreSQL DBA की भूमिका sysadmin की भूमिका के साथ ओवरलैप हो जाती है। नीचे, जैसा कि हम जांच करते हैं कि PostgreSQL निगरानी में क्या देखना है, हम सिस्टम-निर्भर चर और मीट्रिक दोनों के साथ-साथ PostgreSQL के विशिष्ट आंकड़ों का सामना करेंगे।

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

सिस्टम मॉनिटरिंग बेसिक्स

सिस्टम निगरानी में महत्वपूर्ण चर हैं:

• सीपीयू उपयोग
• नेटवर्क उपयोग
• डिस्क स्थान / डिस्क उपयोग
• रैम का उपयोग
• डिस्क आईओपीएस
• स्पेस उपयोग बदलें
• नेटवर्क त्रुटियां

यहां दो बार pgbench -c 64 -t 1000 pgbench चलाते समय pg_stat_database और pg_stat_bgwriter (जिसे हम निम्नलिखित पैराग्राफ में कवर करेंगे) से आने वाले कुछ महत्वपूर्ण PostgreSQL चर के लिए ग्राफ़ दिखाने वाले ClusterControl का एक उदाहरण है:

हमने देखा है कि हमारे पास पहले रन में ब्लॉक-रीड पर एक चोटी है, लेकिन दूसरे रन के दौरान हम शून्य के करीब पहुंच जाते हैं क्योंकि सभी ब्लॉक शेयर्ड_बफ़र्स में पाए जाते हैं।

रुचि के अन्य चर हैं पेजिंग गतिविधि, इंटरप्ट, संदर्भ स्विच, अन्य। Linux/BSDs और यूनिक्स या यूनिक्स जैसी प्रणालियों में उपयोग करने के लिए ढेर सारे उपकरण हैं। उनमें से कुछ हैं:

• ps:चल रही प्रक्रियाओं की सूची के लिए

• टॉप/एचटॉप/सिस्टैट:सिस्टम (सीपीयू/मेमोरी) यूटिलाइजेशन मॉनिटरिंग के लिए

• vmstat:सामान्य सिस्टम गतिविधि (वर्चुअल मेमोरी सहित) निगरानी के लिए

• iostat/iotop/top -mio:IO निगरानी के लिए

• ntop:नेटवर्क मॉनिटरिंग के लिए

यहां एक क्वेरी के दौरान फ्रीबीएसडी बॉक्स पर vmstat का एक उदाहरण दिया गया है जिसके लिए कुछ डिस्क पढ़ने और कुछ गणना की भी आवश्यकता होती है:

procs  memory      page                         disks      faults          cpu
r b w  avm   fre   flt   re  pi  po   fr    sr  ad0 ad1  in     sy    cs us sy id
0 0 0  98G  666M   421   0   0   0   170  2281    5  0  538   6361  2593  1  1 97
0 0 0  98G  665M   141   0   0   0     0  2288   13  0  622  11055  3748  3  2 94
--- query starts here ---
0 0 0  98G  608M   622   0   0   0   166  2287 1072  0 1883  16496 12202  3  2 94
0 0 0  98G  394M   101   0   0   0     2  2284 4578  0 5815  24236 39205  3  5 92
2 0 0  98G  224M  4861   0   0   0  1711  2287 3588  0 4806  24370 31504  4  6 91
0 0 0  98G  546M    84 188   0   0 39052 41183 2832  0 4017  26007 27131  5  7 88
2 0 0  98G  469M   418   0   0   1   397  2289 1590  0 2356  11789 15030  2  2 96
0 0 0  98G  339M   112   0   0   0   348  2300 2852  0 3858  17250 25249  3  4 93
--- query ends here ---
1 0 0  98G  332M  1622   0   0   0   213  2289    4  0  531   6929  2502  3  2 95

क्वेरी को दोहराते हुए हम डिस्क गतिविधि में कोई नया विस्फोट नहीं देखेंगे क्योंकि डिस्क के वे ब्लॉक पहले से ही ओएस के कैश में होंगे। हालाँकि, PostgreSQL DBA को पूरी तरह से समझने में सक्षम होना चाहिए कि अंतर्निहित बुनियादी ढांचे में क्या हो रहा है जहाँ डेटाबेस चलता है, अधिक जटिल सिस्टम मॉनिटरिंग आमतौर पर sysadmin के लिए एक काम है, क्योंकि यह अपने आप में एक बड़ा विषय है।

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

PostgreSQL मॉनिटरिंग बेसिक्स

PostgreSQL निगरानी में महत्वपूर्ण चर हैं:

• बफ़र कैश प्रदर्शन (कैश हिट बनाम डिस्क रीड)
• कमिट की संख्या
• कनेक्शन की संख्या
• सत्रों की संख्या
• चेकपॉइंट और बीजीराइटर आँकड़े
• वैक्यूम
• ताले
• प्रतिकृति
• और अंतिम लेकिन निश्चित रूप से कम से कम, क्वेरीज़

डेटा संग्रह करने के लिए निगरानी सेटअप में आम तौर पर दो तरीके होते हैं:

• लॉग के माध्यम से डेटा प्राप्त करने के लिए
• PostgreSQL सिस्टम को क्वेरी करके डेटा प्राप्त करने के लिए

लॉग फ़ाइल-आधारित डेटा अधिग्रहण (ठीक से कॉन्फ़िगर किया गया) PostgreSQL लॉग पर निर्भर करता है। हम डेटा के "ऑफ-लाइन" प्रसंस्करण के लिए इस तरह के लॉगिंग का उपयोग कर सकते हैं। लॉग फ़ाइल-आधारित निगरानी सबसे उपयुक्त है जब PostgreSQL सर्वर के लिए न्यूनतम ओवरहेड की आवश्यकता होती है और जब हम लाइव डेटा या लाइव अलर्ट प्राप्त करने की परवाह नहीं करते हैं (हालांकि लॉग फ़ाइल डेटा का उपयोग करके लाइव मॉनिटरिंग संभव हो सकती है जैसे पोस्टग्रेस्क्ल लॉग को syslog पर निर्देशित करना और फिर लॉग प्रोसेसिंग के लिए समर्पित किसी अन्य सर्वर पर syslog स्ट्रीमिंग)।

PostgreSQL सांख्यिकी संग्राहक

PostgreSQL सांख्यिकी कलेक्टर सबसिस्टम के माध्यम से आसानी से उपलब्ध विचारों और कार्यों का एक समृद्ध सेट प्रदान करता है। फिर से उन डेटा को दो श्रेणियों में बांटा गया है:

• इस समय सिस्टम क्या कर रहा है, इसकी गतिशील जानकारी।
• सांख्यिकी संग्राहक उपप्रणाली के अंतिम रीसेट के बाद से संचित आंकड़े।

गतिशील आंकड़े दृश्य प्रति प्रक्रिया वर्तमान गतिविधि (pg_stat_activity), भौतिक प्रतिकृति की स्थिति (pg_stat_replication), भौतिक स्टैंडबाय की स्थिति (pg_stat_wal_receiver) या तार्किक (pg_stat_subscription), ssl (pg_stat_ssl) और वैक्यूम (pg_stat_progress_vacuum) के बारे में जानकारी प्रदान करें।

संग्रहित आंकड़े दृश्य महत्वपूर्ण पृष्ठभूमि प्रक्रियाओं के बारे में जानकारी प्रदान करें जैसे कि वाल आर्काइवर, bgwriter, और डेटाबेस ऑब्जेक्ट:उपयोगकर्ता या सिस्टम टेबल, इंडेक्स, अनुक्रम और फ़ंक्शन के साथ-साथ स्वयं डेटाबेस।

अब तक यह बिल्कुल स्पष्ट हो जाना चाहिए कि निगरानी से संबंधित डेटा को वर्गीकृत करने के कई तरीके हैं:

• स्रोत द्वारा:
  • सिस्टम टूल (ps, top, iotop, etc)
  • PgSQL लॉग फ़ाइल
  • डेटाबेस
    • गतिशील
    • संग्रहित
• विशिष्ट डेटाबेस ऑपरेशन द्वारा:
  • बफ़र कैश
  • प्रतिबद्ध करता है
  • प्रश्न
  • सत्र
  • चौकियों
  • आदि

इस लेख को पढ़ने और प्रस्तुत धारणाओं, अवधारणाओं और शर्तों के साथ प्रयोग करने के बाद, आप सभी संभावित संयोजनों के साथ एक 2D मैट्रिक्स बनाने में सक्षम होना चाहिए। एक उदाहरण के रूप में, विशिष्ट पोस्टग्रेएसक्यूएल गतिविधि (एसक्यूएल कमांड) का उपयोग करके पाया जा सकता है:पीएस या टॉप (सिस्टम यूटिलिटीज), पोस्टग्रेएसक्यूएल लॉग फाइल, pg_stat_activity (डायनेमिक व्यू), लेकिन pg_stat_statements का उपयोग करके कॉन्ट्रिब में पाया गया एक्सटेंशन (एकत्रित आंकड़े दृश्य) . इसी तरह, ताले के बारे में जानकारी PostgreSQL लॉग फ़ाइलों में पाई जा सकती है, pg_locks और pg_stat_activity (ठीक नीचे प्रस्तुत) wait_event . का उपयोग करके और wait_event_type . इस वजह से, एक आयामी रैखिक फैशन में निगरानी के विशाल क्षेत्र को कवर करना मुश्किल है, और लेखक इस वजह से पाठक को भ्रम पैदा करने का जोखिम उठाता है। इससे बचने के लिए हम आधिकारिक दस्तावेज के पाठ्यक्रम का पालन करके और आवश्यकतानुसार संबंधित जानकारी जोड़कर निगरानी को कवर करेंगे।

गतिशील सांख्यिकी दृश्य

pg_stat_activity का उपयोग करना हम विभिन्न बैकएंड प्रक्रियाओं द्वारा यह देखने में सक्षम हैं कि वर्तमान गतिविधि क्या है। उदाहरण के लिए यदि हम निम्न क्वेरी को लगभग 3M पंक्तियों वाले तालिका भागों पर चलाते हैं:

testdb=# \d parts
                         Table "public.parts"
   Column   |          Type          | Collation | Nullable | Default
------------+------------------------+-----------+----------+---------
 id         | integer                |           |          |
 partno     | character varying(20)  |           |          |
 partname   | character varying(80)  |           |          |
 partdescr  | text                   |           |          |
 machine_id | integer                |           |          |
 parttype   | character varying(100) |           |          |
 date_added | date                   |           |          |

और निम्न क्वेरी को चलाने देता है, जिसे पूरा करने के लिए कुछ सेकंड की आवश्यकता होती है:

testdb=# select avg(age(date_added)) FROM parts;

एक नया टर्मिनल खोलकर और निम्न क्वेरी चलाकर, जबकि पिछला अभी भी चल रहा है, हम प्राप्त करते हैं:

testdb=# select pid,usename,application_name,client_addr,backend_start,xact_start,query_start,state,backend_xid,backend_xmin,query,backend_type from pg_stat_activity where datid=411547739 and usename ='achix' and state='active';
-[ RECORD 1 ]----+----------------------------------------
pid              | 21305
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.833677+02
xact_start       | 2018-03-02 18:04:35.832564+02
query_start      | 2018-03-02 18:04:35.832564+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker
-[ RECORD 2 ]----+----------------------------------------
pid              | 21187
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:02:06.834787+02
xact_start       | 2018-03-02 18:04:35.826065+02
query_start      | 2018-03-02 18:04:35.826065+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | client backend
-[ RECORD 3 ]----+----------------------------------------
pid              | 21306
usename          | achix
application_name | psql
client_addr      |
backend_start    | 2018-03-02 18:04:35.837829+02
xact_start       | 2018-03-02 18:04:35.836707+02
query_start      | 2018-03-02 18:04:35.836707+02
state            | active
backend_xid      |
backend_xmin     | 438132638
query            | select avg(age(date_added)) FROM parts;
backend_type     | background worker

pg_stat_activity व्यू हमें बैकएंड प्रक्रिया, उपयोगकर्ता, क्लाइंट, लेन-देन, क्वेरी, राज्य के साथ-साथ क्वेरी की प्रतीक्षा स्थिति के बारे में एक व्यापक जानकारी के बारे में जानकारी देता है।

लेकिन 3 पंक्तियाँ क्यों? संस्करणों में>=9.6, यदि कोई क्वेरी समानांतर में चलाई जा सकती है, या उसके कुछ हिस्सों को समानांतर में चलाया जा सकता है, और अनुकूलक को लगता है कि समानांतर निष्पादन सबसे तेज़ रणनीति है, तो यह एक इकट्ठा बनाता है या मर्ज करें नोड, और फिर अधिकतम max_parallel_workers_per_gather . पर अनुरोध करें पृष्ठभूमि कार्यकर्ता प्रक्रियाएं, जो डिफ़ॉल्ट रूप से 2 है, इसलिए 3 पंक्तियाँ जो हम ऊपर के आउटपुट में देखते हैं। हम बैकएंड_टाइप . का उपयोग करके क्लाइंट बैकएंड प्रक्रिया को बैकग्राउंड वर्कर से अलग बता सकते हैं कॉलम। pg_stat_activity दृश्य को सक्षम करने के लिए आपको यह सुनिश्चित करना होगा कि सिस्टम कॉन्फ़िगरेशन पैरामीटर track_activities चालू है। pg_stat_activity वेट_इवेंट_टाइप और वेट_इवेंट कॉलम के उपयोग द्वारा अवरुद्ध प्रश्नों को निर्धारित करने के लिए समृद्ध जानकारी प्रदान करती है।

कथनों पर नज़र रखने का एक अधिक परिष्कृत तरीका pg_stat_statements . के माध्यम से है योगदान विस्तार, पहले उल्लेख किया गया। हाल ही के लिनक्स सिस्टम (उबंटू 17.10, पोस्टग्रेएसक्यूएल 9.6) पर, इसे काफी आसानी से स्थापित किया जा सकता है:

testdb=# create extension pg_stat_statements ;
CREATE EXTENSION
testdb=# alter system set shared_preload_libraries TO 'pg_stat_statements';
ALTER SYSTEM
testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# \d pg_stat_statements

आइए 100000 पंक्तियों के साथ एक तालिका बनाएं, और फिर pg_stat_statements को रीसेट करें, PostgreSQL सर्वर को पुनरारंभ करें, (अभी भी ठंडे) सिस्टम पर इस तालिका पर एक चयन करें, और फिर चयन के लिए pg_stat_statements की सामग्री देखें:

testdb=# select 'descr '||gs as descr,gs as id into medtable from  generate_series(1,100000) as gs;
SELECT 100000
testdb=# select pg_stat_statements_reset();
 pg_stat_statements_reset
--------------------------
 
(1 row)

testdb=# \q
[email protected]:~$ sudo systemctl restart postgresql
[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
               0 |              541
(1 row)

testdb=#

अब एक बार फिर से * का चयन करें और फिर इस क्वेरी के लिए pg_stat_statements की सामग्री में फिर से देखें:

[email protected]:~$ psql testdb -c 'select * from medtable' > /dev/null
[email protected]:~$ psql testdb
psql (9.6.7)
Type "help" for help.

testdb=# select shared_blks_hit,shared_blks_read from pg_stat_statements where query like '%select%from%medtable%';
 shared_blks_hit | shared_blks_read
-----------------+------------------
             541 |              541
(1 row)

इसलिए, दूसरी बार चयन कथन PostgreSQL साझा बफ़र्स में सभी आवश्यक ब्लॉक ढूंढता है, और pg_stat_statements shared_blks_hit के माध्यम से इसकी रिपोर्ट करता है . pg_stat_statements एक स्टेटमेंट की कॉल की कुल संख्या, Total_time, min_time, max_time और mean_time के बारे में जानकारी प्रदान करता है, जो आपके सिस्टम के वर्कलोड का विश्लेषण करने का प्रयास करते समय बेहद मददगार हो सकता है। बहुत बार चलने वाली धीमी क्वेरी पर तत्काल ध्यान देने की आवश्यकता है। इसी तरह, लगातार कम हिट दरें shared_buffers . की समीक्षा करने की आवश्यकता का संकेत दे सकती हैं सेटिंग।

pg_stat_replication प्रत्येक wal_sender के लिए प्रतिकृति की वर्तमान स्थिति के बारे में जानकारी प्रदान करता है। मान लीजिए कि हमने अपने प्राथमिक और एक हॉट स्टैंडबाय के साथ एक साधारण प्रतिकृति टोपोलॉजी की स्थापना की है, तो हम प्राथमिक पर pg_stat_replication क्वेरी कर सकते हैं (स्टैंडबाय पर ऐसा करने से कोई परिणाम नहीं मिलेगा जब तक कि हमारे पास कैस्केडिंग प्रतिकृति सेटअप न हो और यह विशिष्ट स्टैंडबाय अपस्ट्रीम के रूप में कार्य करता है अन्य डाउनस्ट्रीम स्टैंडबाय के लिए) प्रतिकृति की वर्तमान स्थिति देखने के लिए:

testdb=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/3029DB8
write_lsn        | 0/3029DB8
flush_lsn        | 0/3029DB8
replay_lsn       | 0/3029DB8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 0
sync_state       | async

4 कॉलम sent_lsn , write_lsn , flush_lsn , replay_lsn हमें दूरस्थ स्टैंडबाय पर प्रतिकृति प्रक्रिया के प्रत्येक चरण में सटीक WAL स्थिति बताएं। फिर हम एक कमांड के साथ प्राइमरी पर कुछ भारी ट्रैफिक बनाते हैं जैसे:

testdb=# insert into foo(descr) select 'descr ' || gs from generate_series(1,10000000) gs;

और pg_stat_replication को फिर से देखें:

postgres=# select * from pg_stat_replication ;
-[ RECORD 1 ]----+------------------------------
pid              | 1317
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 10.0.2.2
client_hostname  |
client_port      | 48192
backend_start    | 2018-03-03 11:59:21.315524+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/D5E0000
write_lsn        | 0/D560000
flush_lsn        | 0/D4E0000
replay_lsn       | 0/C5FF0A0
write_lag        | 00:00:04.166639
flush_lag        | 00:00:04.180333
replay_lag       | 00:00:04.614416
sync_priority    | 0
sync_state       | async

अब हम देखते हैं कि हमारे पास sent_lsn में दर्शाए गए प्राथमिक और स्टैंडबाय के बीच विलंब है , write_lsn , flush_lsn , replay_lsn मूल्य। चूंकि PgSQL 10.0 pg_stat_replication हाल ही में स्थानीय रूप से फ़्लश किए गए WAL और दूरस्थ रूप से लिखे जाने, फ़्लश किए जाने और फिर से चलाने में लगने वाले समय के बीच अंतराल को भी दर्शाता है। उन 3 कॉलम में नल देखने का मतलब है कि प्राथमिक और स्टैंडबाय सिंक में हैं।

pg_stat_replication . के बराबर स्टैंडबाय साइड पर कहा जाता है:pg_stat_wal_receiver:

testdb=# select * from pg_stat_wal_receiver ;
-[ RECORD 1 ]---------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
pid                   | 17867
status                | streaming
receive_start_lsn     | 0/F000000
receive_start_tli     | 1
received_lsn          | 0/3163F210
received_tli          | 1
last_msg_send_time    | 2018-03-03 13:32:42.516551+00
last_msg_receipt_time | 2018-03-03 13:33:28.644394+00
latest_end_lsn        | 0/3163F210
latest_end_time       | 2018-03-03 13:32:42.516551+00
slot_name             | fbsdclone
conninfo              | user=postgres passfile=/usr/local/var/lib/pgsql/.pgpass dbname=replication host=10.0.2.2 port=20432 fallback_application_name=walreceiver sslmode=disable sslcompression=1 target_session_attrs=any

testdb=#

जब कोई गतिविधि नहीं होती है, और स्टैंडबाय ने सब कुछ फिर से चलाया है तो latest_end_lsn sent_lsn . के बराबर होना चाहिए प्राथमिक (और सभी मध्यवर्ती लॉग अनुक्रम संख्या) पर।

भौतिक प्रतिकृति के समान, तार्किक प्रतिकृति के मामले में, जहां प्राथमिक की भूमिका प्रकाशक द्वारा ली जाती है, और स्टैंडबाय की भूमिका ग्राहक द्वारा ली जाती है, स्वाभाविक रूप से pg_stat_wal_receiver की भूमिका होती है। pg_stat_subscription . द्वारा लिया जाता है . हम pg_stat_subscription के बारे में पूछ सकते हैं इस प्रकार है:

testdb=# select * from pg_stat_subscription ;
-[ RECORD 1 ]---------+------------------------------
subid                 | 24615
subname               | alltables_sub
pid                   | 1132
relid                 |
received_lsn          | 0/33005498
last_msg_send_time    | 2018-03-03 17:05:36.004545+00
last_msg_receipt_time | 2018-03-03 17:05:35.990659+00
latest_end_lsn        | 0/33005498
latest_end_time       | 2018-03-03 17:05:36.004545+00

ध्यान दें कि प्रकाशक की ओर से, संबंधित दृश्य वही है जो भौतिक प्रतिकृति के मामले में है:pg_stat_replication ।

संग्रहित आंकड़े दृश्य

pg_stat_archiver दृश्य में एक पंक्ति है जो वाल संग्रहकर्ता के बारे में जानकारी देती है। नियमित अंतराल पर इस पंक्ति का स्नैपशॉट रखने से आप उन अंतरालों के बीच WAL ट्रैफ़िक के आकार की गणना कर सकते हैं। साथ ही यह WAL फ़ाइलों को संग्रहीत करते समय विफलताओं के बारे में जानकारी देता है।

pg_stat_bgwriter व्यू के व्यवहार के बारे में बहुत महत्वपूर्ण जानकारी देता है:

• जांच की चौकी
• पृष्ठभूमि लेखक
• (क्लाइंट सर्विंग) बैकएंड करता है

चूंकि यह दृश्य अंतिम रीसेट के बाद से संचित डेटा देता है pg_stat_bgwriter के आवधिक स्नैपशॉट के साथ एक और टाइमस्टैम्प तालिका बनाना बहुत उपयोगी है , ताकि दो स्नैपशॉट के बीच एक वृद्धिशील परिप्रेक्ष्य प्राप्त करना आसान हो जाए। ट्यूनिंग एक विज्ञान (या जादू) है, और इसमें अच्छे परिणाम प्राप्त करने के लिए व्यापक लॉगिंग और निगरानी के साथ-साथ अंतर्निहित अवधारणाओं और पोस्टग्रेएसक्यूएल इंटर्नल की स्पष्ट समझ की आवश्यकता होती है, और यह दृश्य वह जगह है जहां से शुरू करना है, जैसे चीजों की तलाश में:

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

Pg_stat_[user|sys|all]_tables

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

Pg_stat_[user|sys|all]_indexes

यहां सिस्टम व्यक्तिगत इंडेक्स उपयोग के बारे में जानकारी संग्रहीत और दिखाता है। एक बात का ध्यान रखें कि idx_tup_read idx_tup_fetch की तुलना में अधिक सटीक है। कम idx_scan . के साथ गैर PK/गैर अद्वितीय इंडेक्स हटाने के लिए विचार किया जाना चाहिए, क्योंकि वे केवल HOT अपडेट में बाधा डालते हैं। जैसा कि पिछले ब्लॉग में बताया गया है, ओवर-इंडेक्सिंग से बचना चाहिए, इंडेक्सिंग की कीमत चुकानी पड़ती है।

Pg_statio_[user|sys|all]_tables

उन विचारों में हम टेबल हीप रीड्स, इंडेक्स रीड्स और टोस्ट रीड्स के संबंध में कैश के प्रदर्शन के बारे में जानकारी पा सकते हैं। हिट के प्रतिशत और सभी तालिकाओं में हिट के वितरण की गणना करने के लिए एक सरल क्वेरी होगी:

with statioqry as (select relid,heap_blks_hit,heap_blks_read,row_number() OVER (ORDER BY 100.0*heap_blks_hit::numeric/(heap_blks_hit+heap_blks_read) DESC),COUNT(*) OVER () from pg_statio_user_tables where heap_blks_hit+heap_blks_read >0)
select relid,row_number,100.0*heap_blks_hit::float8/(heap_blks_hit+heap_blks_read) as "heap block hits %", 100.0 * row_number::real/count as "In top %" from statioqry order by row_number;
   relid   | row_number | heap block hits % |     In top %      
-----------+------------+-------------------+-------------------
     16599 |          1 |  99.9993058404502 | 0.373134328358209
     18353 |          2 |  99.9992251425738 | 0.746268656716418
     18338 |          3 |    99.99917566565 |  1.11940298507463
     17269 |          4 |  99.9990617323798 |  1.49253731343284
     18062 |          5 |  99.9988021889522 |  1.86567164179104
     18075 |          6 |  99.9985334109273 |  2.23880597014925
     18365 |          7 |  99.9968070500335 |  2.61194029850746
………..
     18904 |        127 |  97.2972972972973 |  47.3880597014925
     18801 |        128 |  97.1631205673759 |  47.7611940298507
     16851 |        129 |  97.1428571428571 |   48.134328358209
     17321 |        130 |  97.0043198249512 |  48.5074626865672
     17136 |        131 |                97 |  48.8805970149254
     17719 |        132 |  96.9791612263018 |  49.2537313432836
     17688 |        133 |   96.969696969697 |  49.6268656716418
     18872 |        134 |  96.9333333333333 |                50
     17312 |        135 |  96.8181818181818 |  50.3731343283582
……………..
     17829 |        220 |  60.2721026527734 |   82.089552238806
     17332 |        221 |  60.0276625172891 |  82.4626865671642
     18493 |        222 |                60 |  82.8358208955224
     17757 |        223 |  59.7222222222222 |  83.2089552238806
     17586 |        224 |  59.4827586206897 |  83.5820895522388

यह हमें बताता है कि कम से कम 50% तालिकाओं की हिट दर 96.93% से अधिक है, और 83.5% तालिकाओं की हिट दर 59.4% से बेहतर है

Pg_statio_[user|sys|all]_indexes

इस दृश्य में इंडेक्स के लिए ब्लॉक रीड/हिट जानकारी है।

Pg_stat_database

इस दृश्य में प्रति डेटाबेस एक पंक्ति है। यह संपूर्ण डेटाबेस (ब्लॉक रीड, ब्लॉक हिट, टुप्स पर जानकारी), संपूर्ण डेटाबेस के लिए प्रासंगिक कुछ जानकारी (कुल xactions, अस्थायी फ़ाइलें, संघर्ष, डेडक्लॉक, पढ़ने / लिखने का समय) के लिए पिछले विचारों की कुछ जानकारी दिखाता है। , और अंत में वर्तमान बैकएंड की संख्या।

यहां देखने के लिए चीजें blks_hit/(blks_hit + blks_read) का अनुपात हैं :मान जितना अधिक होगा, सिस्टम के I/O के लिए उतना ही बेहतर होगा। हालाँकि, डिस्क रीड के लिए मिसेज़ का हिसाब जरूरी नहीं होना चाहिए क्योंकि हो सकता है कि वे OS के फाइलस कैश द्वारा बहुत अच्छी तरह से परोसे गए हों।

ऊपर बताए गए अन्य एकत्रित आंकड़ों के दृश्य के समान, किसी को pg_stat_database का टाइमस्टैम्प्ड संस्करण बनाना चाहिए लगातार दो स्नैपशॉट के बीच अंतर देखें और देखें:

• क्या रोलबैक की संख्या बढ़ रही है?
• या प्रतिबद्ध क्रियाओं की संख्या?
• क्या हम कल की तुलना में अधिक संघर्ष कर रहे हैं (यह स्टैंडबाय पर लागू होता है)?
• क्या हमारे पास असामान्य रूप से उच्च संख्या में गतिरोध हैं?

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

ताला

पोस्टग्रेएसक्यूएल में लॉकिंग एक बहुत ही महत्वपूर्ण विषय है और इसके अपने ब्लॉग का हकदार है। फिर भी बुनियादी तालों की निगरानी उसी तरह से की जानी चाहिए जैसे ऊपर प्रस्तुत निगरानी के अन्य पहलुओं में की जाती है। pg_locks दृश्य सिस्टम में वर्तमान तालों पर वास्तविक समय की जानकारी प्रदान करता है। हम log_lock_waits . सेट करके लंबे समय तक प्रतीक्षारत लॉक को पकड़ सकते हैं , तो लंबी प्रतीक्षा की जानकारी PgSQL लॉग में लॉग की जाएगी। यदि हम असामान्य उच्च लॉकिंग देखते हैं जिसके परिणामस्वरूप लंबे समय तक प्रतीक्षा की जाती है, जैसा कि ऊपर वर्णित गतिरोध के मामले में, सॉफ़्टवेयर इंजीनियरों को कोड के किसी भी टुकड़े की समीक्षा करनी चाहिए जो लंबे समय तक लॉक का कारण हो सकता है, उदा। एप्लिकेशन में स्पष्ट लॉकिंग (टेबल लॉक करें या चुनें ... अद्यतन के लिए)।

इसी तरह गतिरोध के मामले में, शॉर्ट लॉक वाला सिस्टम आसानी से मल्टी-मास्टर सेटअप में चला जाएगा।