PostgreSQL प्रदर्शन को बेहतर बनाने के लिए लिनक्स ट्यूनिंग। इल्या कोस्मोडेमेन्स्की

इल्या कोस्मोडेमयांस्की की 2015 की रिपोर्ट "PostgreSQL प्रदर्शन में सुधार के लिए लिनक्स ट्यूनिंग" की प्रतिलिपि

अस्वीकरण: मैं यह नोट करना चाहूंगा कि यह रिपोर्ट नवंबर 2015 की है - 4 साल से अधिक समय बीत चुका है और बहुत समय बीत चुका है। रिपोर्ट में माना गया संस्करण 9.4 अब समर्थित नहीं है। पिछले 4 वर्षों में, PostgreSQL के 5 नए रिलीज़ जारी किए गए हैं और Linux कर्नेल के 15 संस्करण जारी किए गए हैं। यदि आप इन स्थानों को फिर से लिखते हैं, तो आपको एक अलग रिपोर्ट मिलेगी। लेकिन यहाँ हम PostgreSQL के लिए मौलिक Linux ट्यूनिंग पर विचार करते हैं, जो आज भी प्रासंगिक है।

मेरा नाम इल्या कोस्मोडेमयांस्की है। मैं PostgreSQL-Consulting के लिए काम करता हूँ। और अब मैं आपको थोड़ा बताऊँगा कि सामान्य रूप से डेटाबेस और विशेष रूप से PostgreSQL के संबंध में Linux के साथ क्या करना है, क्योंकि सिद्धांत काफी समान हैं।

हम किस बारे में बात करने जा रहे हैं? यदि आप PostgreSQL के साथ काम कर रहे हैं, तो आपको कुछ हद तक UNIX एडमिन होना चाहिए। इसका क्या मतलब है? यदि हम Oracle और PostgreSQL की तुलना करें, तो Oracle में आपको 80% DBA डेटाबेस एडमिन और 20% Linux एडमिन होना चाहिए।

PostgreSQL के साथ यह थोड़ा और जटिल है। PostgreSQL के साथ आपको Linux के काम करने के तरीके के बारे में बेहतर समझ होनी चाहिए। और साथ ही लोकोमोटिव के पीछे थोड़ा भागना चाहिए, क्योंकि हाल ही में सब कुछ काफी अच्छी तरह से अपडेट किया गया है। नए कर्नेल जारी किए जाते हैं, और नई कार्यक्षमता दिखाई देती है, प्रदर्शन में सुधार होता है, आदि।

हम लिनक्स के बारे में क्यों बात कर रहे हैं? बिलकुल नहीं क्योंकि हम लिनक्स पीटर सम्मेलन में हैं, बल्कि इसलिए क्योंकि आधुनिक परिस्थितियों में डेटाबेस के साथ और विशेष रूप से PostgreSQL के साथ उपयोग के लिए सबसे उचित ओएस में से एक लिनक्स है। क्योंकि दुर्भाग्य से, FreeBSD कुछ बहुत ही अजीब दिशा में विकसित हो रहा है। और प्रदर्शन और कई अन्य चीजों के साथ समस्याएं होंगी। विंडोज़ पर PostgreSQL का प्रदर्शन एक अलग, गंभीर विषय है, जो इस तथ्य पर आधारित है कि विंडोज़ में UNIX जैसी साझा मेमोरी नहीं है, जबकि PostgreSQL में यह सब है, क्योंकि यह एक बहु-प्रक्रिया प्रणाली है।

और सोलारिस जैसी विदेशी चीजें, मुझे लगता है, हर किसी के लिए कम रुचिकर हैं, इसलिए चलो चलते हैं।

एक आधुनिक लिनक्स वितरण में 1 से अधिक syctl पैरामीटर होते हैं, जो कर्नेल को संकलित करने के तरीके पर निर्भर करता है। साथ ही, अगर हम विभिन्न नट और बोल्ट को देखें, तो चीजों को बदलने के कई और तरीके हैं। फ़ाइल सिस्टम पैरामीटर हैं, माउंट कैसे करें। यदि आपके पास चलाने के तरीके के बारे में प्रश्न हैं: BIOS में क्या सक्षम करना है, हार्डवेयर को कैसे कॉन्फ़िगर करना है, आदि।

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

लिनक्स में पारंपरिक ट्यूनिंग लक्ष्य क्या हैं? मुझे लगता है कि चूंकि आप सभी लिनक्स प्रशासन से निपटते हैं, इसलिए यह समझाने की कोई आवश्यकता नहीं है कि लक्ष्य क्या हैं।

आप ट्यून कर सकते हैं:

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

PostgreSQL और सामान्य रूप से डेटाबेस की विशिष्टता क्या है? समस्या यह है कि आप किसी अलग नट को ट्यून करके यह नहीं देख सकते कि हमारे प्रदर्शन में उल्लेखनीय सुधार हुआ है।

हां, ऐसे नट और बोल्ट हैं, लेकिन डेटाबेस एक जटिल चीज है। यह सर्वर के पास मौजूद सभी संसाधनों के साथ इंटरैक्ट करता है और पूरी तरह से इंटरैक्ट करना पसंद करता है। यदि आप होस्ट ओएस का उपयोग करने के तरीके पर Oracle की वर्तमान अनुशंसाओं को देखें, तो यह उस मंगोलियन अंतरिक्ष यात्री के बारे में मजाक की तरह होगा - कुत्ते को खाना खिलाओ और कुछ भी मत छुओ। हम डेटाबेस को सभी संसाधन देंगे, डेटाबेस खुद ही सब कुछ सुलझा लेगा।

सिद्धांत रूप में, कुछ हद तक स्थिति PostgreSQL के साथ बिल्कुल वैसी ही है। अंतर यह है कि डेटाबेस अभी तक सभी संसाधनों को लेने में सक्षम नहीं है, यानी लिनक्स स्तर पर कहीं न कहीं यह सब स्वतंत्र रूप से सुलझाना आवश्यक है।

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

