PostgreSQL के प्रदर्शन को बेंचमार्क कैसे करें

किसी डेटाबेस को बेंचमार्क करने का उद्देश्य न केवल डेटाबेस की क्षमता की जांच करना है, बल्कि आपके एप्लिकेशन के विरुद्ध किसी विशेष डेटाबेस के व्यवहार की भी जांच करना है। अलग-अलग हार्डवेयर आपके द्वारा निर्धारित बेंचमार्किंग योजना के आधार पर अलग-अलग परिणाम प्रदान करते हैं। सर्वर (वास्तविक एक बेंचमार्क किया जा रहा है) को अन्य तत्वों से अलग करना बहुत महत्वपूर्ण है जैसे लोड चलाने वाले सर्वर, या सर्वर प्रदर्शन मेट्रिक्स को इकट्ठा और संग्रहीत करने के लिए उपयोग किया जाता है। बेंचमार्किंग अभ्यास के हिस्से के रूप में, आपको एप्लिकेशन विशेषताओं को प्राप्त करना होगा जैसे a) क्या एप्लिकेशन को पढ़ा या लिखा जा रहा है? या ख) पढ़ने/लिखने का विभाजन (जैसे 80:20) क्या है? या c) डेटासेट कितना बड़ा है?, वास्तविक उत्पादन डेटाबेस आदि का डेटा और संरचना प्रतिनिधि है।

PostgreSQL दुनिया का सबसे उन्नत ओपन सोर्स डेटाबेस है। यदि कोई एंटरप्राइज़ RDBMS ग्राहक अपने डेटाबेस को ओपनसोर्स में माइग्रेट करना चाहता है, तो PostgreSQL मूल्यांकन करने का पहला विकल्प होगा।

इस पोस्ट में निम्नलिखित शामिल हैं:

• पोस्टग्रेएसक्यूएल को बेंचमार्क कैसे करें
• PostgreSQL में प्रमुख प्रदर्शन कारक क्या हैं
• प्रदर्शन बढ़ाने के लिए आप कौन से लीवर खींच सकते हैं
• प्रदर्शन के नुकसान से बचने के लिए क्या हैं
• लोग कौन सी सामान्य गलतियाँ करते हैं?
• आपको कैसे पता चलेगा कि आपका सिस्टम प्रदर्शन कर रहा है? आप किन उपकरणों का उपयोग कर सकते हैं?

PostgreSQL को बेंचमार्क कैसे करें

PostgreSQL को बेंचमार्क करने का मानक उपकरण pgbench है। डिफ़ॉल्ट रूप से, पीजीबेंच परीक्षण टीपीसी-बी पर आधारित होते हैं। इसमें प्रति लेनदेन 5 चयन, INSERT, और अद्यतन आदेश शामिल हैं। हालाँकि, आपके अनुप्रयोग व्यवहार के आधार पर, आप अपनी स्वयं की स्क्रिप्ट फ़ाइलें लिख सकते हैं। आइए हम डिफ़ॉल्ट और कुछ स्क्रिप्ट उन्मुख परीक्षा परिणामों को देखें। हम इन परीक्षणों के लिए PostgreSQL के नवीनतम संस्करण का उपयोग करने जा रहे हैं, जो कि लेखन के समय PostgreSQL 10 है। आप इसे ClusterControl का उपयोग करके या यहां दिए गए निर्देशों का उपयोग करके स्थापित कर सकते हैं:https://www.openscg.com/bigsql/package-manager/।

मशीन के विनिर्देश

संस्करण:RHEL 6 - 64 बिट
मेमोरी:4GB
प्रोसेसर:4
स्टोरेज:50G
PostgreSQL संस्करण:10.0
डेटाबेस आकार:15G

इससे पहले कि आप pgbench टूल के साथ बेंचमार्किंग चलाएँ, आपको इसे कमांड के नीचे इनिशियलाइज़ करना होगा:

-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE:  table "pgbench_history" does not exist, skipping
NOTICE:  table "pgbench_tellers" does not exist, skipping
NOTICE:  table "pgbench_accounts" does not exist, skipping
NOTICE:  table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.

जैसा कि नोटिस संदेशों में दिखाया गया है, यह बेंचमार्किंग के लिए लेनदेन चलाने के लिए pgbench_history, pgbench_tellers, pgbench_accounts, और pgbench_branches टेबल बनाता है।

यहां 10 ग्राहकों के साथ एक सरल परीक्षण दिया गया है:

-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)

जैसा कि आप देख सकते हैं, यह 10 ग्राहकों और प्रति ग्राहक 10 लेनदेन के साथ चला। इसने आपको 739 लेनदेन/सेकंड दिए। इसने आपको 739 लेनदेन/सेकंड दिए। यदि आप इसे विशिष्ट समय के लिए चलाना चाहते हैं, तो आप "-T" विकल्प का उपयोग कर सकते हैं। सामान्य तौर पर, 15 मिनट या 30 मिनट की दौड़ पर्याप्त होती है।

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

• किस प्रकार का कार्यभार?
• कितने समवर्ती सत्र?
• क्वेरी का औसत परिणाम सेट क्या है?
• अपेक्षित tps(लेन-देन प्रति सेकंड) क्या हैं?

यहां केवल-पढ़ने के लिए वर्क लोड का एक उदाहरण दिया गया है। आप केवल उन चयनों का उपयोग करने के लिए "-S" विकल्प का उपयोग कर सकते हैं जो केवल पढ़ने के लिए आते हैं। ध्यान दें कि -n टेबल पर वैक्यूम करना छोड़ना है।

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$

यहां विलंबता प्रत्येक क्लाइंट द्वारा निष्पादित प्रत्येक स्टेटमेंट का औसत बीता हुआ लेनदेन समय है। यह दिए गए हार्डवेयर के साथ 52 टीपीएस देता है। चूंकि यह बेंचमार्क केवल-पढ़ने के वातावरण के लिए है, आइए हम postgresql.conf फ़ाइल में साझा_बफ़र्स और प्रभावी_कैश_साइज़ मापदंडों को बदलने का प्रयास करें और टीपीएस गणना की जाँच करें। उपरोक्त परीक्षण में वे डिफ़ॉल्ट मान पर हैं, मान बढ़ाने का प्रयास करें, और परिणामों की जांच करें।

-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)

मापदंडों को बदलने से प्रदर्शन में 30% सुधार हुआ।

पीजीबेंच आमतौर पर अपनी टेबल पर लेनदेन चलाता है। यदि आपके पास 50% पढ़ने और लिखने का कार्यभार है (या 60:40 वातावरण), तो आप अपेक्षित कार्यभार प्राप्त करने के लिए कथनों के एक सेट के साथ एक स्क्रिप्ट फ़ाइल बना सकते हैं।

-bash-4.1$ cat /tmp/bench.sql 
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql 
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
 - weight: 1 (targets 50.0% of total)
 - 12707 transactions (50.0% of total, tps = 42.225555)
 - latency average = 914.240 ms
 - latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
 - weight: 1 (targets 50.0% of total)
 - 12729 transactions (50.0% of total, tps = 42.298662)
 - latency average = 1446.721 ms
 - latency stddev = 765.933 ms

PostgreSQL में प्रमुख प्रदर्शन कारक क्या हैं

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

• कार्यभार
• संसाधन
• अनुकूलन
• विवाद

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

सुझाव और सर्वोत्तम अभ्यास क्या हैं

यहां कुछ युक्तियां और सर्वोत्तम प्रक्रियाएं दी गई हैं जिनका पालन करके आप प्रदर्शन संबंधी समस्याओं से बच सकते हैं:

• आप अपने डेटाबेस में बड़े संशोधन के बाद VACUUM और ANALYZE जैसी रखरखाव गतिविधियों को चलाने पर विचार कर सकते हैं। यह योजनाकार को प्रश्नों को निष्पादित करने के लिए सर्वोत्तम योजना के साथ आने में मदद करता है।
• तालिकाओं को अनुक्रमित करने के लिए किसी भी आवश्यकता की तलाश करें। यह पूर्ण तालिका स्कैन करने के बजाय क्वेरी को बहुत तेज़ी से चलाता है।
• इंडेक्स ट्रैवर्सल को बहुत तेज़ बनाने के लिए, आप समान कुंजी मानों वाली पंक्तियों को क्लस्टर करने के लिए CREATE TABLE AS या CLUSTER कमांड का उपयोग कर सकते हैं।
• जब आप एक प्रदर्शन समस्या देखते हैं, तो योजना को देखने के लिए EXPLAIN कमांड का उपयोग करें कि कैसे अनुकूलक ने आपकी क्वेरी को निष्पादित करने का निर्णय लिया है।
• आप क्वेरी ऑपरेटरों को संशोधित करके ऑप्टिमाइज़र को प्रभावित करके योजनाओं को बदलने का प्रयास कर सकते हैं। उदाहरण के लिए, यदि आप अपनी क्वेरी के लिए अनुक्रमिक स्कैन देखते हैं, तो आप "SET ENABLE_SEQSCAN TO OFF" का उपयोग करके seq स्कैन को अक्षम कर सकते हैं। इस बात की कोई गारंटी नहीं है कि यदि आप इसे अक्षम करते हैं तो अनुकूलक उस ऑपरेटर को नहीं चुनेगा। ऑप्टिमाइज़र केवल ऑपरेटर को अधिक महंगा मानता है। अधिक विवरण यहां हैं:https://www.postgresql.org/docs/current/static/runtime-config-query.html
• आप अनुकूलक को प्रभावित करने के लिए CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST, और EFFECTIVE_CACHE_SIZE जैसे लागत मापदंडों को बदलने का प्रयास कर सकते हैं। अधिक विवरण यहां हैं:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
• क्लाइंट एप्लिकेशन के बजाय हमेशा सर्वर पर डेटा फ़िल्टर करें। यह नेटवर्क ट्रैफ़िक को कम करेगा और बेहतर प्रदर्शन देगा।
• सामान्य संचालन करने के लिए, सर्वर-साइड प्रक्रियाओं (ट्रिगर और फ़ंक्शन) का उपयोग करने की हमेशा अनुशंसा की जाती है। सर्वर-साइड ट्रिगर या फ़ंक्शन को हर बार नहीं, बल्कि पहली बार उपयोग किए जाने पर पार्स, नियोजित और अनुकूलित किया जाता है।

लोग क्या सामान्य गलतियाँ करते हैं

आम गलतियों में से एक जो लोग करते हैं वह है डेटाबेस सर्वर और डेटाबेस को डिफ़ॉल्ट मापदंडों के साथ चलाना। PostgreSQL डिफ़ॉल्ट कॉन्फ़िगरेशन का परीक्षण कुछ वातावरणों में किया जाता है, हालांकि प्रत्येक एप्लिकेशन को वे मान इष्टतम नहीं मिलेंगे। तो आपको अपने एप्लिकेशन व्यवहार को समझने की जरूरत है और इसके आधार पर, अपने कॉन्फ़िगरेशन पैरामीटर सेट करें। आप जिस हार्डवेयर का उपयोग कर रहे हैं उसके आधार पर अपने पैरामीटर के लिए मान प्राप्त करने के लिए आप pgTune टूल का उपयोग कर सकते हैं। आप यहां देख सकते हैं:http://pgtune.leopard.in.ua/। हालांकि, ध्यान रखें कि आपके द्वारा किए गए परिवर्तनों के साथ आपको अपने आवेदन का परीक्षण करना होगा, यह देखने के लिए कि क्या परिवर्तनों के साथ कोई प्रदर्शन गिरावट आई है।

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