PostgreSQL
 sql >> डेटाबेस >  >> RDS >> PostgreSQL

पीजीईस्ट, हार्डवेयर बेंचमार्किंग और पीजी परफॉर्मेंस फार्म

इस महीने के पोस्टग्रेएसक्यूएल कॉन्फ़्रेंस ईस्ट 2010 की मेजबानी करने वाले होटल में विशेष कमरे की दर के लिए आज समय सीमा है।  यदि आप सम्मेलन में किसी स्थान की बुकिंग में देरी कर रहे हैं, तो कल से यह आपको महंगा पड़ जाएगा।

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

और पोस्टग्रेएसक्यूएल 9.0 ने एक बड़ी समस्या को ठीक कर दिया, जिसने इसे लिनक्स पर सामान्य रूप से सटीक परिणाम देने से रोक दिया, एक कर्नेल रिग्रेशन के कारण जिसने पहले से ही बहुत सामान्य स्थिति को और भी खराब कर दिया:  इसे चलाने के दौरान एक पीजीबेंच क्लाइंट के लिए बाधा बनना आसान है, बल्कि डेटाबेस की तुलना में ही। मल्टी-थ्रेडेड pgbench के लिए मैंने जो समीक्षा की थी (जो सिस्टम पर मल्टी-प्रोसेस pgbench भी हो सकती है जो थ्रेड्स का समर्थन नहीं करती है) ने उन सिस्टमों पर भी एक ठोस> 30% स्पीडअप का सुझाव दिया, जिन पर खराब कर्नेल असंगति नहीं थी। बाद के परीक्षण से पता चलता है कि हाल ही में लिनक्स कर्नेल के तहत सस्ते आधुनिक प्रोसेसर से पूर्ण थ्रूपुट प्राप्त करने के लिए यह आसानी से 8 पीजीबेंच प्रक्रियाओं को ले सकता है। मैं ठीक-ठीक बताता हूँ कि यह इस तरह के सिस्टम पर कैसे चलता है, और कैसे यह नई सुविधा डेटाबेस को चलाने वाले CPU प्रदर्शन को मापने के प्राथमिक तरीके के रूप में pgbench का उपयोग करना फिर से संभव बनाती है।

हाल ही में मैंने pgbench-tools के लिए git रेपो में एक अपडेट किया है जो PostgreSQL 8.4 और मूल 9.0 संगतता के लिए कार्य समर्थन जोड़ता है, और अगले अपडेट में मल्टी-थ्रेडेड विकल्प के लिए समर्थन शामिल होगा जिसे मैंने मैप किया है कि कैसे काम करने की जरूरत है। यह सब कहीं आगे बढ़ रहा है। एक बार जब हमारे पास PostgreSQL के प्रदर्शन के लिए सटीक माप होते हैं जो सर्वर साइड पर CPU सीमित होते हैं, तो कुछ ऐसा जो अक्सर दो साल से अधिक समय से नहीं होता है, वे फिर से PostgreSQL कोडबेस में प्रदर्शन प्रतिगमन की निगरानी के लिए एक उपयोगी तरीका बन जाते हैं। शामिल किए गए परीक्षणों को इसके लिए और अधिक अंततः कवर करने के लिए विस्तार करने की आवश्यकता होगी, लेकिन अभी के लिए हम एक ऐसे बिंदु पर पहुंच गए हैं जहां pgbench का उपयोग उन प्रतिगमनों को खोजने के लिए किया जा सकता है जो प्रभावित करते हैं कि कितनी तेजी से सरल SELECT स्टेटमेंट निष्पादित होते हैं। मुझे पता है कि यह उम्मीद के मुताबिक काम करता है, क्योंकि हर बार जब मैं गलती से पोस्टग्रेएसक्यूएल का निर्माण करता हूं तो उस पर दावा किया जाता है क्योंकि मुझे औसत प्रसंस्करण दर में नाटकीय रूप से गिरावट दिखाई देती है।

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

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

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


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. यदि कोई मेल नहीं खाता है तो पहले रिकॉर्ड का चयन करें

  2. रिकॉर्ड प्राप्त करें जहां जेसन कॉलम कुंजी रिक्त है

  3. केवल नई पंक्तियों के लिए डिफ़ॉल्ट नाउ () के साथ टाइमस्टैम्प कॉलम जोड़ें

  4. PostgreSQL में JSONB का उपयोग करना:PostgreSQL में JSON डेटा को प्रभावी ढंग से कैसे स्टोर और इंडेक्स करें?

  5. त्रुटि:psycopg2.extensions नाम का कोई मॉड्यूल नहीं है