यहाँ एक चित्र है जो यह समझाता है कि यह क्या है। एक Linux OS बफर है और एक साझा मेमोरी है और PostgreSQL साझा बफर हैं। Oracle के विपरीत, PostgreSQL सीधे कर्नेल बफर के माध्यम से ही काम करता है, यानी डिस्क से किसी पेज को अपनी साझा मेमोरी में जाने के लिए, उसे कर्नेल बफर से होकर वापस जाना होगा, बिल्कुल वही स्थिति।

इस सिस्टम के अंतर्गत लाइव डिस्क हैं। मैंने इसे डिस्क के रूप में बनाया है। वास्तव में इसमें RAID नियंत्रक आदि हो सकते हैं।

और यह इनपुट-आउटपुट, किसी न किसी तरह, इसी मामले के माध्यम से घटित होता है।

PostgreSQL एक क्लासिक डेटाबेस है। इसके अंदर पेज हैं। और सभी इनपुट-आउटपुट पेजों का उपयोग करके किए जाते हैं। हम ब्लॉक को मेमोरी में पेजों का उपयोग करके उठाते हैं। और अगर कुछ नहीं हुआ, तो हम उन्हें बस पढ़ते हैं, फिर धीरे-धीरे वे इस कैश से, साझा बफ़र्स से सिंक हो जाते हैं और डिस्क पर वापस आ जाते हैं।

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

ऐसा क्यों किया जाता है? अगर हमने वोल्टेज खो दिया, तो हमें ऐसी स्थिति नहीं मिली जहां सारा डेटा खो गया। पर्सेंटेंट मेमोरी, जिसके बारे में सभी ने हमें बताया, अभी भी डेटाबेस थ्योरी में है - यह एक उज्ज्वल भविष्य है, जिसके लिए हम, निश्चित रूप से, प्रयास करते हैं और हमें यह पसंद है, लेकिन अभी के लिए वे अभी भी माइनस 20 साल में रहते हैं। और, ज़ाहिर है, इस सब पर नज़र रखने की ज़रूरत है।

और थ्रूपुट को अधिकतम करने का कार्य इन सभी चरणों को ट्यून करना है ताकि यह सब जल्दी से आगे और पीछे हो जाए। साझा मेमोरी मूल रूप से एक पेज कैश है। PostgreSQL में, हमने वहां एक सेलेक्ट क्वेरी भेजी, इसने डिस्क से यह डेटा प्राप्त किया। यह साझा बफ़र्स में चला गया। तदनुसार, इसके बेहतर काम करने के लिए, बहुत सारी मेमोरी होनी चाहिए।

यह सब अच्छी तरह से और जल्दी से काम करने के लिए, आपको सभी चरणों में ऑपरेटिंग सिस्टम को सही ढंग से कॉन्फ़िगर करने की आवश्यकता है। और एक संतुलित हार्डवेयर चुनें, क्योंकि अगर आपके पास कहीं असंतुलन है, तो आप बहुत सारी मेमोरी बना सकते हैं, लेकिन यह पर्याप्त गति से सेवा नहीं करेगा।

आइये इनमें से प्रत्येक बिंदु पर गौर करें।

इन पृष्ठों को तेजी से आगे-पीछे करने के लिए, आपको निम्नलिखित कार्य करने होंगे:

• सबसे पहले, आपको स्मृति के साथ अधिक कुशलता से काम करने की आवश्यकता है।
• दूसरा, यह संक्रमण, जब मेमोरी से पृष्ठ डिस्क पर आते हैं, अधिक कुशल होना चाहिए।
• और तीसरी बात, डिस्क अच्छी होनी चाहिए।

यदि आपके पास 512 जीबी रैम है सर्वर और अगर यह सब बिना किसी कैश के SATA हार्ड ड्राइव पर स्टोर हो जाता है, तो पूरा डेटाबेस सर्वर न सिर्फ बेकार हो जाएगा, बल्कि एक SATA इंटरफेस वाला बेकार सर्वर बन जाएगा। आप वहीं फंस जाएंगे। और कोई भी आपको बचा नहीं पाएगा।

जहां तक ​​स्मृति से संबंधित पहले बिंदु का प्रश्न है, ऐसी तीन चीजें हैं जो जीवन को बहुत कठिन बना सकती हैं।

पहला है NUMA. NUMA एक ऐसी चीज़ है जिसे प्रदर्शन को बेहतर बनाने के लिए डिज़ाइन किया गया है। कार्यभार के आधार पर, आप अलग-अलग चीज़ों को अनुकूलित कर सकते हैं। और अपने मौजूदा स्वरूप में, यह डेटाबेस जैसे अनुप्रयोगों के लिए बहुत अच्छा नहीं है जो पेज कैश और साझा बफ़र्स का गहन उपयोग करते हैं।

संक्षेप में। आपको कैसे पता चलेगा कि NUMA में कुछ गड़बड़ है? आपको किसी तरह की अप्रिय आवाज़ आती है, अचानक कुछ CPU ओवरलोड हो जाता है। उसी समय, आप PostgreSQL में क्वेरीज़ का विश्लेषण करते हैं और देखते हैं कि वहाँ ऐसा कुछ भी नहीं है। इन क्वेरीज़ को CPU का इतना ज़्यादा उपभोग नहीं करना चाहिए। इसे पकड़ने में काफ़ी समय लग सकता है। PostgreSQL के लिए NUMA को कॉन्फ़िगर करने के तरीके के बारे में शुरू से ही सही अनुशंसा का उपयोग करना आसान है।

असल में क्या हो रहा है? NUMA का मतलब है नॉन-यूनिफ़ॉर्म मेमोरी एक्सेस। इसका क्या मतलब है? आपके पास एक CPU है, और उसके बगल में उसकी स्थानीय मेमोरी है। और यह इंटरकनेक्ट मेमोरी दूसरे CPU से मेमोरी खींच सकती है।

