कम पोस्टग्रेएसक्यूएल लेटेंसी के लिए पिछले महीने के ट्यूनिंग लिनक्स के बाद, अब दो फाइल सिस्टम, तीन पैच, और कर्नेल ट्यूनिंग पैरामीटर के दो सेट पर परीक्षण का एक विशाल ढेर हो गया है। परिणाम अब तक कुछ दिलचस्प नया डेटा है, और इस क्षेत्र में एक और प्रतिबद्ध सुधार जो अब PostgreSQL 9.1 में हैं (कुल तीन बनाते हुए, अन्य दो निगरानी पैच हैं)। मैं अगले महीने पोस्टग्रेएसक्यूएल ईस्ट में अपनी एक वार्ता के दौरान अनुशंसित अभ्यास के बारे में बोलूंगा, और मैंने इस क्षेत्र में मई के पीजीसीओएन के लिए भी कुछ प्रस्तुत किया है। यहाँ मैं मृत अंत के बारे में भी कुछ और बात करूँगा, जबकि वे यादें अभी भी ताज़ा हैं।
यहां मूल समस्या यह है कि जिस तरह से PostgreSQL ऑपरेटिंग सिस्टम कैश का उपयोग करता है जब लेखन बड़ी मात्रा में डेटा जमा करने की अनुमति देता है। परिणाम जब डेटाबेस चौकियों के समाप्त होने पर उस डेटा के लिखने की प्रतीक्षा करते हुए लंबी देरी हो सकती है। यह पता चला है कि PostgreSQL के साथ आने वाला pgbench प्रोग्राम वास्तव में इस समस्या को पैदा करने में अच्छा है, इसलिए मैंने सभी परीक्षणों के लिए इसका उपयोग किया। मैं जिन सवालों के जवाब देने के लिए निकला था, वे थे:
- क्या पुराने ext3 फाइल सिस्टम से बदलना वास्तव में डेटाबेस कार्यों पर प्रदर्शन में सुधार दिखाता है? मैंने पिछले साल लिनक्स पर एक्सएफएस की वापसी के बारे में कुछ लिखा था जिसने सरल बेंचमार्क पर अच्छा सुधार दिखाया। हालांकि यह हमेशा डेटाबेस सुधार में तब्दील नहीं होता है।
- क्या हाल ही के Linux डर्टी_बाइट्स और डर्टी_बैकग्राउंड_बाइट्स ट्यूनेबल वास्तव में सबसे खराब स्थिति में सुधार करते हैं?
- यहां व्यवहार में सुधार के लिए सुझाए गए डेटाबेस में से कौन सा परिवर्तन वास्तव में काम करता है?
यदि आप कच्चे डेटा की जांच करना चाहते हैं तो आप सभी परीक्षा परिणाम देख सकते हैं। प्रत्येक परीक्षण सेट के लिए जो बदला गया था वह प्रलेखित है, और यदि आप एक व्यक्तिगत परीक्षण में ड्रिल डाउन करते हैं तो आप उपयोग किए गए डेटाबेस पैरामीटर और कुछ अन्य बुनियादी ओएस जानकारी देख सकते हैं। यदि आप स्वयं इस प्रकार का प्रयास करना चाहते हैं, तो वह वेब पेज मेरे pgbench-tools परीक्षण कार्यक्रम से निकलता है।
परिणाम बहुत आश्चर्यजनक नहीं थे, लेकिन वे दिलचस्प थे। यहां सभी परीक्षण दो डेटाबेस आकारों के साथ किए गए थे। एक छोटे डेटाबेस आकार पर (स्केल=500, लगभग 8GB डेटाबेस जो सर्वर के 16GB RAM में आसानी से फिट हो जाता है), ext3 ने 690 लेनदेन/सेकंड का प्रबंधन किया, जबकि उस आकार के दोगुने पर (स्केल=1000, लगभग 16GB डेटाबेस) यह बहुत अधिक था मोर सीक बाउंड और केवल 349 टीपीएस प्रबंधित। एक्सएफएस ने उन दो नंबरों को बढ़ाकर क्रमशः 1757 टीपीएस और 417 टीपीएस कर दिया-क्रमशः 255% और 19% लाभ। इससे भी बेहतर, एकल लेन-देन के लिए सबसे खराब स्थिति विलंबता 34 से 56 सेकंड की सीमा (!) से घटकर 2 से 5 सेकंड हो गई। जबकि 5 सेकंड भी बहुत अच्छा नहीं है, यह एक सिंथेटिक वर्कलोड है जिसे इस समस्या को वास्तव में खराब करने के लिए डिज़ाइन किया गया है। ext3 संख्या इतनी भयानक है कि आप अभी भी वास्तव में यहां एक खराब समस्या में भाग लेने की संभावना रखते हैं, भले ही मैं वास्तव में उस फाइल सिस्टम पर बेहतर व्यवहार देख रहा था, जैसा कि मैंने पहले कर्नेल में देखा है (यह 2.6.32 के साथ किया गया था)।
राउंड 1: XFS एक भूस्खलन में जीत जाता है। यदि आप बहुत अधिक लिखने की योजना बनाते हैं, तो मैं बहुत सारी मेमोरी के साथ लिनक्स सिस्टम पर एक व्यवहार्य फाइल सिस्टम के रूप में ext3 की सिफारिश नहीं कर सकता; यह सिर्फ उस संदर्भ में काम नहीं करता है। इस सर्वर में केवल 16GB RAM था, इसलिए आप कल्पना कर सकते हैं कि 2011 में एक गंभीर उत्पादन सर्वर पर यह समस्या कितनी खराब है।
अगला, डर्टी_बाइट्स और डर्टी_बैकग्राउंड_बाइट्स ट्यून करने योग्य हैं। इन दोनों ने कुछ मंदी की कीमत पर ext3 पर विलंबता में काफी सुधार किया। उनमें से सबसे खराब, धीमा रखरखाव समय VACUUM चल रहा है, आप स्वयं परीक्षा परिणामों में नहीं देखते हैं; मैंने अपनी पिछली ब्लॉग प्रविष्टि में पहले ही इस पर चर्चा की थी। XFS पर, इन मापदंडों को कम करना एक प्रदर्शन आपदा है। छोटे डेटाबेस पैमाने पर, TPS का प्रदर्शन 46% गिर जाता है, और इसके शीर्ष पर विलंबता वास्तव में खराब हो जाती है।
राउंड 2: डर्टी_बाइट्स या डर्टी_बैकग्राउंड_बाइट्स से किसी चमत्कार की उम्मीद न करें। ऐसा लगता है कि कुछ परिस्थितियों में उनका कुछ प्रभाव पड़ता है, लेकिन संभावित नकारात्मक पक्ष भी बड़ा है। इन दोनों को नीचे की ओर समायोजित करने से पहले सावधानीपूर्वक परीक्षण करना सुनिश्चित करें, और अपने परीक्षण में VACUUM को शामिल करें।
इसके बाद, मैंने इस अंतिम CommitFest के हिस्से के रूप में PostgreSQL के लिए तीन पैच विचारों का मूल्यांकन समाप्त किया:
- चेकपॉइंट सिंक को डिस्क पर फैलाएं (fsync) समय के साथ कॉल आउट। हमने एक व्यस्त क्लाइंट सर्वर पर इसके साथ कुछ सफलता देखी है जब डेटाबेस द्वारा अन्य सिंक संचालन को कैश किए जाने के कुछ बेहतर प्रबंधन के साथ जोड़ा गया था
- संक्षिप्त fsync अनुरोध। यह विचार पहले वाले से अलग हो गया और रॉबर्ट हास द्वारा लिखित एक पैच में बदल गया। विचार यह है कि डेटा को डिस्क से सिंक करने का प्रयास करने वाले क्लाइंट चेकपॉइंट लेखन के साथ प्रतिस्पर्धा कर सकते हैं। पैच जो करता है वह क्लाइंट को fsync अनुरोधों की कतार को साफ़ करने की अनुमति देता है यदि वे इसे कभी भी पूर्ण पाते हैं।
- सॉर्ट चेकपॉइंट लिखता है। अवधारणा यह है कि यदि आप चीजों को उस क्रम में लिखते हैं जिस क्रम में डेटाबेस मानता है कि चीजें डिस्क पर संग्रहीत हैं, तो ओएस अधिक कुशलता से लिख सकता है। यह पैच कुछ साल पहले कुछ बेंचमार्क परिणामों के साथ दिखा था कि यह काम करता है, लेकिन उस समय कोई भी सुधारों को दोहराने में सक्षम नहीं था। यह विचार बाकी कामों में इतना फिट बैठता है कि मैंने इसका फिर से मूल्यांकन किया।
राउंड 3: यह सब करने के हफ्तों के बाद, इस सेट में से एकमात्र दृष्टिकोण जिसने लगभग सभी कार्यभार आकारों में सुधार दिखाया, वह था fsync संघनन। मूल स्प्रेड चेकपॉइंट सिंक कोड ने इस क्षेत्र में कुछ मदद की, लेकिन विशिष्ट कार्यान्वयन जो अब 9.1 के लिए प्रतिबद्ध है, ने और भी बेहतर काम किया। मेरे द्वारा चलाए गए अधिकांश लेखन-भारी परीक्षणों पर यह लगभग 10% लाभ था। PostgreSQL 9.1 के लिए यह एक बहुत अच्छा सुधार है, और इसे उस समस्या को पूरी तरह से समाप्त करना चाहिए जिसे हमने यहां उत्पादन प्रणालियों पर बहुत अधिक मंदी का कारण देखा है।
यहाँ के बाकी विचारों को भारी के बाद इतना सकारात्मक मूल्यांकन नहीं मिला बेंचमार्किंग, इसलिए अभी के लिए वे वापस शेल्फ पर जाते हैं। मैं यहां डेटा एकत्र करना जारी रखूंगा-कुछ ext4 परीक्षण अगली तार्किक बात हैं- और फिर विकास पर वापस लौटते हैं। कुछ कठिन कार्यभार पर 10% लाभ प्राप्त करना निश्चित रूप से अच्छा है, लेकिन चेकपॉइंट सिंक मुद्दों को एक बंद विषय पर विचार करने के लिए यहां अभी भी बहुत से खराब स्थिति वाले व्यवहार हैं।
