इल्या कोस्मोडेमेन्स्की की 2015 की रिपोर्ट की प्रतिलेख "पोस्टग्रेएसक्यूएल प्रदर्शन को बेहतर बनाने के लिए लिनक्स ट्यूनिंग"
अस्वीकरण: मैंने नोट किया है कि यह रिपोर्ट नवंबर 2015 की है - 4 साल से अधिक समय बीत चुका है और बहुत समय बीत चुका है। रिपोर्ट में चर्चा किया गया संस्करण 9.4 अब समर्थित नहीं है। पिछले 4 वर्षों में, PostgreSQL की 5 नई रिलीज़ जारी की गई हैं, और Linux कर्नेल के 15 संस्करण जारी किए गए हैं। यदि आप इन अंशों को दोबारा लिखते हैं, तो आपके पास एक अलग रिपोर्ट होगी। लेकिन यहां हम PostgreSQL के लिए मौलिक लिनक्स ट्यूनिंग पर विचार करते हैं, जो आज भी प्रासंगिक है।
मेरा नाम इल्या कोस्मोडेमेन्स्की है। मैं PostgreSQL-Consulting पर काम करता हूं। और अब मैं सामान्य रूप से डेटाबेस और विशेष रूप से PostgreSQL के संबंध में लिनक्स के साथ क्या करना है, इसके बारे में थोड़ी बात करूंगा, क्योंकि सिद्धांत काफी समान हैं।
हम किस बारे में बात करेंगे? यदि आप PostgreSQL के साथ संचार करते हैं, तो कुछ हद तक आपको UNIX व्यवस्थापक होने की आवश्यकता है। इसका मतलब क्या है? अगर हम Oracle और PostgreSQL की तुलना करें तो Oracle में आपको 80% DBA डेटाबेस एडमिन और 20% Linux एडमिन होना चाहिए।
PostgreSQL के साथ यह थोड़ा अधिक जटिल है। PostgreSQL के साथ आपको लिनक्स कैसे काम करता है इसकी बेहतर समझ होनी चाहिए। और साथ ही, लोकोमोटिव के पीछे थोड़ा दौड़ें, क्योंकि हाल ही में सब कुछ काफी अच्छे से अपडेट किया गया है। और नए कर्नेल जारी किए जाते हैं, और नई कार्यक्षमता प्रकट होती है, प्रदर्शन में सुधार होता है, आदि।
हम लिनक्स के बारे में क्यों बात कर रहे हैं? बिल्कुल नहीं क्योंकि हम लिनक्स सम्मेलन पीटर में हैं, बल्कि इसलिए कि आधुनिक परिस्थितियों में सामान्य रूप से डेटाबेस और विशेष रूप से PostgreSQL का उपयोग करने के लिए सबसे उचित ऑपरेटिंग सिस्टम में से एक लिनक्स है। क्योंकि FreeBSD, दुर्भाग्य से, कुछ बहुत ही अजीब दिशा में विकसित हो रहा है। और प्रदर्शन के साथ-साथ कई अन्य चीज़ों में भी समस्याएँ होंगी। विंडोज़ पर PostgreSQL का प्रदर्शन आम तौर पर एक अलग गंभीर मुद्दा है, इस तथ्य पर आधारित है कि विंडोज़ में UNIX के समान साझा मेमोरी नहीं है, जबकि PostgreSQL सभी इससे जुड़ा हुआ है, क्योंकि यह एक बहु-प्रक्रिया प्रणाली है।
और मुझे लगता है कि हर किसी को सोलारिस जैसी विदेशी चीज़ों में कम दिलचस्पी है, तो चलिए चलते हैं।
एक आधुनिक लिनक्स वितरण में 1 से अधिक syctl विकल्प होते हैं, यह इस बात पर निर्भर करता है कि आप कर्नेल कैसे बनाते हैं। वहीं, अगर हम अलग-अलग नट्स को देखें तो हम किसी चीज को कई तरह से एडजस्ट कर सकते हैं। उन्हें माउंट करने के तरीके पर फ़ाइल सिस्टम पैरामीटर हैं। यदि आपके पास इसे शुरू करने के तरीके के बारे में प्रश्न हैं: BIOS में क्या सक्षम करना है, हार्डवेयर को कैसे कॉन्फ़िगर करना है, आदि।
यह एक बहुत बड़ी मात्रा है जिस पर कई दिनों तक चर्चा की जा सकती है, और एक छोटी रिपोर्ट में नहीं, लेकिन अब मैं महत्वपूर्ण चीजों पर ध्यान केंद्रित करूंगा, उन रेक से कैसे बचें जो आपको लिनक्स पर अपने डेटाबेस का अच्छी तरह से उपयोग करने से रोकने की गारंटी देते हैं यदि आप उन्हें ठीक मत करो. और साथ ही, एक महत्वपूर्ण बात यह है कि सेटिंग्स में कई डिफ़ॉल्ट पैरामीटर शामिल नहीं हैं जो डेटाबेस के लिए सही हैं। यानी डिफ़ॉल्ट रूप से यह खराब काम करेगा या बिल्कुल भी नहीं करेगा।
लिनक्स में कौन से पारंपरिक ट्यूनिंग लक्ष्य हैं? मुझे लगता है कि चूंकि आप सभी लिनक्स प्रशासन से निपट रहे हैं, इसलिए यह समझाने की कोई विशेष आवश्यकता नहीं है कि लक्ष्य क्या हैं।
आप ट्यून कर सकते हैं:
- सी पी यू।
- याद।
- भंडारण।
- अन्य। हम अंत में अल्पाहार के लिए इस बारे में बात करेंगे। उदाहरण के लिए, ऊर्जा बचत नीति जैसे पैरामीटर भी प्रदर्शन को बहुत अप्रत्याशित और सबसे सुखद तरीके से प्रभावित नहीं कर सकते हैं।
सामान्य तौर पर PostgreSQL और डेटाबेस की विशिष्टताएँ क्या हैं? समस्या यह है कि आप किसी एक चीज़ में फेरबदल नहीं कर सकते और यह नहीं देख सकते कि हमारे प्रदर्शन में उल्लेखनीय सुधार हुआ है।
हाँ, ऐसे गैजेट हैं, लेकिन डेटाबेस एक जटिल चीज़ है। यह सर्वर के पास मौजूद सभी संसाधनों के साथ इंटरैक्ट करता है और पूरी तरह से इंटरैक्ट करना पसंद करता है। यदि आप होस्ट ओएस का उपयोग करने के बारे में ओरेकल की वर्तमान सिफारिशों को देखते हैं, तो यह उस मंगोलियाई अंतरिक्ष यात्री के बारे में मजाक जैसा होगा - कुत्ते को खिलाओ और कुछ भी मत छुओ। आइए डेटाबेस को सभी संसाधन दें, डेटाबेस स्वयं ही सब कुछ सुलझा लेगा।
सिद्धांत रूप में, कुछ हद तक स्थिति PostgreSQL के साथ बिल्कुल वैसी ही है। अंतर यह है कि डेटाबेस अभी तक सभी संसाधनों को अपने लिए लेने में सक्षम नहीं है, यानी कहीं न कहीं लिनक्स स्तर पर आपको इसे स्वयं ही व्यवस्थित करने की आवश्यकता है।
मुख्य विचार किसी एक लक्ष्य का चयन करना और उसे ट्यून करना शुरू करना नहीं है, उदाहरण के लिए, मेमोरी, सीपीयू या ऐसा कुछ, बल्कि कार्यभार का विश्लेषण करना और जितना संभव हो सके थ्रूपुट में सुधार करने का प्रयास करना है ताकि अच्छे प्रोग्रामर ने इसे बनाया हो। हमारे लिए, हमारे उपयोगकर्ताओं सहित।
यह क्या है यह समझाने के लिए यहां एक चित्र है। एक Linux OS बफ़र है और साझा मेमोरी है और PostgreSQL साझा बफ़र हैं। PostgreSQL, Oracle के विपरीत, केवल कर्नेल बफ़र के माध्यम से सीधे काम करता है, यानी, डिस्क से एक पृष्ठ को उसकी साझा मेमोरी में लाने के लिए, उसे कर्नेल बफ़र से गुजरना होगा और वापस आना होगा, बिल्कुल वही स्थिति।
डिस्क इसी सिस्टम के अंतर्गत रहती है. मैंने इसे डिस्क के रूप में चित्रित किया। वास्तव में, कोई RAID नियंत्रक आदि हो सकता है।
और ये इनपुट-आउटपुट किसी न किसी तरह इसी मैटर से होता है.
PostgreSQL एक क्लासिक डेटाबेस है। अंदर एक पेज है. और सभी इनपुट और आउटपुट पेजों का उपयोग करके होते हैं। हम पृष्ठों के साथ ब्लॉकों को मेमोरी में बढ़ा रहे हैं। और अगर कुछ नहीं हुआ, तो हम बस उन्हें पढ़ते हैं, फिर धीरे-धीरे वे इस कैश से, साझा बफ़र्स से गायब हो जाते हैं और वापस डिस्क पर समाप्त हो जाते हैं।
यदि हम कहीं कुछ बदल देते हैं तो पूरा पृष्ठ गंदा अंकित हो जाता है। मैंने उन्हें यहां नीले रंग से चिह्नित किया है। और इसका मतलब यह है कि यह पेज ब्लॉक स्टोरेज के साथ सिंक्रोनाइज़ होना चाहिए। यानी जब हमने इसे गंदा कर दिया तो हमने वाल में एंट्री कर ली. और समय के किसी अद्भुत क्षण में, चेकपॉइंट नामक एक घटना आई। और इस लॉग में जानकारी दर्ज थी कि वह आ गया है. और इसका मतलब यह है कि इन साझा बफ़र्स में उस समय मौजूद सभी गंदे पेज कर्नेल बफ़र के माध्यम से fsync का उपयोग करके स्टोरेज डिस्क के साथ सिंक्रनाइज़ किए गए थे।
ऐसा क्यों किया जा रहा है? यदि हमने वोल्टेज खो दिया, तो हमें ऐसी स्थिति नहीं मिली कि सारा डेटा खो जाए। स्थायी स्मृति, जिसके बारे में सभी ने हमें बताया, डेटाबेस सिद्धांत में अब तक है - यह एक उज्ज्वल भविष्य है, जिसके लिए हम निश्चित रूप से प्रयास करते हैं और हमें यह पसंद है, लेकिन अभी वे शून्य से 20 वर्ष नीचे रहते हैं। और, निःसंदेह, इस सब पर नजर रखने की जरूरत है।
और थ्रूपुट को अधिकतम करने का कार्य इन सभी चरणों को ठीक करना है ताकि यह सब तेजी से आगे और पीछे चले। साझा मेमोरी मूल रूप से एक पेज कैश है। PostgreSQL में हमने एक चुनिंदा क्वेरी या कुछ और भेजा, इसने डिस्क से यह डेटा पुनर्प्राप्त किया। वे साझा बफ़र्स में समाप्त हो गए। तदनुसार, इसे बेहतर ढंग से कार्य करने के लिए बहुत अधिक मेमोरी होनी चाहिए।
यह सब अच्छी तरह से और तेज़ी से काम करने के लिए, आपको सभी चरणों में ऑपरेटिंग सिस्टम को सही ढंग से कॉन्फ़िगर करने की आवश्यकता है। और संतुलित हार्डवेयर चुनें, क्योंकि यदि आपके पास किसी स्थान पर असंतुलन है, तो आप बहुत सारी मेमोरी बना सकते हैं, लेकिन यह पर्याप्त गति से सर्विस नहीं की जाएगी।
और आइए इनमें से प्रत्येक बिंदु पर गौर करें।
इन पृष्ठों को तेजी से आगे-पीछे करने के लिए, आपको निम्नलिखित हासिल करने की आवश्यकता है:
- सबसे पहले, आपको मेमोरी के साथ अधिक कुशलता से काम करने की आवश्यकता है।
- दूसरे, जब मेमोरी से पेज डिस्क पर जाते हैं तो यह संक्रमण अधिक कुशल होना चाहिए।
- और तीसरा, अच्छी डिस्क होनी चाहिए।
यदि आपके सर्वर में 512 जीबी रैम है और यह सब बिना किसी कैश के SATA हार्ड ड्राइव पर समाप्त हो जाता है, तो संपूर्ण डेटाबेस सर्वर सिर्फ एक कद्दू नहीं, बल्कि SATA इंटरफ़ेस वाला एक कद्दू बन जाता है। आप सीधे इसमें भाग लेंगे. और कुछ भी तुम्हें नहीं बचाएगा.
स्मृति के पहले बिंदु के संबंध में, तीन चीजें हैं जो जीवन को बहुत कठिन बना सकती हैं।
उनमें से पहला है NUMA. NUMA एक ऐसी चीज़ है जो प्रदर्शन को बेहतर बनाने के लिए बनाई गई है। कार्यभार के आधार पर, विभिन्न चीजों को अनुकूलित किया जा सकता है। और अपने नए वर्तमान स्वरूप में, यह डेटाबेस जैसे अनुप्रयोगों के लिए बहुत अच्छा नहीं है जो गहनता से पेज कैश साझा बफ़र्स का उपयोग करते हैं।
संक्षेप में। आप कैसे बता सकते हैं कि NUMA में कुछ गड़बड़ है? आपके पास किसी प्रकार की अप्रिय दस्तक है, अचानक कुछ सीपीयू ओवरलोड हो गया है। उसी समय, आप PostgreSQL में प्रश्नों का विश्लेषण करते हैं और देखते हैं कि वहां कुछ भी समान नहीं है। ये क्वेरीज़ इतनी CPU गहन नहीं होनी चाहिए. आप इसे लंबे समय तक पकड़ सकते हैं. PostgreSQL के लिए NUMA को कॉन्फ़िगर करने के तरीके पर शुरू से ही सही अनुशंसा का उपयोग करना आसान है।
वास्तव में क्या चल रहा है? NUMA का मतलब नॉन-यूनिफ़ॉर्म मेमोरी एक्सेस है। क्या बात है? आपके पास एक सीपीयू है, उसके बगल में उसकी स्थानीय मेमोरी है। और यह मेमोरी इंटरकनेक्ट अन्य सीपीयू से मेमोरी खींच सकता है।
यदि आप दौड़ते हैं numactl --hardware, तो आपको इतनी बड़ी शीट मिल जाएगी. अन्य बातों के अलावा, एक दूरी क्षेत्र भी होगा। संख्याएँ होंगी - 10-20, कुछ इस तरह। ये संख्याएँ इस दूरस्थ मेमोरी को लेने और इसे स्थानीय स्तर पर उपयोग करने के लिए हॉप्स की संख्या से अधिक कुछ नहीं हैं। सिद्धांत रूप में, एक अच्छा विचार है. यह विभिन्न प्रकार के कार्यभार के तहत प्रदर्शन को अच्छी तरह से गति देता है।
अब कल्पना करें कि आपके पास एक सीपीयू है जो पहले अपनी स्थानीय मेमोरी का उपयोग करने की कोशिश कर रहा है, फिर किसी चीज़ के लिए इंटरकनेक्ट के माध्यम से दूसरी मेमोरी खींचने की कोशिश कर रहा है। और इस CPU को आपका संपूर्ण PostgreSQL पेज कैश मिलता है - बस इतना ही, कुछ गीगाबाइट। आपको हमेशा सबसे खराब स्थिति मिलती है, क्योंकि सीपीयू पर आमतौर पर उस मॉड्यूल में बहुत कम मेमोरी होती है। और जो भी मेमोरी सेवित की जाती है वह इन इंटरकनेक्ट के माध्यम से जाती है। यह धीमा और दुखद साबित होता है। और आपका प्रोसेसर जो इस नोड को सेवा प्रदान करता है वह लगातार अतिभारित रहता है। और इस मेमोरी का एक्सेस टाइम ख़राब है, धीमा है। यदि आप डेटाबेस के लिए इसका उपयोग कर रहे हैं तो यह वह स्थिति है जो आप नहीं चाहते।
इसलिए, डेटाबेस के लिए अधिक सही विकल्प यह है कि लिनक्स ऑपरेटिंग सिस्टम को पता ही न चले कि वहां क्या चल रहा है। ताकि यह मेमोरी को वैसे ही एक्सेस कर सके जैसे वह करता है।
ऐसा क्यों? ऐसा प्रतीत होगा कि इसका उल्टा होना चाहिए। ऐसा एक साधारण कारण से होता है: हमें पेज कैश के लिए बहुत सारी मेमोरी की आवश्यकता होती है - दसियों, सैकड़ों गीगाबाइट।
और अगर हमने यह सब आवंटित किया और अपना डेटा वहां कैश किया, तो कैश का उपयोग करने से होने वाला लाभ मेमोरी तक इतनी मुश्किल पहुंच से होने वाले लाभ से काफी अधिक होगा। और इस प्रकार हमें इस तथ्य की तुलना में अतुलनीय रूप से लाभ होगा कि हम NUMA का उपयोग करके मेमोरी को अधिक कुशलता से एक्सेस करेंगे।
इसलिए, इस समय यहां दो दृष्टिकोण हैं, जब तक कि उज्ज्वल भविष्य नहीं आ जाता है, और डेटाबेस स्वयं यह पता लगाने में सक्षम नहीं है कि वह किस सीपीयू पर चल रहा है और उसे कहां से कुछ खींचने की जरूरत है।
इसलिए, सही तरीका यह है कि NUMA को पूरी तरह से अक्षम कर दिया जाए, उदाहरण के लिए, रिबूट करते समय। ज्यादातर मामलों में, जीत इतनी बड़ी होती है कि कौन सा बेहतर है इसका सवाल ही नहीं उठता।
एक और विकल्प है. हम इसे पहले वाले की तुलना में अधिक बार उपयोग करते हैं, क्योंकि जब कोई ग्राहक सहायता के लिए हमारे पास आता है, तो सर्वर को रिबूट करना उसके लिए बहुत बड़ी बात होती है। उनका वहां बिजनेस है. और उन्हें NUMA के कारण समस्याओं का अनुभव होता है। इसलिए, हम इसे रीबूट की तुलना में कम आक्रामक तरीकों से अक्षम करने का प्रयास करते हैं, लेकिन यह जांचने में सावधानी बरतें कि यह अक्षम है। क्योंकि, जैसा कि अनुभव से पता चलता है, यह अच्छा है कि हम मूल PostgreSQL प्रक्रिया पर NUMA को अक्षम कर दें, लेकिन यह बिल्कुल भी आवश्यक नहीं है कि यह काम करेगा। हमें यह जांचने और देखने की जरूरत है कि क्या वह वास्तव में स्विच ऑफ है।
रॉबर्ट हास की एक अच्छी पोस्ट है. यह PostgreSQL कमिटर्स में से एक है। सभी निम्न-स्तरीय गिब्लेट के प्रमुख डेवलपर्स में से एक। और यदि आप इस पोस्ट के लिंक का अनुसरण करते हैं, तो वे कई रंगीन कहानियों का वर्णन करते हैं कि कैसे NUMA ने लोगों के लिए जीवन को कठिन बना दिया है। देखिए, हमारे डेटाबेस को अच्छी तरह से काम करने के लिए सर्वर पर क्या कॉन्फ़िगर करने की आवश्यकता है, इसकी सिस्टम प्रशासक चेकलिस्ट का अध्ययन करें। इन सेटिंग्स को लिखने और जाँचने की आवश्यकता है, क्योंकि अन्यथा यह बहुत अच्छा नहीं होगा।
कृपया ध्यान दें कि यह उन सभी सेटिंग्स पर लागू होता है जिनके बारे में मैं बात करूंगा। लेकिन आमतौर पर दोष सहनशीलता के लिए डेटाबेस को मास्टर-स्लेव मोड में एकत्र किया जाता है। गुलाम पर ये सेटिंग करना न भूलें क्योंकि एक दिन आपके साथ दुर्घटना होगी और आप गुलाम पर स्विच कर देंगे और वह मालिक बन जाएगा।
आपातकालीन स्थिति में, जब सब कुछ बहुत खराब हो, आपका फोन लगातार बज रहा हो और आपका बॉस एक बड़ी छड़ी लेकर दौड़ता हुआ आता हो, आपके पास जाँच के बारे में सोचने का समय नहीं होगा। और परिणाम काफी विनाशकारी हो सकते हैं.
अगला बिंदु विशाल पृष्ठ है। बड़े पृष्ठों का अलग से परीक्षण करना कठिन है, और ऐसा करने का कोई मतलब नहीं है, हालांकि ऐसे बेंचमार्क हैं जो ऐसा कर सकते हैं। उन्हें Google पर खोजना आसान है.
क्या बात है? आपके पास बहुत अधिक रैम वाला कोई बहुत महंगा सर्वर नहीं है, उदाहरण के लिए, 30 जीबी से अधिक। आप बड़े पृष्ठों का उपयोग नहीं करते. इसका मतलब यह है कि मेमोरी उपयोग के मामले में आपके पास निश्चित रूप से ओवरहेड है। और यह ओवरहेड सबसे सुखद से बहुत दूर है।
ऐसा क्यों? तो क्या चल रहा है? ऑपरेटिंग सिस्टम मेमोरी को छोटे-छोटे टुकड़ों में आवंटित करता है। यह बहुत सुविधाजनक है, ऐतिहासिक रूप से ऐसा ही हुआ है। और अगर हम विस्तार से जाएं, तो ओएस को आभासी पते को भौतिक पते में अनुवाद करना होगा। और यह प्रक्रिया सबसे सरल नहीं है, इसलिए ओएस इस ऑपरेशन के परिणाम को ट्रांसलेशन लुकसाइड बफर (टीएलबी) में कैश करता है।
और चूंकि टीएलबी एक कैश है, इस स्थिति में कैश में निहित सभी समस्याएं उत्पन्न होती हैं। सबसे पहले, यदि आपके पास बहुत अधिक रैम है और यह सब छोटे-छोटे हिस्सों में आवंटित है, तो यह बफ़र बहुत बड़ा हो जाता है। और यदि कैश बड़ा है, तो इसके माध्यम से खोज करना धीमा है। ओवरहेड स्वस्थ है और यह स्वयं जगह लेता है, यानी रैम का उपभोग किसी गलत चीज़ द्वारा किया जा रहा है। इस समय।
दो - ऐसी स्थिति में कैश जितना अधिक बढ़ेगा, उतनी अधिक संभावना है कि आपका कैश मिस हो जाएगा। और जैसे-जैसे इसका आकार बढ़ता है इस कैश की दक्षता तेजी से घटती जाती है। इसलिए, ऑपरेटिंग सिस्टम एक सरल दृष्टिकोण लेकर आए। Linux में इसका प्रयोग काफी समय से किया जा रहा है. यह कुछ समय पहले फ्रीबीएसडी में दिखाई दिया था। लेकिन हम बात कर रहे हैं Linux की. ये बहुत बड़े पेज हैं.
और यहां यह ध्यान दिया जाना चाहिए कि विशाल पृष्ठ, एक विचार के रूप में, शुरू में उन समुदायों द्वारा आगे बढ़ाए गए थे जिनमें ओरेकल और आईबीएम शामिल थे, यानी डेटाबेस निर्माताओं ने दृढ़ता से सोचा था कि यह डेटाबेस के लिए भी उपयोगी होगा।
और इसे PostgreSQL से कैसे मित्र बनाया जा सकता है? सबसे पहले, लिनक्स कर्नेल में विशाल पेज सक्षम होने चाहिए।
दूसरे, उन्हें sysctl पैरामीटर द्वारा स्पष्ट रूप से निर्दिष्ट किया जाना चाहिए - कितने हैं। यहां नंबर किसी पुराने सर्वर से हैं। आप गणना कर सकते हैं कि आपके पास कितने साझा बफ़र्स हैं ताकि बड़े पृष्ठ वहां फिट हो सकें।
और यदि आपका पूरा सर्वर PostgreSQL को समर्पित है, तो एक अच्छा प्रारंभिक बिंदु या तो साझा बफ़र्स को 25% RAM आवंटित करना है, या 75% यदि आप सुनिश्चित हैं कि आपका डेटाबेस निश्चित रूप से इस 75% में फिट होगा। शुरुआती बिंदु एक. और विचार करें, यदि आपके पास 256 जीबी रैम है, तो तदनुसार, आपके पास 64 जीबी बड़े बफ़र्स होंगे। कुछ मार्जिन के साथ लगभग गणना करें - यह आंकड़ा किस पर सेट किया जाना चाहिए।
संस्करण 9.2 से पहले (यदि मैं गलत नहीं हूँ, संस्करण 8.2 के बाद से), तृतीय-पक्ष लाइब्रेरी का उपयोग करके PostgreSQL को विशाल पृष्ठों से जोड़ना संभव था। और ऐसा हमेशा करना चाहिए. सबसे पहले, आपको विशाल पृष्ठों को सही ढंग से आवंटित करने में सक्षम होने के लिए कर्नेल की आवश्यकता है। और, दूसरा, ताकि उनके साथ काम करने वाला एप्लिकेशन उनका उपयोग कर सके। इसका उपयोग ऐसे ही नहीं किया जाएगा. चूंकि PostgreSQL ने सिस्टम 5 शैली में मेमोरी आवंटित की है, यह libhgetlbfs का उपयोग करके किया जा सकता है - यह लाइब्रेरी का पूरा नाम है।
9.3 में, मेमोरी के साथ काम करते समय PostgreSQL प्रदर्शन में सुधार हुआ और सिस्टम 5 मेमोरी आवंटन विधि को छोड़ दिया गया। हर कोई बहुत खुश था, क्योंकि अन्यथा आप एक मशीन पर दो PostgreSQL इंस्टेंस चलाने का प्रयास करते हैं, और वह कहता है कि मेरे पास पर्याप्त साझा मेमोरी नहीं है। और उनका कहना है कि sysctl को ठीक करने की जरूरत है। और एक ऐसी प्रणाली है जिसे आपको अभी भी रीबूट करने की आवश्यकता है, आदि। सामान्य तौर पर, हर कोई खुश था। लेकिन एमएमएपी मेमोरी आवंटन ने विशाल पृष्ठों के उपयोग को तोड़ दिया। हमारे अधिकांश ग्राहक बड़े साझा बफ़र्स का उपयोग करते हैं। और हमने दृढ़तापूर्वक अनुशंसा की कि 9.3 पर स्विच न करें, क्योंकि वहां ओवरहेड की गणना अच्छे प्रतिशत में की जाने लगी।
लेकिन समुदाय ने इस समस्या पर ध्यान दिया और 9.4 में उन्होंने इस घटना को बहुत अच्छी तरह से फिर से तैयार किया। और 9.4 में postgresql.conf में एक पैरामीटर दिखाई दिया जिसमें आप प्रयास को चालू या बंद कर सकते हैं।
प्रयास सबसे सुरक्षित विकल्प है. जब PostgreSQL प्रारंभ होता है, जब यह साझा मेमोरी आवंटित करता है, तो यह इस मेमोरी को विशाल पृष्ठों से पकड़ने का प्रयास करता है। और यदि यह काम नहीं करता है, तो यह सामान्य चयन पर वापस आ जाता है। और यदि आपके पास फ्रीबीएसडी या सोलारिस है, तो आप कोशिश कर सकते हैं, यह हमेशा सुरक्षित है।
यदि चालू है, तो यह प्रारंभ ही नहीं होता यदि यह विशाल पृष्ठों में से चयन नहीं कर पाता। यहां यह पहले से ही है कि कौन और क्या अच्छा है। लेकिन यदि आपने प्रयास किया है, तो जांच लें कि वास्तव में आपको जो हाइलाइट करना है वह आपके पास है, क्योंकि त्रुटि की बहुत गुंजाइश है। वर्तमान में यह कार्यक्षमता केवल लिनक्स पर काम करती है।
आगे बढ़ने से पहले एक और छोटा सा नोट। पारदर्शी विशाल पृष्ठ अभी तक PostgreSQL के बारे में नहीं हैं। वह उनका सामान्य रूप से उपयोग नहीं कर सकता. और ऐसे कार्यभार के लिए पारदर्शी विशाल पृष्ठों के साथ, जब साझा मेमोरी के एक बड़े टुकड़े की आवश्यकता होती है, तो लाभ केवल बहुत बड़ी मात्रा में आते हैं। यदि आपके पास टेराबाइट्स मेमोरी है तो यह काम आ सकता है। यदि हम अधिक रोजमर्रा के अनुप्रयोगों के बारे में बात कर रहे हैं, जब आपकी मशीन पर 32, 64, 128, 256 जीबी मेमोरी है, तो सामान्य विशाल पृष्ठ ठीक हैं, और हम बस ट्रांसपेरेंट को अक्षम कर देते हैं।
और याददाश्त के बारे में आखिरी बात सीधे तौर पर फल से संबंधित नहीं है, यह वास्तव में आपके जीवन को बर्बाद कर सकती है। सभी थ्रूपुट इस तथ्य से बहुत प्रभावित होंगे कि सर्वर लगातार स्वैप कर रहा है।
और यह कई मायनों में बहुत अप्रिय होगा. और मुख्य समस्या यह है कि आधुनिक कर्नेल पुराने लिनक्स कर्नेल से थोड़ा अलग व्यवहार करते हैं। और इस बात पर आगे बढ़ना काफी अप्रिय है, क्योंकि जब हम स्वैप के साथ किसी प्रकार के काम के बारे में बात करते हैं, तो यह ओओएम-हत्यारे के असामयिक आगमन के साथ समाप्त होता है। और OOM-किलर, जो समय पर नहीं पहुंचा और PostgreSQL को गिरा दिया, अप्रिय है। इसके बारे में हर किसी को यानी आखिरी यूजर तक पता होगा.
क्या हो रहा है? आपके पास बड़ी मात्रा में रैम है, सब कुछ अच्छी तरह से काम करता है। लेकिन किसी कारण से सर्वर स्वैप में हैंग हो जाता है और इस वजह से धीमा हो जाता है। ऐसा लगेगा कि बहुत सारी मेमोरी है, लेकिन ऐसा होता है।
पहले, हमने vm.swappiness को शून्य पर सेट करने, यानी स्वैप को अक्षम करने की सलाह दी थी। पहले, ऐसा लगता था कि 32 जीबी रैम और संबंधित साझा बफ़र्स एक बड़ी राशि थी। अदला-बदली का मुख्य उद्देश्य यह है कि यदि हम गिर जाएँ तो पपड़ी फेंकने के लिए जगह हो। और यह अब विशेष रूप से पूरा नहीं हुआ था. और फिर आप इस पपड़ी के साथ क्या करने जा रहे हैं? यह एक ऐसा कार्य है जहां यह बहुत स्पष्ट नहीं है कि स्वैप की आवश्यकता क्यों है, विशेष रूप से ऐसे आकार की।
लेकिन अधिक आधुनिक, यानी कर्नेल के तीसरे संस्करण में, व्यवहार बदल गया है। और यदि आप स्वैप को शून्य पर सेट करते हैं, यानी इसे बंद कर देते हैं, तो देर-सबेर, भले ही कुछ रैम बची हो, सबसे गहन उपभोक्ताओं को मारने के लिए एक OOM किलर आपके पास आएगा। क्योंकि वह इस बात पर विचार करेगा कि इस तरह के कार्यभार के साथ हमारे पास अभी भी थोड़ा सा बचा है और हम बाहर निकल जाएंगे, यानी, सिस्टम प्रक्रिया को ख़त्म करने के लिए नहीं, बल्कि किसी कम महत्वपूर्ण चीज़ को ख़त्म करने के लिए। यह कम महत्वपूर्ण साझा मेमोरी का गहन उपभोक्ता होगा, अर्थात् पोस्टमास्टर। और उसके बाद आधार को दोबारा ठीक न कराना पड़े तो अच्छा रहेगा.
इसलिए, अब डिफ़ॉल्ट, जहां तक मुझे याद है, अधिकांश वितरण 6 के आसपास हैं, यानी कितनी मेमोरी बची है इसके आधार पर आपको किस बिंदु पर स्वैप का उपयोग शुरू करना चाहिए। अब हम vm.swappiness = 1 सेट करने की अनुशंसा करते हैं, क्योंकि यह व्यावहारिक रूप से इसे बंद कर देता है, लेकिन OOM-किलर के समान प्रभाव नहीं देता है जो अप्रत्याशित रूप से आया और पूरी चीज को खत्म कर दिया।
आगे क्या होगा? जब हम डेटाबेस के प्रदर्शन के बारे में बात करते हैं और धीरे-धीरे डिस्क की ओर बढ़ते हैं, तो हर कोई अपना सिर पकड़ने लगता है। क्योंकि यह सच्चाई कि डिस्क धीमी होती है और याददाश्त तेज़ होती है, बचपन से हर कोई परिचित है। और हर कोई जानता है कि डेटाबेस में डिस्क प्रदर्शन समस्याएँ होंगी।
चेकप्वाइंट स्पाइक्स से जुड़ी मुख्य PostgreSQL प्रदर्शन समस्या उत्पन्न नहीं होती क्योंकि डिस्क धीमी है। यह संभवतः इस तथ्य के कारण है कि मेमोरी और डिस्क बैंडविड्थ संतुलित नहीं हैं। हालाँकि, उन्हें अलग-अलग जगहों पर संतुलित नहीं किया जा सकता है। PostgreSQL कॉन्फ़िगर नहीं है, OS कॉन्फ़िगर नहीं है, हार्डवेयर कॉन्फ़िगर नहीं है और हार्डवेयर ग़लत है। और यह समस्या केवल तभी नहीं होती है जब सब कुछ वैसा ही होता है जैसा होना चाहिए, यानी या तो कोई लोड नहीं है, या सेटिंग्स और हार्डवेयर अच्छी तरह से चुने गए हैं।
यह क्या है और यह कैसा दिखता है? आमतौर पर जो लोग PostgreSQL के साथ काम करते हैं, उन्होंने इस मामले में एक से अधिक बार प्रवेश किया है। मैं समझाता हूँ। जैसा कि मैंने कहा, PostgreSQL समय-समय पर साझा मेमोरी में गंदे पृष्ठों को डिस्क पर डंप करने के लिए चेकपॉइंट बनाता है। यदि हमारे पास बड़ी मात्रा में साझा मेमोरी है, तो चेकपॉइंट का डिस्क पर गहन प्रभाव पड़ना शुरू हो जाता है, क्योंकि यह इन पेजों को fsync के साथ डंप कर देता है। यह कर्नेल बफ़र में आता है और fsync का उपयोग करके डिस्क पर लिखा जाता है। और यदि इस व्यवसाय की मात्रा बड़ी है, तो हम एक अप्रिय प्रभाव देख सकते हैं, अर्थात् डिस्क का बहुत बड़ा उपयोग।
यहां मेरे पास दो तस्वीरें हैं. अब मैं समझाऊंगा कि यह क्या है। ये दो समय-सहसंबंधित ग्राफ़ हैं। पहला ग्राफ़ डिस्क उपयोग है। यहाँ इस समय यह लगभग 90% तक पहुँच जाता है। यदि आपके पास 90% पर RAID नियंत्रक उपयोग के साथ भौतिक डिस्क के साथ डेटाबेस विफलता है, तो यह बुरी खबर है। इसका मतलब है कि थोड़ा और और यह 100 तक पहुंच जाएगा और I/O बंद हो जाएगा।
यदि आपके पास डिस्क ऐरे है, तो यह थोड़ी अलग कहानी है। यह इस बात पर निर्भर करता है कि इसे कैसे कॉन्फ़िगर किया गया है, यह किस प्रकार की सरणी है, आदि।
और समानांतर में, आंतरिक पोस्टग्रेस दृश्य से एक ग्राफ यहां कॉन्फ़िगर किया गया है, जो बताता है कि चेकपॉइंट कैसे होता है। और यहां हरा रंग दिखाता है कि कितने बफ़र्स, ये गंदे पृष्ठ, उस समय सिंक्रनाइज़ेशन के लिए इस चेकपॉइंट पर पहुंचे। और यही मुख्य बात है जो आपको यहां जानना आवश्यक है। हम देखते हैं कि हमारे यहां बहुत सारे पेज हैं और किसी बिंदु पर हम बोर्ड से टकराते हैं, यानी हमने लिखा और लिखा, यहां डिस्क सिस्टम स्पष्ट रूप से बहुत व्यस्त है। और हमारे चेकप्वाइंट का डिस्क पर बहुत गहरा प्रभाव पड़ता है। आदर्श रूप से, स्थिति इस तरह दिखनी चाहिए, यानी हमारे यहां कम रिकॉर्डिंग थी। और हम इसे सेटिंग्स के साथ ठीक कर सकते हैं ताकि यह इसी तरह बना रहे। यानी रिसाइक्लिंग छोटी है, लेकिन कहीं न कहीं हम यहां कुछ लिख रहे हैं।
इस समस्या को दूर करने के लिए क्या करने की आवश्यकता है? यदि आपने डेटाबेस के तहत IO को रोक दिया है, तो इसका मतलब है कि सभी उपयोगकर्ता जो अपने अनुरोधों को पूरा करने के लिए आए थे, प्रतीक्षा करेंगे।
यदि आप लिनक्स के दृष्टिकोण से देखते हैं, यदि आपने अच्छा हार्डवेयर लिया है, इसे सही ढंग से कॉन्फ़िगर किया है, PostgreSQL को सामान्य रूप से कॉन्फ़िगर किया है ताकि यह इन चौकियों को कम बार बनाए, समय के साथ उन्हें एक-दूसरे के बीच फैलाए, तो आप डिफ़ॉल्ट डेबियन मापदंडों में कदम रखते हैं। अधिकांश लिनक्स वितरणों के लिए, यह चित्र है: vm.dirty_ratio=20, vm.dirty_background_ratio=10।
इसका मतलब क्या है? कर्नेल 2.6 से एक निस्तब्ध दानव प्रकट हुआ। Pdglosh, इस पर निर्भर करता है कि कौन किसका उपयोग कर रहा है, जो कर्नेल बफ़र से गंदे पृष्ठों को पृष्ठभूमि में हटाने में लगा हुआ है और जब गंदे पृष्ठों को त्यागना आवश्यक हो तो त्यागना, चाहे कुछ भी हो, जब बैकग्राउंड त्यागने से मदद नहीं मिलती है।
पृष्ठभूमि कब आती है? जब सर्वर पर उपलब्ध कुल रैम का 10% कर्नेल बफर में गंदे पृष्ठों द्वारा कब्जा कर लिया जाता है, तो पृष्ठभूमि में एक विशेष राइट-ऑफ फ़ंक्शन को कॉल किया जाता है। यह पृष्ठभूमि क्यों है? एक पैरामीटर के रूप में, यह ध्यान में रखा जाता है कि कितने पेज लिखने हैं। और, मान लीजिए, वह एन पेज लिखता है। और थोड़ी देर के लिए ये चीज़ सो जाती है. और फिर वह दोबारा आती है और कुछ और पन्ने कॉपी कर लेती है।
यह एक अत्यंत सरल कहानी है. यहां समस्या स्विमिंग पूल की तरह है, जब इसे एक पाइप में डाला जाता है, तो यह दूसरे पाइप में चला जाता है। हमारा चेकपॉइंट आ गया और अगर उसने कुछ गंदे पेजों को त्यागने के लिए भेजा, तो धीरे-धीरे कर्नेल बफर पीजीफ्लश से पूरी चीज़ को बड़े करीने से हल किया जाएगा।
यदि ये गंदे पेज जमा होते रहे, तो वे 20% तक जमा हो जाते हैं, जिसके बाद ओएस की प्राथमिकता पूरी चीज़ को डिस्क पर लिखना है, क्योंकि बिजली विफल हो जाएगी और हमारे लिए सब कुछ खराब हो जाएगा। उदाहरण के लिए, हम यह डेटा खो देंगे।
चाल क्या है? चाल यह है कि आधुनिक दुनिया में ये पैरामीटर मशीन पर मौजूद कुल रैम का 20 और 10% हैं, वे आपके पास मौजूद किसी भी डिस्क सिस्टम के थ्रूपुट के मामले में बिल्कुल राक्षसी हैं।
कल्पना कीजिए कि आपके पास 128 जीबी रैम है। आपके डिस्क सिस्टम में 12,8 जीबी आती है। और इससे कोई फर्क नहीं पड़ता कि आपके पास वहां कौन सा कैश है, इससे कोई फर्क नहीं पड़ता कि आपके पास वहां कौन सी सरणी है, वे इतने लंबे समय तक नहीं टिकेंगे।
इसलिए, हम अनुशंसा करते हैं कि आप अपने RAID नियंत्रक की क्षमताओं के आधार पर इन नंबरों को तुरंत समायोजित करें। मैंने तुरंत यहां एक ऐसे नियंत्रक की अनुशंसा की जिसमें 512 एमबी कैश हो।
सब कुछ बहुत सरल माना जाता है. आप बाइट्स में vm.dirty_background डाल सकते हैं। और ये सेटिंग्स पिछली दो को रद्द कर देती हैं। या तो अनुपात डिफ़ॉल्ट रूप से है, या बाइट्स वाले सक्रिय हैं, तो बाइट्स वाले काम करेंगे। लेकिन चूंकि मैं एक डीबीए सलाहकार हूं और विभिन्न ग्राहकों के साथ काम करता हूं, इसलिए मैं स्ट्रॉ निकालने की कोशिश करता हूं और इसलिए, यदि बाइट्स में, तो बाइट्स में। किसी ने कोई गारंटी नहीं दी कि एक अच्छा व्यवस्थापक सर्वर में अधिक मेमोरी नहीं जोड़ेगा, उसे रीबूट नहीं करेगा, और आंकड़ा वही रहेगा। बस इन संख्याओं की गणना करें ताकि सब कुछ गारंटी के साथ वहां फिट हो जाए।
यदि आप इसमें फिट नहीं होते तो क्या होगा? मैंने लिखा है कि किसी भी फ्लशिंग को प्रभावी ढंग से रोका जाता है, लेकिन वास्तव में यह भाषण का एक अलंकार है। ऑपरेटिंग सिस्टम में एक बड़ी समस्या है - इसमें बहुत सारे गंदे पेज हैं, इसलिए आपके क्लाइंट द्वारा जेनरेट किया जाने वाला IO प्रभावी रूप से बंद हो जाता है, यानी डेटाबेस में एक sql क्वेरी भेजने के लिए एप्लिकेशन आ गया है, यह प्रतीक्षा कर रहा है। इसमें कोई भी इनपुट/आउटपुट सबसे कम प्राथमिकता वाला है, क्योंकि डेटाबेस पर एक चेकपॉइंट का कब्जा है। और वह कब ख़त्म करेगी यह पूरी तरह से अस्पष्ट है. और जब आपने नॉन-बैकग्राउंड फ्लशिंग हासिल कर ली है, तो इसका मतलब है कि आपके सभी आईओ पर इसका कब्जा है। और जब तक यह ख़त्म न हो जाए, आप कुछ नहीं करेंगे.
यहां दो और महत्वपूर्ण बिंदु हैं जो इस रिपोर्ट के दायरे से बाहर हैं। इन सेटिंग्स को postgresql.conf, यानी चेकपॉइंट सेटिंग्स में सेटिंग्स से मेल खाना चाहिए। और आपका डिस्क सिस्टम पर्याप्त रूप से कॉन्फ़िगर होना चाहिए। यदि आपके पास RAID पर कैश है, तो उसमें बैटरी होनी चाहिए। लोग बिना बैटरी के अच्छे कैश वाला RAID खरीदते हैं। यदि आपके पास RAID में SSDs हैं, तो वे सर्वर वाले होने चाहिए, वहां कैपेसिटर होने चाहिए। यहां एक विस्तृत चेकलिस्ट है. इस लिंक में PostgreSQL में प्रदर्शन डिस्क को कॉन्फ़िगर करने के तरीके पर मेरी रिपोर्ट शामिल है। वहाँ ये सभी चेकलिस्ट हैं।
और क्या चीज़ जीवन को बहुत कठिन बना सकती है? ये दो पैरामीटर हैं. वे अपेक्षाकृत नये हैं. डिफ़ॉल्ट रूप से, उन्हें विभिन्न अनुप्रयोगों में शामिल किया जा सकता है। और अगर उन्हें गलत तरीके से चालू किया जाए तो वे जीवन को उतना ही कठिन बना सकते हैं।
दो अपेक्षाकृत नई चीजें हैं. वे पहले ही तीसरे कोर में प्रकट हो चुके हैं। यह नैनोसेकंड में sched_migration_cost और sched_autogroup_enabled है, जो डिफ़ॉल्ट रूप से एक है।
और वे आपका जीवन कैसे बर्बाद करते हैं? शेड्यूल_माइग्रेशन_कॉस्ट क्या है? लिनक्स पर, शेड्यूलर एक प्रक्रिया को एक सीपीयू से दूसरे सीपीयू में स्थानांतरित कर सकता है। और PostgreSQL के लिए, जो प्रश्नों को निष्पादित करता है, दूसरे CPU पर माइग्रेट करना पूरी तरह से अस्पष्ट है। ऑपरेटिंग सिस्टम के दृष्टिकोण से, जब आप विंडोज़ को ओपनऑफ़िस और टर्मिनल के बीच स्विच करते हैं, तो यह अच्छा हो सकता है, लेकिन किसी डेटाबेस के लिए यह बहुत ख़राब है. इसलिए, एक उचित नीति यह है कि माइग्रेशन_कॉस्ट को कुछ बड़े मान, कम से कम कई हजार नैनोसेकंड पर सेट किया जाए।
अनुसूचक के लिए इसका क्या अर्थ होगा? यह माना जाएगा कि इस दौरान प्रक्रिया अभी भी गर्म है। यानी अगर आपका कोई लंबे समय से चल रहा लेनदेन है जो लंबे समय से कुछ कर रहा है तो शेड्यूलर इसे समझ जाएगा। वह मान लेगा कि जब तक यह समय समाप्त नहीं हो जाता, इस प्रक्रिया को कहीं भी स्थानांतरित करने की कोई आवश्यकता नहीं है। यदि उसी समय प्रक्रिया कुछ करती है, तो इसे कहीं भी स्थानांतरित नहीं किया जाएगा, यह चुपचाप उस सीपीयू पर काम करेगा जो इसे आवंटित किया गया था। और परिणाम उत्कृष्ट है.
दूसरा बिंदु ऑटोग्रुप है। विशिष्ट कार्यभार के लिए एक अच्छा विचार है जो आधुनिक डेटाबेस से संबंधित नहीं है - यह वर्चुअल टर्मिनल द्वारा प्रक्रियाओं को समूहीकृत करना है जहां से उन्हें लॉन्च किया जाता है। यह कुछ कार्यों के लिए सुविधाजनक है. व्यवहार में, PostgreSQL एक बहु-प्रक्रिया प्रणाली है जिसमें प्रीफ़ॉर्क होता है जो एकल टर्मिनल से चलता है। आपके पास एक लॉक राइटर, चेकपॉइंट है, और आपके सभी क्लाइंट अनुरोधों को प्रति सीपीयू एक शेड्यूलर में समूहीकृत किया जाएगा। और वे एक-दूसरे के साथ हस्तक्षेप करने और उसे लंबे समय तक अपने कब्जे में रखने के लिए, उसके स्वतंत्र होने का एक साथ वहां इंतजार करेंगे। यह एक ऐसी कहानी है जो इस तरह के भार के मामले में पूरी तरह से अनावश्यक है और इसलिए इसे बंद करने की जरूरत है।
मेरे सहयोगी एलेक्सी लेसोव्स्की ने एक साधारण पीजीबेंच के साथ परीक्षण किया, जहां उन्होंने परिमाण के क्रम से माइग्रेशन_कॉस्ट बढ़ाया और ऑटोग्रुप को बंद कर दिया। ख़राब हार्डवेयर पर अंतर लगभग 10% था. पोस्टग्रेस मेलिंग सूची पर एक चर्चा है जहां लोग क्वेरी गति में समान परिवर्तनों के परिणाम देते हैं 50% प्रभावित. ऐसी बहुत सारी कहानियाँ हैं।
और अंत में, बिजली बचत नीति के बारे में। अच्छी बात यह है कि लिनक्स का उपयोग अब लैपटॉप पर भी किया जा सकता है। और यह माना जाता है कि यह बैटरी का अच्छा उपयोग करेगा। लेकिन अचानक पता चला कि सर्वर पर भी ऐसा हो सकता है.
इसके अलावा, यदि आप किसी होस्टर से सर्वर किराए पर लेते हैं, तो "अच्छे" होस्टर्स को इस बात की परवाह नहीं है कि आपका प्रदर्शन बेहतर है। उनका कार्य यह सुनिश्चित करना है कि उनके लोहे का यथासंभव कुशलतापूर्वक उपयोग किया जाए। इसलिए, डिफ़ॉल्ट रूप से वे ऑपरेटिंग सिस्टम पर लैपटॉप पावर सेविंग मोड को सक्षम कर सकते हैं।
यदि आप भारी लोड वाले डेटाबेस वाले सर्वर पर इस सामग्री का उपयोग करते हैं, तो आपकी पसंद acpi_cpufreq + permormance है। ऑनडिमांड से भी दिक्कतें होंगी.
Intel_pstate थोड़ा अलग ड्राइवर है। और अब इसे प्राथमिकता दी जाती है, क्योंकि यह बाद में है और बेहतर काम करता है।
और, तदनुसार, गवर्नर केवल प्रदर्शन है. ऑनडिमांड, पॉवरसेव और बाकी सब कुछ आपके बारे में नहीं है।
यदि आप पॉवरसेव को सक्षम करते हैं, तो व्याख्या विश्लेषण पोस्टग्रेएसक्यूएल के परिणाम परिमाण के कई क्रमों से भिन्न हो सकते हैं, क्योंकि व्यावहारिक रूप से आपके डेटाबेस के तहत सीपीयू पूरी तरह से अप्रत्याशित तरीके से चल रहा होगा।
ये आइटम डिफ़ॉल्ट रूप से शामिल किए जा सकते हैं. यह देखने के लिए ध्यान से देखें कि क्या उन्होंने इसे डिफ़ॉल्ट रूप से चालू किया है। यह सचमुच एक बड़ी समस्या हो सकती है.
और अंत में, मैं हमारी पॉस्ग्रेएसक्यूएल-कंसल्टिंग डीबीए टीम के लोगों, मैक्स बोगुक और एलेक्सी लेसोव्स्की को धन्यवाद कहना चाहता हूं, जो हर दिन इस मामले में प्रगति कर रहे हैं। और हम अपने ग्राहकों के लिए सर्वोत्तम प्रयास करने का प्रयास करते हैं ताकि यह सब उनके लिए काम करे। यह विमानन सुरक्षा निर्देशों के समान है। यहां सब कुछ खून से लिखा है. इनमें से प्रत्येक नट किसी न किसी प्रकार की समस्या की प्रक्रिया में पाया जाता है। मुझे उन्हें आपके साथ साझा करते हुए खुशी हो रही है।
प्रश्न:
धन्यवाद! यदि, उदाहरण के लिए, कोई कंपनी पैसे बचाना चाहती है और डेटाबेस और एप्लिकेशन लॉजिक को एक सर्वर पर रखना चाहती है, या यदि कंपनी माइक्रोसर्विस आर्किटेक्चर के फैशनेबल चलन का अनुसरण करती है, जिसमें PostgreSQL एक कंटेनर में चलता है। चाल क्या है? Sysctl विश्व स्तर पर संपूर्ण कर्नेल को प्रभावित करेगा। मैंने sysctls को किसी तरह वर्चुअलाइज किए जाने के बारे में नहीं सुना है ताकि वे एक कंटेनर पर अलग से काम करें। वहां केवल एक सीग्रुप है और वहां नियंत्रण का केवल एक हिस्सा है। आप इसके साथ कैसे रह सकते हैं? या यदि आप प्रदर्शन चाहते हैं, तो PostgreSQL को एक अलग हार्डवेयर सर्वर पर चलाएं और इसे ट्यून करें?
हमने आपके प्रश्न का उत्तर लगभग तीन तरीकों से दिया। यदि हम एक हार्डवेयर सर्वर के बारे में बात नहीं कर रहे हैं जिसे ट्यून किया जा सकता है, आदि, तो निश्चिंत रहें, इन सेटिंग्स के बिना सब कुछ ठीक काम करेगा। अगर आपके पास इतना लोड है कि आपको ये सेटिंग्स करनी हैं तो आप इन सेटिंग्स से पहले आयरन सर्वर पर आ जाएंगे।
समस्या क्या है? यदि यह एक वर्चुअल मशीन है, तो सबसे अधिक संभावना है कि आपको कई समस्याएं होंगी, उदाहरण के लिए, इस तथ्य के साथ कि अधिकांश वर्चुअल मशीनों पर डिस्क की विलंबता काफी असंगत है। यहां तक कि अगर डिस्क थ्रूपुट अच्छा है, तो एक असफल I/O लेनदेन जो चेकपॉइंट के समय या वाल को लिखने के समय हुए औसत थ्रूपुट को बहुत प्रभावित नहीं करता है, तो डेटाबेस को इससे बहुत नुकसान होगा। और इन समस्याओं में पड़ने से पहले आप इस पर ध्यान देंगे।
यदि आपके पास एक ही सर्वर पर NGINX है, तो आपको भी यही समस्या होगी। वह साझा स्मृति के लिए लड़ेंगे. और आप यहां वर्णित समस्याओं तक नहीं पहुंच पाएंगे।
लेकिन दूसरी ओर, इनमें से कुछ पैरामीटर अभी भी आपके लिए प्रासंगिक होंगे। उदाहरण के लिए, dirty_ratio को sysctl के साथ सेट करें ताकि यह इतना पागल न हो - किसी भी स्थिति में, इससे मदद मिलेगी। किसी न किसी तरीके से, आपका डिस्क के साथ इंटरेक्शन होगा। और यह गलत पैटर्न के अनुसार होगा. यह आम तौर पर मेरे द्वारा दिखाए गए मापदंडों के लिए एक डिफ़ॉल्ट है। और किसी भी स्थिति में उन्हें बदल देना ही बेहतर है।
लेकिन NUMA के साथ समस्याएँ हो सकती हैं। उदाहरण के लिए, VmWare बिल्कुल विपरीत सेटिंग्स के साथ NUMA के साथ अच्छा काम करता है। और यहां आपको चुनना होगा - एक लोहे का सर्वर या एक गैर-लोहे वाला।
मेरे पास Amazon AWS से संबंधित एक प्रश्न है। उनमें छवियाँ पूर्व-कॉन्फ़िगर की गई हैं। उनमें से एक को अमेज़ॅन आरडीएस कहा जाता है। क्या उनके ऑपरेटिंग सिस्टम के लिए कोई कस्टम सेटिंग्स हैं?
वहां सेटिंग्स हैं, लेकिन वे अलग-अलग सेटिंग्स हैं। यहां हम ऑपरेटिंग सिस्टम को इस संदर्भ में कॉन्फ़िगर करते हैं कि डेटाबेस इस चीज़ का उपयोग कैसे करेगा। और ऐसे पैरामीटर हैं जो यह निर्धारित करते हैं कि हमें अब कहां जाना चाहिए, जैसे आकार देना। यानी हमें इतने संसाधनों की जरूरत है, अब हम उन्हें खा जाएंगे। इसके बाद, अमेज़ॅन आरडीएस इन संसाधनों को मजबूत करता है, और प्रदर्शन वहां गिर जाता है। इस बात की अलग-अलग कहानियाँ हैं कि कैसे लोग इस मामले में गड़बड़ करने लगे हैं। कभी-कभी तो काफी सफलतापूर्वक भी. लेकिन इसका ओएस सेटिंग्स से कोई लेना-देना नहीं है। यह क्लाउड को हैक करने जैसा है। वह एक अलग कहानी है.
विशाल टीएलबी की तुलना में पारदर्शी विशाल पृष्ठों का कोई प्रभाव क्यों नहीं पड़ता?
न दें। इसे कई तरह से समझाया जा सकता है. लेकिन वास्तव में वे इसे देते ही नहीं हैं। PostgreSQL का इतिहास क्या है? स्टार्टअप पर, यह साझा मेमोरी का एक बड़ा टुकड़ा आवंटित करता है। वे पारदर्शी हैं या नहीं, यह पूरी तरह अप्रासंगिक है। यह तथ्य कि वे शुरुआत में ही अलग नजर आते हैं, सब कुछ स्पष्ट कर देता है। और यदि बहुत अधिक मेमोरी है और आपको शेयर्ड_मेमोरी सेगमेंट को फिर से बनाने की आवश्यकता है, तो पारदर्शी विशाल पृष्ठ प्रासंगिक होंगे। PostgreSQL में, शुरुआत में इसे बस एक बड़े हिस्से में आवंटित किया जाता है और बस इतना ही, और फिर वहां कुछ खास नहीं होता है। बेशक, आप इसका उपयोग कर सकते हैं, लेकिन जब यह किसी चीज़ को फिर से आवंटित करता है तो share_memory के ख़राब होने की संभावना होती है। PostgreSQL को इसके बारे में पता नहीं है.
स्रोत: www.habr.com