यदि आप दौड़ते हैं numactl --hardware, तो आपको इतनी बड़ी शीट मिलेगी। अन्य चीजों के अलावा, एक फ़ील्ड डिस्टेंस होगा। संख्याएँ होंगी - 10-20, कुछ ऐसा ही। ये संख्याएँ इस रिमोट मेमोरी को लेने और स्थानीय रूप से इसका उपयोग करने के लिए हॉप्स की संख्या से अधिक कुछ नहीं हैं। सिद्धांत रूप में, एक अच्छा विचार है। यह कई लोड के तहत प्रदर्शन को अच्छी तरह से गति देता है।

अब कल्पना करें कि आपके पास एक CPU है जो पहले अपनी स्थानीय मेमोरी का उपयोग करने की कोशिश करता है, फिर इंटरकनेक्ट के माध्यम से किसी चीज़ के लिए अन्य मेमोरी खींचने की कोशिश करता है। और यह CPU आपके सभी PostgreSQL पेज कैश को प्राप्त करता है - सब कुछ, कुछ गीगाबाइट्स। आपको हमेशा सबसे खराब स्थिति मिलती है, क्योंकि CPU में आमतौर पर इस मॉड्यूल में बहुत कम मेमोरी होती है। और जो भी मेमोरी सर्विस की जाती है वह इन इंटरकनेक्ट से होकर गुजरती है। यह धीमा और दुखद होता है। और आपका प्रोसेसर जो इस नोड को सर्विस करता है वह लगातार ओवरलोड होता है। और इस मेमोरी का एक्सेस टाइम खराब, धीमा है। यह वह स्थिति है जो आप नहीं चाहते हैं यदि आप इस चीज़ का उपयोग डेटाबेस के लिए कर रहे हैं।

इसलिए, डेटाबेस के लिए एक अधिक सही विकल्प यह है कि लिनक्स ऑपरेटिंग सिस्टम को यह पता ही न चले कि वहां क्या हो रहा है। ताकि वह मेमोरी को उसी तरह एक्सेस कर सके जैसे वह उसे एक्सेस करता है।

ऐसा क्यों है? ऐसा लगता है कि यह इसके विपरीत होना चाहिए। ऐसा एक साधारण कारण से होता है: हमें पेज कैश के लिए बहुत अधिक मेमोरी की आवश्यकता होती है - दसियों, सैकड़ों गीगाबाइट।

और अगर हमने यह सब आवंटित किया और अपना डेटा वहां कैश किया, तो कैश का उपयोग करने से होने वाला लाभ मेमोरी तक इस तरह की मुश्किल पहुंच से होने वाले लाभ से काफी अधिक होगा। और इस प्रकार हम इस तथ्य की तुलना में अतुलनीय रूप से लाभ प्राप्त करेंगे कि हम NUMA का उपयोग करके मेमोरी तक अधिक प्रभावी ढंग से पहुंचेंगे।

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

इसलिए, सही तरीका यह है कि NUMA को पूरी तरह से अक्षम कर दिया जाए।उदाहरण के लिए, रीबूट करते समय। ज़्यादातर मामलों में, लाभ इतने बड़े होते हैं कि सबसे अच्छा क्या है, इस बारे में कोई सवाल ही नहीं उठता।

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

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

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

किसी आपातकालीन स्थिति में, जब सब कुछ वाकई बहुत खराब हो, आपका फोन लगातार बज रहा हो और आपका बॉस बड़ी सी छड़ी लेकर दौड़ रहा हो, तो आपके पास जांच करने के बारे में सोचने का समय नहीं होगा। और परिणाम बहुत ही भयावह हो सकते हैं।

अगला बिंदु विशाल पृष्ठों का है। विशाल पृष्ठों को अलग से परीक्षण करना मुश्किल है, और ऐसा करने का कोई मतलब नहीं है, हालांकि ऐसे बेंचमार्क हैं जो ऐसा कर सकते हैं। उन्हें गूगल पर खोजना आसान है।

इसका क्या मतलब है? आपके पास बहुत महंगा सर्वर नहीं है, जिसमें बहुत ज़्यादा RAM है, उदाहरण के लिए, 30 GB से ज़्यादा। आप बहुत ज़्यादा पेज इस्तेमाल नहीं करते। इसका मतलब है कि आपके पास मेमोरी इस्तेमाल में निश्चित रूप से ओवरहेड है। और यह ओवरहेड सबसे सुखद से बहुत दूर है।

ऐसा क्यों है? और क्या हो रहा है? ऑपरेटिंग सिस्टम मेमोरी को छोटे-छोटे हिस्सों में आवंटित करता है। यह सुविधाजनक है, यह ऐतिहासिक रूप से ऐसा ही रहा है। और अगर हम विस्तार से देखें, तो OS को वर्चुअल एड्रेस को फिजिकल एड्रेस में बदलना पड़ता है। और यह प्रक्रिया सबसे आसान नहीं है, इसलिए OS इस ऑपरेशन के परिणाम को ट्रांसलेशन लुकसाइड बफर (TLB) में कैश करता है।

और चूंकि TLB एक कैश है, इसलिए कैश में निहित सभी समस्याएं ऐसी स्थिति में उत्पन्न होती हैं। सबसे पहले, यदि आपके पास बहुत अधिक RAM है और यह सभी छोटे-छोटे हिस्सों में आवंटित है, तो यह बफर बहुत बड़ा हो जाता है। और यदि कैश बड़ा है, तो इसके माध्यम से खोज धीमी होती है। ओवरहेड स्वस्थ है और यह खुद ही जगह लेता है, यानी RAM किसी गलत चीज़ द्वारा खपत की जाती है। यह एक है।

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

और यहां यह ध्यान दिया जाना चाहिए कि विशाल पृष्ठों का विचार, एक विचार के रूप में, शुरू में उन समुदायों द्वारा आगे बढ़ाया गया था जिनमें ओरेकल और आईबीएम शामिल थे, यानी डेटाबेस निर्माता इस तथ्य के बारे में गंभीरता से सोच रहे थे कि यह डेटाबेस के लिए भी उपयोगी होगा।

