मैं कई परियोजनाओं को बनाए रखता हूं जिनका जीवन में उद्देश्य पोस्टग्रेएसक्यूएल के परीक्षण भागों को आसान बनाना है। इन सभी को पिछले सप्ताह के दौरान एक अच्छा अपग्रेड मिला है।
स्ट्रीम-स्केलिंग परीक्षण करता है कि सर्वर पर मेमोरी की गति कैसे बढ़ती है क्योंकि अधिक कोर खेल में लाए जाते हैं। यह आकर्षक डेटा है, इसमें से कुछ वास्तविक रुझानों को देखना शुरू करने के लिए पर्याप्त है। यह अब बड़ी मात्रा में CPU कैश वाले सिस्टम पर सही ढंग से काम करता है, क्योंकि उनके पास कई कोर हैं। कैश प्रभाव से बचने के लिए परीक्षण सेट को आकार देने के साथ इतना आक्रामक होना पहले संभव था कि यह स्ट्रीम कोड के वर्तमान डिज़ाइन के साथ आवंटित की तुलना में अधिक मेमोरी का उपयोग करता था। इसे वापस बढ़ाया गया है। यदि आपके पास 48 कोर सर्वर या उससे बड़ा है, तो मैं इस नए कोड के कुछ और परीक्षण का उपयोग यह देखने के लिए कर सकता हूं कि क्या मैं इसे संभालने का नया तरीका समझ में आता हूं।
पेग एक स्क्रिप्ट है जिसे मैंने स्रोत से पोस्टग्रेएसक्यूएल बनाना आसान बनाने के लिए लिखा था, आमतौर पर डेवलपर काम के लिए या अस्थायी रूप से उत्पादन प्रणाली पर एक नए संस्करण को आजमाने के लिए। पहले परियोजनाओं और उनकी संबंधित गिट शाखाओं के बीच स्विच के साथ भ्रमित होना बहुत आसान था; इस क्षेत्र में प्रलेखन में काफी सुधार हुआ है।
pgbench-tools मेरा प्रदर्शन परीक्षण वर्कहाउस है, जिससे आप बेंचमार्क चिह्न के दिनों की कतार में लग सकते हैं और फिर इसे समझने के लिए पर्याप्त विश्लेषण उपकरण उपलब्ध हैं। प्रोग्राम अब हाल ही में पेश किए गए pg_stat_bgwriter.buffers_backend_fsync पैरामीटर को ट्रैक करता है यदि आपके पास एक संस्करण है जो इसका समर्थन करता है (वर्तमान में केवल एक हालिया खट्टा बिल्ड-जो हमें वापस लाता है कि पेग उपयोगी क्यों है)। आप इसे प्रत्येक परीक्षण को एक निश्चित समय के लिए चलाने के लिए भी कह सकते हैं, जो बेतहाशा भिन्न क्लाइंट/आकार मानों पर परीक्षण को कहीं अधिक आसान बना देता है।
जहाँ तक आप pgbench-tools के साथ क्या कर सकते हैं ... आज तक मैं उन बेंचमार्किंग परीक्षणों को साझा कर रहा हूँ जो मैं PostgreSQL 9.1 पर सबसे शक्तिशाली सर्वर पर कर रहा हूँ जिसका मेरे पास असीमित उपयोग है। 8 कोर, 16GB RAM, 3 डिस्क RAID-0 डेटाबेस ड्राइव, 1 डिस्क WAL वॉल्यूम, Areca बैटरी-समर्थित कैश। आप परिणाम देख सकते हैं। रन को परीक्षण सेट में व्यवस्थित किया जाता है, जिनमें से प्रत्येक कॉन्फ़िगरेशन में किसी प्रकार के परिवर्तन का प्रतिनिधित्व करता है। उदाहरण के लिए, इस डेटा में # 1 केवल SELECT चल रहा है, # 2 TPC-B- जैसा चल रहा है, लेकिन 8GB RAM और ईलियर कोड के साथ, जबकि हॉट स्टफ # 3 है, TPC-B को 16GB RAM और कोड के साथ चला रहा है बफ़र्स_बैकएंड_fsyncs को ट्रैक करता है।
इन परिणामों द्वारा हाइलाइट किए गए क्षेत्रों में प्रदर्शन से संबंधित PostgreSQL 9.1 कतार में कई पैच हैं- कि लिनक्स में लिखने-भारी डेटाबेस लोड पर अत्यधिक खराब स्थिति विलंबता हो सकती है। एक अच्छा औसत उदाहरण परीक्षण 215 है: 1000 का पैमाना, 32 क्लाइंट, 365 टीपीएस।, लेकिन सबसे खराब स्थिति में विलंबता 43 सेकंड है, और आप टीपीएस ग्राफ़ में मृत स्पॉट देख सकते हैं। यह बहुत ही भयानक है, और इसे कैसे करना है, इसके लिए कुछ अवधारणाएं चल रही हैं।
अगर इसे पढ़ने वाले किसी व्यक्ति के पास इस तरह के परीक्षण चलाने के लिए कुछ हफ्तों के लिए एक शक्तिशाली सर्वर उपलब्ध है, तो मुझे इस माहौल को दोहराने और यह देखने में आपकी मदद करने में खुशी होगी कि आप किस तरह के परिणाम देखते हैं। मेरे पास एकमात्र जादू है कि स्केलिंग और क्लाइंट लोड को कैसे सेट किया जाए, ताकि आप अनुत्पादक परीक्षणों के लिए बहुत समय न गंवाएं। मेरी बाकी प्रक्रिया पूरी तरह से मुफ़्त और प्रलेखित है।
