मैंने विभिन्न PostgreSQL संस्करणों की तुलना करते हुए कई बेंचमार्क प्रकाशित किए हैं, उदाहरण के लिए प्रदर्शन पुरातत्व वार्ता (PostgreSQL 7.4 का मूल्यांकन 9.4 तक), और उन सभी बेंचमार्क ने निश्चित वातावरण (हार्डवेयर, कर्नेल, ...) ग्रहण किया। जो कई मामलों में ठीक है (उदाहरण के लिए पैच के प्रदर्शन प्रभाव का मूल्यांकन करते समय), लेकिन उत्पादन पर वे चीजें समय के साथ बदल जाती हैं - आपको हार्डवेयर अपग्रेड मिलता है और समय-समय पर आपको एक नए कर्नेल संस्करण के साथ अपडेट मिलता है।
हार्डवेयर उन्नयन (बेहतर भंडारण, अधिक रैम, तेज सीपीयू,…) के लिए, प्रभाव आमतौर पर भविष्यवाणी करना काफी आसान होता है, और इसके अलावा लोगों को आमतौर पर एहसास होता है कि उन्हें उत्पादन पर बाधाओं का विश्लेषण करके और शायद पहले नए हार्डवेयर का परीक्षण करके प्रभाव का आकलन करने की आवश्यकता है। ।
लेकिन कर्नेल अपडेट के बारे में क्या? अफसोस की बात है कि हम आमतौर पर इस क्षेत्र में ज्यादा बेंचमार्किंग नहीं करते हैं। यह धारणा ज्यादातर है कि नए कर्नेल पुराने लोगों की तुलना में बेहतर हैं (तेज, अधिक कुशल, अधिक CPU कोर के पैमाने)। लेकिन क्या यह वाकई सच है? और कितना बड़ा अंतर है? उदाहरण के लिए, यदि आप कर्नेल को 3.0 से 4.7 में अपग्रेड करते हैं - तो क्या यह प्रदर्शन को प्रभावित करेगा, और यदि हाँ, तो क्या प्रदर्शन में सुधार होगा या नहीं?
समय-समय पर हमें किसी विशेष कर्नेल संस्करण के साथ गंभीर प्रतिगमन, या कर्नेल संस्करणों के बीच अचानक सुधार के बारे में रिपोर्ट मिलती है। तो स्पष्ट रूप से, कर्नेल संस्करण प्रदर्शन को प्रभावित कर सकते हैं।
मुझे पता है कि एक सिंगल पोस्टग्रेएसक्यूएल बेंचमार्क विभिन्न कर्नेल संस्करणों की तुलना करता है, जिसे 2014 में सर्गेई कोनोपलेव द्वारा 3.0 - 3.8 कर्नेल से बचने की सिफारिशों के जवाब में बनाया गया था। लेकिन वह बेंचमार्क काफी पुराना है (~ 18 महीने पहले उपलब्ध अंतिम कर्नेल संस्करण 3.13 था, जबकि आजकल हमारे पास 3.19 और 4.6 है), इसलिए मैंने वर्तमान कर्नेल (और PostgreSQL 9.6beta1) के साथ कुछ बेंचमार्क चलाने का फैसला किया है।
PostgreSQL बनाम कर्नेल संस्करण
लेकिन पहले, मैं दो परियोजनाओं में प्रतिबद्धताओं को नियंत्रित करने वाली नीतियों के बीच कुछ महत्वपूर्ण अंतरों पर चर्चा करता हूं। PostgreSQL में हमारे पास प्रमुख और छोटे संस्करणों की अवधारणा है - प्रमुख संस्करण (जैसे 9.5) वर्ष में लगभग एक बार जारी किए जाते हैं, और इसमें विभिन्न नई सुविधाएँ शामिल होती हैं। छोटे संस्करणों (जैसे 9.5.2) में केवल बगफिक्स शामिल होते हैं, और हर तीन महीने में जारी किए जाते हैं (या अधिक बार, जब एक गंभीर बग का पता चलता है)। इसलिए छोटे संस्करणों के बीच कोई बड़ा प्रदर्शन या व्यवहार परिवर्तन नहीं होना चाहिए, जो व्यापक परीक्षण के बिना मामूली संस्करणों को तैनात करना काफी सुरक्षित बनाता है।
कर्नेल संस्करणों के साथ, स्थिति बहुत कम स्पष्ट है। लिनक्स कर्नेल की भी शाखाएँ हैं (जैसे 2.6, 3.0 या 4.7), जो किसी भी तरह से PostgreSQL के "प्रमुख संस्करणों" के बराबर नहीं हैं, क्योंकि वे नई सुविधाएँ प्राप्त करना जारी रखते हैं न कि केवल बगफिक्स। मैं यह दावा नहीं कर रहा हूं कि PostgreSQL संस्करण नीति किसी भी तरह से स्वचालित रूप से बेहतर है, लेकिन परिणाम यह है कि मामूली कर्नेल संस्करणों के बीच अद्यतन करना प्रदर्शन को आसानी से प्रभावित कर सकता है या यहां तक कि बग भी पेश कर सकता है (उदाहरण के लिए 3.18.37 ऐसे गैर-बगफिक्स के कारण ओओएम मुद्दों से ग्रस्त है प्रतिबद्ध)।
बेशक, वितरण इन जोखिमों का एहसास करते हैं, और अक्सर कर्नेल संस्करण को लॉक कर देते हैं और नए बगों को दूर करने के लिए और परीक्षण करते हैं। हालाँकि यह पोस्ट वैनिला लॉन्गटर्म कर्नेल का उपयोग करती है, जैसा कि www.kernel.org पर उपलब्ध है।
बेंचमार्क
ऐसे कई बेंचमार्क हैं जिनका हम उपयोग कर सकते हैं - यह पोस्ट pgbench परीक्षणों का एक सूट प्रस्तुत करता है, अर्थात एक काफी सरल OLTP (TPC-B-like) बेंचमार्क। मैं अन्य बेंचमार्क प्रकारों (विशेषकर DWH/DSS-उन्मुख) के साथ अतिरिक्त परीक्षण करने की योजना बना रहा हूं, और मैं उन्हें भविष्य में इस ब्लॉग पर प्रस्तुत करूंगा।
अब, पीजीबेंच पर वापस जाएं - जब मैं "परीक्षणों का संग्रह" कहता हूं, तो मेरा मतलब संयोजनों से है
- केवल पढ़ने के लिए बनाम पढ़ने-लिखने के लिए
- डेटा सेट का आकार - सक्रिय सेट साझा बफर / रैम में फिट नहीं होता है
- ग्राहकों की संख्या - एकल ग्राहक बनाम अनेक ग्राहक (लॉकिंग/शेड्यूलिंग)
मान स्पष्ट रूप से उपयोग किए गए हार्डवेयर पर निर्भर करते हैं, तो आइए देखें कि बेंचमार्क का यह दौर किस हार्डवेयर पर चल रहा था:
- CPU:Intel i5-2500k @ 3.3 GHz (3.7 GHz टर्बो)
- रैम:8GB (DDR3 @ 1333 MHz)
- भंडारण:RAID-10 में 6x Intel SSD DC S3700 (लिनक्स स्व RAID)
- फाइल सिस्टम:डिफ़ॉल्ट I/O अनुसूचक (cfq) के साथ ext4
तो यह वही मशीन है जिसका उपयोग मैंने पिछले कई बेंचमार्क के लिए किया है - एक काफी छोटी मशीन, बिल्कुल नवीनतम सीपीयू आदि नहीं, लेकिन मेरा मानना है कि यह अभी भी एक उचित "छोटा" सिस्टम है।
बेंचमार्क पैरामीटर हैं:
- डेटा सेट स्केल:30, 300 और 1500 (इतना मोटे तौर पर 450MB, 4.5GB और 22.5GB)
- ग्राहकों की संख्या:1, 4, 16 (मशीन में 4 कोर हैं)
प्रत्येक संयोजन के लिए 3 रीड-ओनली रन (प्रत्येक में 15-मिनट) और 3 रीड-राइट रन (प्रत्येक में 30-मिनट) थे। बेंचमार्क चलाने वाली वास्तविक स्क्रिप्ट यहां (परिणामों और अन्य उपयोगी डेटा के साथ) उपलब्ध है।
नोट :यदि आपके पास महत्वपूर्ण रूप से भिन्न हार्डवेयर (उदा. घूर्णी ड्राइव) हैं, तो आप बहुत भिन्न परिणाम देख सकते हैं। यदि आपके पास एक प्रणाली है जिसका आप परीक्षण करना चाहते हैं, तो मुझे बताएं और मैं इसमें आपकी सहायता करूंगा (यह मानते हुए कि मुझे परिणाम प्रकाशित करने की अनुमति दी जाएगी)।
कर्नेल संस्करण
कर्नेल संस्करणों के संबंध में, मैंने 2.6.x (2.6.39, 3.0.101, 3.2.81, 3.4.112, 3.10.102, 3.12.61, 3.14.73, 3.16) के बाद से सभी लंबी अवधि की शाखाओं में नवीनतम संस्करणों का परीक्षण किया है। 36, 3.18.38, 4.1.29, 4.4.16, 4.6.5 और 4.7)। 2.6.x कर्नेल पर अभी भी बहुत सारे सिस्टम चल रहे हैं, इसलिए यह जानना उपयोगी है कि नए कर्नेल में अपग्रेड करके आप कितना प्रदर्शन प्राप्त कर सकते हैं (या खो सकते हैं)। लेकिन मैं सभी कर्नेल को अपने आप संकलित कर रहा हूं (यानी वेनिला कर्नेल का उपयोग करना, कोई वितरण-विशिष्ट पैच नहीं), और कॉन्फ़िगरेशन फ़ाइलें गिट रिपॉजिटरी में हैं।
परिणाम
हमेशा की तरह, सभी डेटा बिटबकेट पर उपलब्ध है, जिसमें शामिल हैं
- कर्नेल .कॉन्फ़िगरेशन फ़ाइल
- बेंचमार्क स्क्रिप्ट (run-pgbench.sh)
- PostgreSQL कॉन्फिगरेशन (हार्डवेयर के लिए कुछ बेसिक ट्यूनिंग के साथ)
- PostgreSQL लॉग
- विभिन्न सिस्टम लॉग (dmesg, sysctl, माउंट,…)
निम्न चार्ट प्रत्येक बेंचमार्क केस के लिए औसत टीपीएस दिखाते हैं - तीन रनों के परिणाम काफी सुसंगत हैं, ज्यादातर मामलों में न्यूनतम और अधिकतम के बीच ~2% अंतर के साथ।
केवल पढ़ने के लिए
सबसे छोटे डेटा सेट के लिए, सभी क्लाइंट गणनाओं के लिए 3.4 और 3.10 के बीच एक स्पष्ट प्रदर्शन गिरावट है। 16 ग्राहकों के लिए परिणाम (कोर की संख्या का 4 गुना) हालांकि 3.12 में ठीक होने की तुलना में अधिक।
मध्यम डेटा सेट के लिए (रैम में फिट बैठता है लेकिन साझा बफर में नहीं), हम 3.4 और 3.10 के बीच एक ही गिरावट देख सकते हैं लेकिन 3.12 में रिकवरी नहीं देख सकते हैं।
बड़े डेटा सेट (रैम से अधिक, इतनी भारी I/O-बाउंड) के लिए, परिणाम बहुत अलग हैं - मुझे यकीन नहीं है कि 3.10 और 3.12 के बीच क्या हुआ, लेकिन प्रदर्शन में सुधार (विशेष रूप से उच्च ग्राहक गणना के लिए) काफी आश्चर्यजनक है।
पढ़ें-लिखें
पढ़ने-लिखने के कार्यभार के लिए, परिणाम काफी समान हैं। छोटे और मध्यम डेटा सेट के लिए हम 3.4 और 3.10 के बीच समान ~ 10% की गिरावट देख सकते हैं, लेकिन दुख की बात है कि 3.12 में कोई रिकवरी नहीं हुई।
बड़े डेटा सेट के लिए (फिर से, महत्वपूर्ण रूप से I/O बाध्य) हम 3.12 में समान सुधार देख सकते हैं (केवल-पढ़ने के लिए कार्यभार के रूप में महत्वपूर्ण नहीं, लेकिन फिर भी महत्वपूर्ण):
सारांश
मैं एक मशीन पर एक बेंचमार्क से निष्कर्ष निकालने की हिम्मत नहीं करता, लेकिन मुझे लगता है कि यह कहना सुरक्षित है:
- समग्र प्रदर्शन काफी स्थिर है, लेकिन हम कुछ महत्वपूर्ण प्रदर्शन परिवर्तन (दोनों दिशाओं में) देख सकते हैं।
- मेमोरी में फिट होने वाले डेटा सेट के साथ (या तो शेयर्ड_बफ़र्स में या कम से कम रैम में) हम 3.4 और 3.10 के बीच एक औसत दर्जे का प्रदर्शन ड्रॉप देखते हैं। केवल पढ़ने के लिए परीक्षण पर यह आंशिक रूप से 3.12 (लेकिन केवल कई क्लाइंट के लिए) में ठीक हो जाता है।
- मेमोरी से अधिक डेटा सेट के साथ, और इस प्रकार मुख्य रूप से I/O-बाउंड, हमें ऐसा कोई प्रदर्शन ड्रॉप नहीं दिखाई देता है, बल्कि 3.12 में एक महत्वपूर्ण सुधार दिखाई देता है।
उन अचानक परिवर्तन होने के कारणों के बारे में, मुझे पूरा यकीन नहीं है। संस्करणों के बीच कई संभावित-प्रासंगिक प्रतिबद्धताएं हैं, लेकिन मुझे यकीन नहीं है कि व्यापक (और समय लेने वाली) परीक्षण के बिना सही की पहचान कैसे करें। यदि आपके पास अन्य विचार हैं (उदाहरण के लिए ऐसी प्रतिबद्धताओं से अवगत हैं), तो मुझे बताएं।