और PostgreSQL से दोस्ती कैसे करें? सबसे पहले, लिनक्स कर्नेल में विशाल पेज सक्षम होना चाहिए।

दूसरा, उन्हें sysctl पैरामीटर द्वारा स्पष्ट रूप से निर्दिष्ट किया जाना चाहिए - उनमें से कितने हैं। यहाँ संख्याएँ कुछ पुराने सर्वर से हैं। आप गणना कर सकते हैं कि आपके पास कितने साझा बफ़र्स हैं, ताकि विशाल पृष्ठ वहाँ फ़िट हो सकें।

और अगर आपके पास PostgreSQL के लिए समर्पित पूरा सर्वर है, तो एक अच्छा शुरुआती बिंदु या तो 25% RAM को साझा बफ़र्स के लिए है, या 75%, अगर आपको यकीन है कि आपका डेटाबेस निश्चित रूप से इन 75% में फिट होगा। पहला शुरुआती बिंदु। और मान लें कि अगर आपके पास 256 जीबी रैम है, तो, तदनुसार, आपके पास 64 जीबी साझा बफ़र्स होंगे। कुछ रिजर्व के साथ लगभग गणना करें - यह आंकड़ा किस पर सेट किया जाना चाहिए।

संस्करण 9.2 से पहले (अगर मैं गलत नहीं हूँ, तो संस्करण 8.2 के बाद से), आप PostgreSQL को विशाल पृष्ठों के साथ काम करने के लिए किसी तृतीय-पक्ष लाइब्रेरी का उपयोग कर सकते थे। और आपको हमेशा ऐसा करना होगा। सबसे पहले, आपको कर्नेल को विशाल पृष्ठों को सही ढंग से आवंटित करने में सक्षम होना चाहिए। और दूसरा, आपको उनके साथ काम करने वाले एप्लिकेशन को उनका उपयोग करने में सक्षम होना चाहिए। यह सिर्फ़ उनका उपयोग नहीं करेगा। चूंकि PostgreSQL ने सिस्टम 5 शैली में मेमोरी आवंटित की है, इसलिए यह libhugetlbfs का उपयोग करके किया जा सकता है - यह लाइब्रेरी का पूरा नाम है।

9.3 में, उन्होंने मेमोरी के साथ काम करते समय PostgreSQL के प्रदर्शन में सुधार किया और मेमोरी आवंटित करने की सिस्टम 5 विधि को छोड़ दिया। हर कोई बहुत खुश था, क्योंकि अन्यथा आप एक मशीन पर दो PostgreSQL इंस्टेंस चलाने की कोशिश करते हैं, और यह कहता है कि मेरे पास पर्याप्त साझा मेमोरी नहीं है। और यह कहता है कि मुझे sysctl को ठीक करने की आवश्यकता है। और ऐसा sysctl है जिसे आपको रीबूट करने की भी आवश्यकता है, आदि। सामान्य तौर पर, हर कोई खुश था। लेकिन mmap मेमोरी के आवंटन ने विशाल पृष्ठों के उपयोग को तोड़ दिया। हमारे अधिकांश क्लाइंट बड़े साझा बफ़र्स का उपयोग करते हैं। और हमने दृढ़ता से 9.3 पर स्विच न करने की सिफारिश की, क्योंकि वहाँ ओवरहेड की गणना अच्छे प्रतिशत में की जाने लगी।

लेकिन समुदाय ने इस समस्या पर ध्यान दिया और 9.4 में इस घटना को बहुत अच्छी तरह से फिर से तैयार किया गया। और 9.4 में postgresql.conf में एक पैरामीटर दिखाई दिया, जिसमें आप try को चालू या बंद कर सकते हैं।

Try सबसे सुरक्षित विकल्प है। जब PostgreSQL शुरू होता है, जब यह साझा मेमोरी आवंटित करता है, तो यह विशाल पृष्ठों से इस मेमोरी को हथियाने की कोशिश करता है। और अगर यह विफल हो जाता है, तो यह सामान्य आवंटन पर वापस आ जाता है। और अगर आपके पास FreeBSD या Solaris है, तो आप try सेट कर सकते हैं, यह हमेशा सुरक्षित रहता है।

यदि चालू है, तो यह बस शुरू नहीं होता है यदि यह विशाल पृष्ठों से आवंटित नहीं हो सकता है। यहाँ यह पहले से ही है - किसके लिए और क्या अधिक सुखद है। लेकिन अगर आपने कोशिश की है, तो जांचें कि क्या आपने वास्तव में वह आवंटित किया है जिसकी आपको आवश्यकता है, क्योंकि त्रुटि के लिए कई स्थान हैं। अब यह कार्यक्षमता केवल लिनक्स पर काम करती है।

आगे बढ़ने से पहले एक और छोटी सी टिप्पणी। पारदर्शी विशाल पृष्ठ अभी PostgreSQL के बारे में नहीं हैं। यह उन्हें सामान्य रूप से उपयोग नहीं कर सकता है। और इस तरह के कार्यभार के लिए पारदर्शी विशाल पृष्ठों के साथ, जब साझा मेमोरी के एक बड़े हिस्से की आवश्यकता होती है, तो लाभ केवल बहुत बड़ी मात्रा के साथ आते हैं। यदि आपके पास टेराबाइट्स मेमोरी है, तो यह एक भूमिका निभा सकता है। यदि हम अधिक रोजमर्रा के अनुप्रयोगों के बारे में बात कर रहे हैं, जब आपके पास मशीन पर 32, 64, 128, 256 जीबी मेमोरी है, तो नियमित विशाल पृष्ठ ठीक हैं, और पारदर्शी बस अक्षम है।

और मेमोरी के बारे में आखिरी बात सीधे फ्रूटट से संबंधित नहीं है, यह वास्तव में आपके जीवन को खराब कर सकती है। सर्वर के लगातार स्वैपिंग से पूरे बैंडविड्थ को बहुत नुकसान होगा।

और यह कई क्षणों में बहुत अप्रिय होगा। और मुख्य अप्रियता यह है कि आधुनिक कर्नेल पुराने लिनक्स कर्नेल से थोड़ा अलग व्यवहार करते हैं। और यह बात, जिस पर कदम रखना काफी अप्रिय है, क्योंकि जब हम स्वैप के साथ कुछ काम के बारे में बात करते हैं, तो यह OOM-किलर के असामयिक आगमन के साथ समाप्त होता है। और OOM-किलर, जो समय पर नहीं आया और PostgreSQL को डंप कर दिया, अप्रिय है। हर कोई इसके बारे में जानेगा, यानी आखिरी उपयोगकर्ता तक।

क्या हो रहा है? आपके पास बहुत ज़्यादा RAM है, सब कुछ ठीक काम कर रहा है। लेकिन किसी कारण से सर्वर स्वैप में हैंग हो जाता है और इसकी वजह से धीमा हो जाता है। ऐसा लगता है कि बहुत ज़्यादा मेमोरी है, लेकिन ऐसा ही होता है।

पहले, हमने vm.swappiness को शून्य पर सेट करने की सलाह दी थी, यानी स्वैप को अक्षम करना। पहले, ऐसा लगता था कि 32 जीबी रैम और संबंधित साझा बफ़र्स एक बड़ी राशि थी। स्वैप का मुख्य उद्देश्य यह था कि अगर हम गिर गए तो क्रस्ट को फेंकने के लिए एक जगह हो। और यह अब वास्तव में पूरा नहीं हुआ। और आप बाद में इस क्रस्ट के साथ क्या करेंगे? यह पहले से ही एक कार्य है जब यह बहुत स्पष्ट नहीं है कि स्वैप की आवश्यकता क्यों है, विशेष रूप से इस तरह के आकार का।

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

इसलिए, अब डिफ़ॉल्ट, जहां तक ​​मुझे याद है, अधिकांश वितरणों के लिए 6 के आसपास है, यानी स्वैप का उपयोग किस बिंदु पर शुरू करना है यह इस बात पर निर्भर करता है कि कितनी मेमोरी शेष है। अब हम vm.swappiness = 1 सेट करने की अनुशंसा करते हैं, क्योंकि यह व्यावहारिक रूप से इसे बंद कर देता है, लेकिन यह वैसा प्रभाव नहीं देता जैसा अप्रत्याशित रूप से आने वाले OOM-किलर के साथ होता है जो पूरी चीज को नष्ट कर देता है।

आगे क्या? जब हम डेटाबेस के प्रदर्शन के बारे में बात करते हैं और धीरे-धीरे डिस्क की ओर बढ़ते हैं, तो हर कोई अपना सिर पकड़ना शुरू कर देता है। क्योंकि यह सच है कि डिस्क धीमी है और मेमोरी तेज़ है, यह हर कोई बचपन से जानता है। और हर कोई जानता है कि डेटाबेस में डिस्क प्रदर्शन के साथ समस्याएँ होंगी।

चेकपॉइंट स्पाइक्स से संबंधित मुख्य PostgreSQL प्रदर्शन समस्या इसलिए नहीं है क्योंकि डिस्क धीमी है। बल्कि, यह इसलिए है क्योंकि मेमोरी और डिस्क बैंडविड्थ संतुलित नहीं हैं। और वे अलग-अलग जगहों पर असंतुलित हो सकते हैं। PostgreSQL कॉन्फ़िगर नहीं है, OS कॉन्फ़िगर नहीं है, हार्डवेयर कॉन्फ़िगर नहीं है, और हार्डवेयर गलत है। और यह समस्या केवल तभी नहीं होती है जब सब कुछ वैसा ही चल रहा हो जैसा होना चाहिए, यानी या तो कोई लोड नहीं है, या सेटिंग्स और हार्डवेयर अच्छी तरह से चुने गए हैं।

यह क्या है और यह कैसा दिखता है? आमतौर पर PostgreSQL के साथ काम करने वाले लोगों ने एक से अधिक बार इसका सामना किया है। मुझे समझाएं। जैसा कि मैंने कहा, PostgreSQL समय-समय पर साझा मेमोरी में गंदे पृष्ठों को डिस्क पर डंप करने के लिए चेकपॉइंट बनाता है। यदि हमारे पास साझा मेमोरी की बड़ी मात्रा है, तो चेकपॉइंट डिस्क को तीव्रता से प्रभावित करना शुरू कर देता है, क्योंकि fsync इन पृष्ठों को डंप करता है। यह कर्नेल बफर में आता है और fsync का उपयोग करके डिस्क पर लिखा जाता है। और अगर इस मामले की मात्रा बड़ी है, तो हम एक अप्रिय प्रभाव देख सकते हैं, अर्थात्, डिस्क का बहुत बड़ा उपयोग।

यहाँ मेरे पास दो चित्र हैं। मैं समझाता हूँ कि वे क्या हैं। ये दो समय-सहसंबद्ध ग्राफ़ हैं। पहला ग्राफ़ डिस्क उपयोग है। यहाँ यह इस समय लगभग 90% तक पहुँच जाता है। यदि आपके पास भौतिक डिस्क के साथ डेटाबेस विफलता है, RAID नियंत्रक के साथ, उपयोग 90% से कम है, तो यह बुरी खबर है। इसका मतलब है कि थोड़ा और और यह 100 तक पहुँच जाएगा और इनपुट-आउटपुट बंद हो जाएगा।

अगर आपके पास डिस्क ऐरे है, तो यह थोड़ी अलग कहानी है। यह इस बात पर निर्भर करता है कि इसे कैसे कॉन्फ़िगर किया गया है, यह किस तरह का ऐरे है, आदि।

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

इस समस्या को दूर करने के लिए क्या किया जाना चाहिए? यदि डेटाबेस के अंतर्गत आपका IO बंद हो गया है, तो इसका मतलब है कि अपने अनुरोधों को निष्पादित करने के लिए आने वाले सभी उपयोगकर्ता प्रतीक्षा करेंगे।

यदि आप इसे लिनक्स के दृष्टिकोण से देखें, यदि आपने अच्छा हार्डवेयर लिया, इसे सही तरीके से कॉन्फ़िगर किया, PostgreSQL को सामान्य रूप से कॉन्फ़िगर किया ताकि यह इन चेकपॉइंट्स को कम बार बनाए, उन्हें एक दूसरे के बीच समय के साथ फैलाए, तो आप डिफ़ॉल्ट डेबियन मापदंडों में कदम रख रहे हैं। अधिकांश लिनक्स वितरणों के लिए, यह चित्र है: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

इसका क्या मतलब है? कर्नेल 2.6 के बाद से, एक फ्लशिंग दानव दिखाई दिया है। Pdglush, इस बात पर निर्भर करता है कि कौन किसका उपयोग करता है, जो कर्नेल बफर से गंदे पृष्ठों की पृष्ठभूमि फ्लशिंग में लगा हुआ है और फ्लशिंग, जब किसी भी कीमत पर गंदे पृष्ठों को फ्लश करना आवश्यक होता है, जब पृष्ठभूमि फ्लशिंग मदद नहीं करती है।

बैकग्राउंड कब होता है? जब सर्वर पर मौजूद सभी RAM का 10% हिस्सा कर्नेल बफर में गंदे पेजों द्वारा कब्जा कर लिया जाता है, तो बैकग्राउंड में एक विशेष राइट-ऑफ फ़ंक्शन को कॉल किया जाता है। यह बैकग्राउंड क्यों होता है? यह एक पैरामीटर के रूप में लेता है कि कितने पेज राइट ऑफ करने हैं। और, मान लीजिए, यह N पेज राइट ऑफ करता है। और कुछ समय के लिए यह चीज़ सो जाती है। और फिर यह वापस आता है और कुछ और पेज राइट ऑफ करता है।

यह एक बहुत ही सरल कहानी है। यहाँ समस्या स्विमिंग पूल की तरह है, जब कोई चीज़ एक पाइप में और दूसरी में जाती है। हमारे पास एक चेकपॉइंट है और अगर यह रीसेट के लिए कुछ गंदे पेज भेजता है, तो धीरे-धीरे कर्नेल बफर pgflush से यह पूरी बात बड़े करीने से हल हो जाएगी।

अगर ये गंदे पेज लगातार जमा होते रहें, तो ये 20% तक जमा हो जाते हैं, उसके बाद OS की प्राथमिकता इन सभी चीजों को डिस्क पर लिखना है, क्योंकि बिजली चली जाएगी, और हमारे लिए सब कुछ खराब हो जाएगा। उदाहरण के लिए, हम यह डेटा खो देंगे।

चाल क्या है? चाल यह है कि आधुनिक दुनिया में ये पैरामीटर, मशीन पर मौजूद सभी RAM का 20 और 10%, आपके पास मौजूद किसी भी डिस्क सिस्टम के थ्रूपुट के मामले में बिल्कुल राक्षसी हैं।

कल्पना करें कि आपके पास 128 जीबी रैम है। 12,8 जीबी आपके डिस्क सिस्टम में आता है। और चाहे आपके पास कोई भी कैश हो, चाहे आपके पास कोई भी सरणी हो, वे इतना संभाल नहीं पाएंगे।

इसलिए, हम अनुशंसा करते हैं कि आप अपने RAID नियंत्रक की क्षमताओं के आधार पर इन नंबरों को तुरंत कॉन्फ़िगर करें। मेरे पास एक नियंत्रक के लिए एक सिफारिश है जिसमें 512 एमबी कैश है।

यह सब गणना करना बहुत आसान है। आप vm.dirty_background को बाइट्स में सेट कर सकते हैं। और ये सेटिंग पिछले दो को रद्द कर देती हैं। या तो अनुपात डिफ़ॉल्ट रूप से होता है, या बाइट्स वाले सक्रिय होते हैं, तो बाइट्स वाले काम करेंगे। लेकिन चूंकि मैं एक DBA सलाहकार हूँ और अलग-अलग क्लाइंट के साथ काम करता हूँ, इसलिए मैं स्ट्रॉ लगाने की कोशिश करता हूँ और इसलिए, अगर बाइट्स में है, तो बाइट्स में। किसी ने कोई गारंटी नहीं दी कि एक दयालु व्यवस्थापक सर्वर में मेमोरी नहीं जोड़ेगा, इसे रीबूट करेगा, और आंकड़ा वही रहेगा। बस इन आंकड़ों की गणना करें ताकि सब कुछ गारंटी के साथ वहाँ फिट हो जाए।

अगर आप फिट नहीं होते तो क्या होता है? मैंने लिखा है कि कोई भी फ्लशिंग प्रभावी रूप से बंद हो जाती है, लेकिन वास्तव में यह एक अलंकार है। ऑपरेटिंग सिस्टम में एक बड़ी समस्या है - इसमें बहुत सारे गंदे पेज हैं, इसलिए आपके क्लाइंट द्वारा जेनरेट किया गया IO प्रभावी रूप से बंद हो जाता है, यानी एक एप्लीकेशन डेटाबेस को SQL क्वेरी भेजने के लिए आता है, यह प्रतीक्षा करता है। इसमें कोई भी इनपुट-आउटपुट सबसे कम प्राथमिकता में होता है, क्योंकि डेटाबेस एक चेकपॉइंट के साथ व्यस्त होता है। और यह कब खत्म होगा यह पूरी तरह से अस्पष्ट है। और जब आप नॉन-बैकग्राउंड फ्लशिंग पर पहुँच जाते हैं, तो इसका मतलब है कि आपका पूरा IO इसके द्वारा कब्जा कर लिया गया है। और जब तक यह खत्म नहीं हो जाता, आप कुछ नहीं कर सकते।

यहाँ दो और महत्वपूर्ण बिंदु हैं जो इस रिपोर्ट के दायरे से बाहर हैं। ये सेटिंग्स postgresql.conf में सेटिंग्स से मेल खानी चाहिए, यानी चेकपॉइंट सेटिंग्स। और आपका डिस्क सिस्टम पर्याप्त रूप से कॉन्फ़िगर किया हुआ होना चाहिए। यदि आपके पास RAID कैश है, तो उसमें बैटरी होनी चाहिए। लोग बिना बैटरी वाले अच्छे कैश वाले RAID खरीदते हैं। यदि आपके पास RAID में SSD हैं, तो वे सर्वर वाले होने चाहिए, उनमें कैपेसिटर होने चाहिए। यहाँ एक विस्तृत चेकलिस्ट है। इस लिंक में PostgreSQL में डिस्क प्रदर्शन को कॉन्फ़िगर करने के तरीके पर मेरी रिपोर्ट है। ये सभी चेकलिस्ट वहाँ हैं।

और क्या है जो जीवन को बहुत मुश्किल बना सकता है? ये दो सेटिंग्स हैं। वे अपेक्षाकृत नए हैं। उन्हें विभिन्न अनुप्रयोगों में डिफ़ॉल्ट रूप से सक्षम किया जा सकता है। और अगर उन्हें गलत तरीके से सक्षम किया जाता है तो वे जीवन को कम जटिल नहीं बना सकते हैं।

दो अपेक्षाकृत नई चीजें हैं। वे पहले से ही तीसरे कर्नेल में दिखाई दे चुकी हैं। ये हैं नैनोसेकंड में sched_migration_cost और sched_autogroup_enabled, जो डिफ़ॉल्ट है।

और वे जीवन को कैसे बर्बाद करते हैं? sched_migration_cost क्या है? लिनक्स शेड्यूलर एक प्रक्रिया को एक CPU से दूसरे CPU में माइग्रेट कर सकता है। और PostgreSQL के लिए, जो क्वेरीज़ निष्पादित करता है, यह पूरी तरह से अस्पष्ट है कि उसे दूसरे CPU में माइग्रेट करने की आवश्यकता क्यों है। ऑपरेटिंग सिस्टम के दृष्टिकोण से, जब आप ओपनऑफ़िस और टर्मिनल के बीच विंडोज़ स्विच करते हैं, तो यह अच्छा हो सकता है, लेकिन डेटाबेस के लिए, यह बहुत बुरा है. इसलिए एक उचित नीति यह है कि migration_cost को कुछ बड़े मान पर सेट किया जाए, कम से कम कुछ हजार नैनोसेकंड पर।

शेड्यूलर के लिए इसका क्या मतलब होगा? यह इस बात पर विचार करेगा कि इस दौरान यह प्रक्रिया अभी भी गर्म है। यानी अगर आपके पास कोई लंबा लेनदेन है जो लंबे समय से कुछ कर रहा है, तो शेड्यूलर इसे समझ जाएगा। यह इस बात पर विचार करेगा कि जब तक यह समय समाप्त नहीं हो जाता, तब तक इस प्रक्रिया को कहीं भी माइग्रेट करने की आवश्यकता नहीं है। अगर प्रक्रिया कुछ कर रही है, तो इसे कहीं भी माइग्रेट नहीं किया जाएगा, यह चुपचाप उस CPU पर काम करेगा जो इसे आवंटित किया गया था। और परिणाम उत्कृष्ट है।

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

मेरे सहकर्मी एलेक्सी लेसोव्स्की ने एक सरल पीजीबेंच के साथ परीक्षण किया, जहां उन्होंने माइग्रेशन_कॉस्ट को एक परिमाण के क्रम से बढ़ा दिया और ऑटोग्रुप को बंद कर दिया। खराब हार्डवेयर पर अंतर लगभग 10% थापोस्टग्रेज मेलिंग सूची पर एक चर्चा चल रही है, जिसमें लोग क्वेरी गति में इसी प्रकार के परिवर्तन के परिणामों का हवाला दे रहे हैं। 50% प्रभावितऐसी कई कहानियाँ हैं।

और अंत में, बिजली बचत नीति के बारे में। यह अच्छी बात है कि अब लिनक्स का इस्तेमाल लैपटॉप पर किया जा सकता है। और माना जाता है कि यह बैटरी का अच्छा इस्तेमाल करेगा। लेकिन अचानक पता चलता है कि यह सर्वर पर भी हो सकता है।

इसके अलावा, यदि आप किसी होस्टिंग प्रदाता से सर्वर किराए पर लेते हैं, तो यह "अच्छी बात" है। होस्टर उन्हें आपके प्रदर्शन की परवाह नहीं है। उनका काम यह सुनिश्चित करना है कि उनके हार्डवेयर का उपयोग यथासंभव कुशलता से हो। इसीलिए वे ऑपरेटिंग सिस्टम में लैपटॉप की तरह पावर-सेविंग मोड को डिफ़ॉल्ट रूप से सक्षम कर सकते हैं।

यदि आप इस सामान का उपयोग गहन लोड के तहत डेटाबेस वाले सर्वर पर करते हैं, तो आपका विकल्प acpi_cpufreq + permormance है। ऑनडिमांड के साथ भी समस्याएँ होंगी।

Intel_pstate थोड़ा अलग ड्राइवर है। और अब इसे प्राथमिकता दी जाती है, क्योंकि यह बाद में और बेहतर काम करने वाला ड्राइवर है।

और, तदनुसार, गवर्नर केवल प्रदर्शन है। ऑनडिमांड, पावरसेव और बाकी सब आपके बारे में नहीं है।

यदि आप पावरसेव को सक्षम करते हैं, तो PostgreSQL के परिणाम कई क्रमों से भिन्न हो सकते हैं, क्योंकि व्यवहार में आपके डेटाबेस में CPU शेड्यूलिंग पूरी तरह से अप्रत्याशित तरीके से होगी।

ये चीज़ें डिफ़ॉल्ट रूप से चालू हो सकती हैं। ध्यान से देखें कि क्या वे डिफ़ॉल्ट रूप से चालू हैं। यह वाकई एक बड़ी समस्या हो सकती है।

और अंत में, मैं हमारी DBA टीम PosgreSQL-Consulting के लोगों को धन्यवाद देना चाहता हूँ, अर्थात् मैक्स बोगुक और एलेक्सी लेसोव्स्की, जो हर दिन इस व्यवसाय में अपनी भूमिका निभाते हैं। और अपने ग्राहकों के लिए, हम अपना सर्वश्रेष्ठ करने की कोशिश करते हैं ताकि यह सब उनके लिए काम करे। यह विमानन सुरक्षा निर्देशों की तरह है। यहाँ सब कुछ खून से लिखा हुआ है। इनमें से प्रत्येक नट और बोल्ट किसी समस्या की प्रक्रिया में खोजे गए थे। मुझे उन्हें आपके साथ साझा करने में खुशी हो रही है।

प्रश्न:

धन्यवाद! उदाहरण के लिए, यदि कोई कंपनी पैसे बचाना चाहती है और डेटाबेस और एप्लिकेशन लॉजिक को एक सर्वर पर रखना चाहती है, या यदि कोई कंपनी माइक्रोसर्विस आर्किटेक्चर के फैशनेबल ट्रेंड का अनुसरण करती है, जिसमें PostgreSQL को कंटेनर में लॉन्च किया जाता है। चाल क्या है? Sysctl वैश्विक स्तर पर पूरे कर्नेल को प्रभावित करता है। मैंने sysctl को किसी तरह वर्चुअलाइज़ किए जाने के बारे में नहीं सुना है, ताकि वे कंटेनर पर अलग-अलग काम करें। केवल cgroup है और केवल एक हिस्से के लिए नियंत्रण है। आप इसके साथ कैसे रह सकते हैं? या यदि आप प्रदर्शन चाहते हैं, तो PostgreSQL को एक अलग हार्डवेयर सर्वर पर लॉन्च करें और इसे ट्यून करें?

हमने आपके सवाल का जवाब लगभग तीन तरीकों से दिया है। अगर हम हार्डवेयर सर्वर के बारे में बात नहीं कर रहे हैं जिसे ट्यून किया जा सकता है, तो चिंता न करें, इन सेटिंग्स के बिना भी सब कुछ ठीक चलेगा। अगर आपके पास इतना लोड है कि आपको ये सेटिंग्स करने की ज़रूरत है, तो आप इन सेटिंग्स से पहले हार्डवेयर सर्वर पर आ जाएँगे।

समस्या क्या है? यदि यह एक वर्चुअल मशीन है, तो सबसे अधिक संभावना है कि आपको बहुत सारी समस्याएं होंगी, उदाहरण के लिए, इस तथ्य के साथ कि अधिकांश वर्चुअल मशीनों में काफी असंगत डिस्क विलंबता होती है। भले ही डिस्क थ्रूपुट अच्छा हो, फिर भी एक विफल I/O लेनदेन जो औसत थ्रूपुट को बहुत प्रभावित नहीं करता है, जो चेकपॉइंट पर या WAL को लिखते समय हुआ, डेटाबेस को इससे बहुत नुकसान होगा। और आप इन समस्याओं में पड़ने से पहले इसे नोटिस करेंगे।

यदि आपके पास एक ही सर्वर पर NGINX है, तो आपको भी यही समस्या होगी। यह साझा मेमोरी के लिए संघर्ष करेगा। और आपको यहाँ वर्णित समस्याएँ नहीं मिलेंगी।

लेकिन दूसरी ओर, इनमें से कुछ पैरामीटर अभी भी आपके लिए प्रासंगिक होंगे। उदाहरण के लिए, sysctl के साथ dirty_ratio सेट करें ताकि यह इतना पागल न हो - किसी भी मामले में, यह मदद करेगा। एक तरह से या किसी अन्य, आप डिस्क के साथ बातचीत करेंगे। और यह गलत योजना के अनुसार होगा। ये आम तौर पर डिफ़ॉल्ट पैरामीटर हैं जो मैंने दिखाए हैं। और किसी भी मामले में, उन्हें बदलना बेहतर है।

और NUMA के साथ समस्याएँ हो सकती हैं। उदाहरण के लिए, VmWare, NUMA के साथ बिल्कुल विपरीत सेटिंग्स के साथ अच्छी तरह से काम करता है। और यहाँ आपको चुनना होगा - हार्डवेयर सर्वर या नहीं।

मेरे पास Amazon AWS से संबंधित एक प्रश्न है। उनके पास पहले से कॉन्फ़िगर की गई छवियाँ हैं। उनमें से एक को Amazon RDS कहा जाता है। क्या उनके ऑपरेटिंग सिस्टम के लिए कोई कस्टम सेटिंग हैं?

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

पारदर्शी विशाल पृष्ठ विशाल TLB की तुलना में कोई प्रभाव क्यों नहीं देते?

वे नहीं करते। इसे समझाने के कई तरीके हैं। लेकिन वास्तव में, वे इसे देते ही नहीं। PostgreSQL के साथ कहानी क्या है? यह स्टार्टअप पर साझा मेमोरी का एक बड़ा हिस्सा आवंटित करता है। वे पारदर्शी हैं या नहीं, यह पूरी तरह से महत्वहीन है। तथ्य यह है कि उन्हें स्टार्टअप पर आवंटित किया जाता है, सब कुछ समझाता है। और अगर बहुत सारी मेमोरी है और आपको shared_memory सेगमेंट को फिर से बनाने की आवश्यकता है, तो पारदर्शी विशाल पृष्ठ प्रासंगिक होंगे। PostgreSQL में, इसे स्टार्टअप पर एक विशाल हिस्से के रूप में आवंटित किया जाता है और बस इतना ही, और वहाँ कुछ खास नहीं होता है। बेशक, आप इसका उपयोग कर सकते हैं, लेकिन जब यह कुछ पुनः आवंटित करता है तो shared_memory भ्रष्टाचार होने की संभावना है। PostgreSQL को इसके बारे में पता नहीं है।

स्रोत: www.habr.com