PostgreSQL कार्यप्रदर्शन सुधारण्यासाठी Linux ट्यूनिंग. इल्या कोस्मोडेमियान्स्की

Ilya Kosmodemyansky द्वारे 2015 अहवालाचा उतारा "PostgreSQL कार्यप्रदर्शन सुधारण्यासाठी लिनक्स ट्यूनिंग"

अस्वीकरण: मी लक्षात घेतो की हा अहवाल नोव्हेंबर 2015 चा आहे - 4 वर्षांहून अधिक काळ लोटला आहे आणि बराच वेळ गेला आहे. अहवालात चर्चा केलेली आवृत्ती 9.4 यापुढे समर्थित नाही. गेल्या 4 वर्षांमध्ये, PostgreSQL ची 5 नवीन रिलीझ रिलीझ झाली आहे, आणि Linux कर्नलच्या 15 आवृत्त्या रिलीझ झाल्या आहेत. तुम्ही हे परिच्छेद पुन्हा लिहिल्यास, तुम्हाला वेगळा अहवाल मिळेल. परंतु येथे आम्ही PostgreSQL साठी मूलभूत Linux ट्यूनिंगचा विचार करतो, जे आजही संबंधित आहे.

माझे नाव इल्या कोस्मोडेमियान्स्की आहे. मी PostgreSQL-Consulting येथे काम करतो. आणि आता मी सामान्यत: डेटाबेसेस आणि विशेषतः PostgreSQL च्या संबंधात लिनक्सचे काय करावे याबद्दल थोडेसे बोलेन, कारण तत्त्वे अगदी समान आहेत.

आपण कशाबद्दल बोलणार आहोत? जर तुम्ही PostgreSQL शी संवाद साधत असाल तर काही प्रमाणात तुम्हाला UNIX प्रशासक असणे आवश्यक आहे. याचा अर्थ काय? जर आम्ही ओरॅकल आणि पोस्टग्रेएसक्यूएलची तुलना केली, तर ओरॅकलमध्ये तुम्हाला 80% डीबीए डेटाबेस प्रशासक आणि 20% लिनक्स प्रशासक असणे आवश्यक आहे.

PostgreSQL सह हे थोडे अधिक क्लिष्ट आहे. PostgreSQL सह तुम्हाला लिनक्स कसे कार्य करते याबद्दल अधिक चांगली समज असणे आवश्यक आहे. आणि त्याच वेळी, लोकोमोटिव्हच्या मागे थोडेसे धावा, कारण अलीकडे सर्व काही अगदी छान अद्यतनित केले गेले आहे. आणि नवीन कर्नल सोडले जातात, आणि नवीन कार्यक्षमता दिसून येते, कार्यप्रदर्शन सुधारते, इ.

आपण लिनक्सबद्दल का बोलत आहोत? अजिबात नाही कारण आम्ही लिनक्स कॉन्फरन्स पीटरमध्ये आहोत, परंतु आधुनिक परिस्थितीत सर्वसाधारणपणे डेटाबेस आणि विशेषतः PostgreSQL वापरण्यासाठी सर्वात न्याय्य ऑपरेटिंग सिस्टमपैकी एक Linux आहे. कारण फ्रीबीएसडी, दुर्दैवाने, काही अतिशय विचित्र दिशेने विकसित होत आहे. आणि कार्यप्रदर्शन आणि इतर अनेक गोष्टींसह दोन्ही समस्या असतील. Windows वरील PostgreSQL चे कार्यप्रदर्शन ही सामान्यतः एक वेगळी गंभीर समस्या आहे, या वस्तुस्थितीवर आधारित आहे की Windows कडे UNIX सारखी सामायिक मेमरी नाही, तर PostgreSQL सर्व याशी जोडलेले आहे, कारण ही एक बहु-प्रक्रिया प्रणाली आहे.

आणि मला वाटते की सोलारिस सारख्या एक्सोटिक्समध्ये प्रत्येकाला कमी रस आहे, म्हणून चला जाऊया.

आधुनिक लिनक्स वितरणामध्ये 1 पेक्षा जास्त syctl पर्याय आहेत, तुम्ही कर्नल कसे तयार करता यावर अवलंबून. त्याच वेळी, जर आपण वेगवेगळ्या नटांकडे पाहिले तर आपण अनेक प्रकारे काहीतरी समायोजित करू शकतो. ते कसे माउंट करावे यासाठी फाइल सिस्टम पॅरामीटर्स आहेत. ते कसे सुरू करावे याबद्दल आपल्याकडे प्रश्न असल्यास: BIOS मध्ये काय सक्षम करावे, हार्डवेअर कसे कॉन्फिगर करावे इ.

हा एक खूप मोठा खंड आहे ज्यावर अनेक दिवस चर्चा केली जाऊ शकते, आणि एका छोट्या अहवालात नाही, परंतु आता मी महत्त्वाच्या गोष्टींवर लक्ष केंद्रित करेन, जर तुम्ही लिनक्सवर तुमचा डेटाबेस चांगल्या प्रकारे वापरण्यापासून रोखण्यासाठी हमी दिलेले रेक कसे टाळता येतील. त्यांना दुरुस्त करू नका. आणि त्याच वेळी, एक महत्त्वाचा मुद्दा असा आहे की डेटाबेससाठी योग्य असलेल्या सेटिंग्जमध्ये अनेक डीफॉल्ट पॅरामीटर्स समाविष्ट नाहीत. म्हणजेच, डीफॉल्टनुसार ते खराब कार्य करेल किंवा अजिबात नाही.

लिनक्समध्ये कोणते पारंपारिक ट्यूनिंग लक्ष्य आहेत? मला वाटते की तुम्ही सर्व लिनक्स प्रशासनाशी व्यवहार करत असल्याने, लक्ष्य काय आहेत हे स्पष्ट करण्याची विशेष गरज नाही.

आपण ट्यून करू शकता:

• सीपीयू.
• मेमरी.
• साठवण.
• इतर. स्नॅकसाठी आम्ही शेवटी याबद्दल बोलू. जरी, उदाहरणार्थ, उर्जा बचत धोरणासारखे पॅरामीटर्स अत्यंत अप्रत्याशित आणि सर्वात आनंददायी मार्गाने कामगिरीवर परिणाम करू शकतात.

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

होय, अशी गॅझेट आहेत, परंतु डेटाबेस ही एक जटिल गोष्ट आहे. हे सर्व्हरकडे असलेल्या सर्व संसाधनांशी संवाद साधते आणि पूर्ण संवाद साधण्यास प्राधान्य देते. यजमान ओएस कसे वापरावे याविषयी ओरॅकलच्या सध्याच्या शिफारशी पाहिल्यास, ते त्या मंगोलियन कॉस्मोनॉटच्या विनोदासारखे होईल - कुत्र्याला खायला द्या आणि काहीही स्पर्श करू नका. चला डेटाबेसला सर्व संसाधने देऊ, डेटाबेस स्वतः सर्वकाही क्रमवारी लावेल.

तत्वतः, काही प्रमाणात परिस्थिती PostgreSQL सारखीच आहे. फरक असा आहे की डेटाबेस अद्याप स्वतःसाठी सर्व संसाधने घेण्यास सक्षम नाही, म्हणजे कुठेतरी लिनक्स स्तरावर तुम्हाला ते सर्व स्वतःच वर्गीकरण करणे आवश्यक आहे.

मुख्य कल्पना म्हणजे एकल लक्ष्य निवडणे आणि ते ट्यून करणे सुरू करणे नाही, उदाहरणार्थ, मेमरी, सीपीयू किंवा असे काहीतरी, परंतु वर्कलोडचे विश्लेषण करणे आणि शक्य तितके थ्रूपुट सुधारण्याचा प्रयत्न करणे जेणेकरून चांगल्या प्रोग्रामरने तयार केलेला भार. आमच्या वापरकर्त्यांसह आमच्यासाठी.

ते काय आहे हे स्पष्ट करण्यासाठी येथे एक चित्र आहे. तेथे लिनक्स ओएस बफर आहे आणि सामायिक मेमरी आहे आणि पोस्टग्रेएसक्यूएल सामायिक बफर आहेत. पोस्टग्रेएसक्यूएल, ओरॅकलच्या विपरीत, केवळ कर्नल बफरद्वारे थेट कार्य करते, म्हणजे, डिस्कवरील पृष्ठ त्याच्या सामायिक मेमरीमध्ये येण्यासाठी, ते कर्नल बफरमधून आणि मागे जाणे आवश्यक आहे, अगदी समान परिस्थिती.

डिस्क या प्रणाली अंतर्गत राहतात. मी हे डिस्क्स म्हणून काढले. खरं तर, RAID कंट्रोलर इत्यादी असू शकतात.

आणि हे इनपुट-आउटपुट एक ना एक मार्ग या प्रकरणाद्वारे घडते.

PostgreSQL हा क्लासिक डेटाबेस आहे. आत एक पान आहे. आणि सर्व इनपुट आणि आउटपुट पृष्ठे वापरून होते. आम्ही पृष्ठांसह मेमरीमध्ये ब्लॉक्स वाढवत आहोत. आणि काहीही झाले नाही तर, आम्ही फक्त ते वाचतो, नंतर हळूहळू ते या कॅशेमधून, सामायिक बफरमधून अदृश्य होतात आणि डिस्कवर परत जातात.

आपण कुठेतरी काहीतरी बदलल्यास, संपूर्ण पृष्ठ गलिच्छ म्हणून चिन्हांकित केले जाते. मी त्यांना येथे निळ्या रंगात चिन्हांकित केले आहे. आणि याचा अर्थ हे पृष्ठ ब्लॉक स्टोरेजसह समक्रमित केले जाणे आवश्यक आहे. म्हणजे घाणेरडे केल्यावर वालमध्ये एन्ट्री केली. आणि वेळेच्या काही अद्भुत क्षणी, चेकपॉईंट नावाची घटना आली. आणि तो आल्याची माहिती या लॉगमध्ये नोंदवली गेली. आणि याचा अर्थ असा की या सामायिक बफरमध्ये त्या क्षणी येथे असलेली सर्व गलिच्छ पृष्ठे कर्नल बफरद्वारे fsync वापरून स्टोरेज डिस्कसह समक्रमित केली गेली.

हे का केले जात आहे? जर आम्ही व्होल्टेज गमावले, तर सर्व डेटा गमावल्याची परिस्थिती आम्हाला मिळाली नाही. कायमस्वरूपी स्मृती, ज्याबद्दल प्रत्येकाने आम्हाला सांगितले, ते आतापर्यंत डेटाबेस सिद्धांतामध्ये आहे - हे एक उज्ज्वल भविष्य आहे, ज्यासाठी आपण अर्थातच प्रयत्न करतो आणि आम्हाला ते आवडते, परंतु आता ते उणे 20 वर्षे जगतात. आणि, अर्थातच, या सर्वांचे निरीक्षण करणे आवश्यक आहे.

आणि जास्तीत जास्त थ्रूपुट करण्याचे कार्य या सर्व टप्प्यांवर बारीक-ट्यून करणे आहे जेणेकरून ते सर्व त्वरीत पुढे आणि पुढे जाईल. सामायिक मेमरी मुळात एक पृष्ठ कॅशे आहे. PostgreSQL मध्ये आम्ही एक निवडक क्वेरी किंवा काहीतरी पाठवले, त्याने डिस्कवरून हा डेटा पुनर्प्राप्त केला. ते सामायिक बफरमध्ये संपले. त्यानुसार, हे अधिक चांगले कार्य करण्यासाठी, भरपूर स्मृती असणे आवश्यक आहे.

हे सर्व चांगले आणि द्रुतपणे कार्य करण्यासाठी, आपल्याला सर्व टप्प्यांवर ऑपरेटिंग सिस्टम योग्यरित्या कॉन्फिगर करणे आवश्यक आहे. आणि संतुलित हार्डवेअर निवडा, कारण जर तुमचा काही ठिकाणी असंतुलन असेल तर तुम्ही भरपूर मेमरी बनवू शकता, परंतु ते पुरेशा वेगाने सर्व्ह केले जाणार नाही.

आणि या प्रत्येक मुद्द्याचा विचार करूया.

ही पृष्ठे वेगाने पुढे-पुढे जाण्यासाठी, तुम्हाला खालील गोष्टी साध्य करणे आवश्यक आहे:

• प्रथम, आपल्याला मेमरीसह अधिक कार्यक्षमतेने कार्य करण्याची आवश्यकता आहे.
• दुसरे म्हणजे, जेव्हा मेमरीमधील पृष्ठे डिस्कवर जातात तेव्हा हे संक्रमण अधिक कार्यक्षम असावे.
• आणि तिसरे म्हणजे, चांगली डिस्क असणे आवश्यक आहे.

जर तुमच्याकडे सर्व्हरमध्ये 512 GB RAM असेल आणि ती सर्व कॅशेशिवाय SATA हार्ड ड्राइव्हवर संपली, तर संपूर्ण डेटाबेस सर्व्हर केवळ भोपळाच नाही तर SATA इंटरफेससह भोपळा बनतो. तुम्ही त्यात थेट धावून जाल. आणि काहीही तुम्हाला वाचवणार नाही.

स्मृतीसह पहिल्या मुद्द्याबद्दल, तीन गोष्टी आहेत ज्यामुळे जीवन खूप कठीण होऊ शकते.

त्यापैकी पहिले NUMA आहे. NUMA ही एक गोष्ट आहे जी कार्यप्रदर्शन सुधारण्यासाठी बनविली जाते. वर्कलोडवर अवलंबून, वेगवेगळ्या गोष्टी ऑप्टिमाइझ केल्या जाऊ शकतात. आणि त्याच्या नवीन वर्तमान फॉर्ममध्ये, डेटाबेसेस सारख्या ऍप्लिकेशन्ससाठी ते फार चांगले नाही जे पृष्ठ कॅशे सामायिक केलेल्या बफरचा गहनपणे वापर करतात.

थोडक्यात. NUMA मध्ये काहीतरी चुकीचे आहे हे तुम्ही कसे सांगू शकता? तुमच्याकडे काही प्रकारची अप्रिय खेळी आहे, अचानक काही CPU ओव्हरलोड झाले आहे. त्याच वेळी, तुम्ही PostgreSQL मधील प्रश्नांचे विश्लेषण करता आणि तेथे समान काहीही नाही हे पहा. या क्वेरी इतक्या CPU गहन नसाव्यात. आपण हे बर्याच काळासाठी पकडू शकता. PostgreSQL साठी NUMA कसे कॉन्फिगर करावे याबद्दल अगदी सुरुवातीपासूनच योग्य शिफारस वापरणे सोपे आहे.

खरोखर काय चालले आहे? NUMA म्हणजे नॉन-युनिफॉर्म मेमरी ऍक्सेस. मुद्दा काय आहे? तुमच्याकडे एक CPU आहे, त्याच्या पुढे त्याची स्थानिक मेमरी आहे. आणि ही मेमरी इंटरकनेक्ट इतर CPU मधून मेमरी खेचू शकते.

आपण धावत असल्यास numactl --hardware, तर तुम्हाला एवढी मोठी शीट मिळेल. इतर गोष्टींबरोबरच, एक अंतर फील्ड असेल. तेथे संख्या असतील - 10-20, असे काहीतरी. ही संख्या ही रिमोट मेमरी उचलण्यासाठी आणि स्थानिक पातळीवर वापरण्यासाठी हॉप्सच्या संख्येपेक्षा अधिक काही नाही. तत्वतः, एक चांगली कल्पना. हे विविध वर्कलोड्स अंतर्गत कार्यप्रदर्शनास गती देते.

आता कल्पना करा की तुमच्याकडे एक CPU प्रथम त्याची स्थानिक मेमरी वापरण्याचा प्रयत्न करत आहे, नंतर एखाद्या गोष्टीसाठी इंटरकनेक्टद्वारे दुसरी मेमरी खेचण्याचा प्रयत्न करत आहे. आणि या CPU ला तुमचे संपूर्ण PostgreSQL पेज कॅशे मिळते - तेच काही गीगाबाइट्स. तुम्‍हाला नेहमीच सर्वात वाईट परिस्थिती मिळते, कारण सीपीयूवर त्या मॉड्यूलमध्‍ये सहसा कमी मेमरी असते. आणि सर्व्हिस केलेली सर्व मेमरी या इंटरकनेक्ट्समधून जाते. तो मंद आणि उदास बाहेर वळते. आणि या नोडला सेवा देणारा तुमचा प्रोसेसर सतत ओव्हरलोड होतो. आणि या मेमरीचा प्रवेश वेळ वाईट, संथ आहे. तुम्ही डेटाबेससाठी वापरत असल्यास ही परिस्थिती तुम्हाला नको आहे.

त्यामुळे, डेटाबेससाठी अधिक योग्य पर्याय म्हणजे लिनक्स ऑपरेटिंग सिस्टिमला तिथे काय चालले आहे हे कळू नये. जेणेकरून ते जसे करते तसे मेमरीमध्ये प्रवेश करते.

अस का? याच्या उलट असावे असे वाटते. हे एका साध्या कारणासाठी घडते: आम्हाला पृष्ठ कॅशेसाठी खूप मेमरी आवश्यक आहे - दहापट, शेकडो गीगाबाइट्स.

आणि जर आपण हे सर्व वाटप केले आणि आमचा डेटा तिथे कॅश केला, तर कॅशे वापरून मिळणारा नफा मेमरीमध्ये अशा अवघड प्रवेशाच्या लाभापेक्षा लक्षणीय असेल. आणि त्यामुळे NUMA चा वापर करून आम्ही मेमरी अधिक कार्यक्षमतेने ऍक्सेस करू या तुलनेत आम्हाला अतुलनीय फायदा होईल.

म्हणून, या क्षणी येथे दोन दृष्टिकोन आहेत, जोपर्यंत उज्वल भविष्य येईपर्यंत, आणि डेटाबेस स्वतः कोणत्या CPU वर चालत आहे आणि कुठून काहीतरी खेचणे आवश्यक आहे हे शोधण्यात सक्षम नाही.

म्हणून, योग्य दृष्टीकोन म्हणजे NUMA पूर्णपणे अक्षम करणे, उदाहरणार्थ, रीबूट करताना. बर्‍याच प्रकरणांमध्ये, जिंकणे इतके मोठे ऑर्डरचे असतात की कोणते चांगले आहे हा प्रश्नच उद्भवत नाही.

दुसरा पर्याय आहे. आम्ही ते पहिल्यापेक्षा जास्त वेळा वापरतो, कारण जेव्हा एखादा क्लायंट आमच्याकडे समर्थनासाठी येतो, तेव्हा सर्व्हर रीबूट करणे ही त्याच्यासाठी मोठी गोष्ट असते. त्याचा तिथे व्यवसाय आहे. आणि त्यांना NUMA मुळे समस्या येतात. म्हणून, आम्ही ते रीबूट करण्यापेक्षा कमी आक्रमक मार्गांनी अक्षम करण्याचा प्रयत्न करतो, परंतु ते अक्षम केले आहे याची काळजी घ्या. कारण, अनुभव दर्शविल्याप्रमाणे, आम्ही मूळ PostgreSQL प्रक्रियेवर NUMA अक्षम करणे चांगले आहे, परंतु ते कार्य करेल हे अजिबात आवश्यक नाही. आम्हाला तपासण्याची आणि ती खरोखर बंद झाली आहे हे पाहण्याची गरज आहे.

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

कृपया लक्षात घ्या की हे सर्व सेटिंग्जना लागू होते ज्याबद्दल मी बोलणार आहे. परंतु सामान्यतः दोष सहिष्णुतेसाठी डेटाबेस मास्टर-स्लेव्ह मोडमध्ये गोळा केले जातात. स्लेव्हवर या सेटिंग्ज करायला विसरू नका कारण एक दिवस तुमचा अपघात होईल आणि तुम्ही गुलामावर स्विच कराल आणि तो मास्टर होईल.

आणीबाणीच्या परिस्थितीत, जेव्हा सर्व काही खूप वाईट असते, तुमचा फोन सतत वाजत असतो आणि तुमचा बॉस मोठी काठी घेऊन धावत येतो, तेव्हा तुम्हाला तपासण्याचा विचार करायला वेळच नसतो. आणि परिणाम जोरदार विनाशकारी असू शकतात.

पुढचा मुद्दा प्रचंड पानांचा आहे. मोठ्या पृष्ठांची स्वतंत्रपणे चाचणी करणे कठीण आहे आणि असे करण्यात काही अर्थ नाही, जरी असे बेंचमार्क आहेत जे हे करू शकतात. ते Google ला सोपे आहेत.

मुद्दा काय आहे? तुमच्याकडे भरपूर RAM असलेला खूप महाग सर्व्हर नाही, उदाहरणार्थ, 30 GB पेक्षा जास्त. तुम्ही मोठी पृष्ठे वापरत नाही. याचा अर्थ मेमरी वापराच्या बाबतीत तुमच्याकडे नक्कीच ओव्हरहेड आहे. आणि हे ओव्हरहेड सर्वात आनंददायी आहे.

अस का? मग काय चालले आहे? ऑपरेटिंग सिस्टम लहान तुकड्यांमध्ये मेमरी वाटप करते. हे खूप सोयीस्कर आहे, हे ऐतिहासिकदृष्ट्या कसे घडले आहे. आणि जर आपण तपशीलवार विचार केला तर, OS ने आभासी पत्ते भौतिक पत्त्यांमध्ये भाषांतरित केले पाहिजेत. आणि ही प्रक्रिया सर्वात सोपी नाही, म्हणून OS या ऑपरेशनचे परिणाम ट्रान्सलेशन लुकसाइड बफर (TLB) मध्ये कॅश करते.

आणि TLB एक कॅशे असल्याने, कॅशेमध्ये अंतर्भूत असलेल्या सर्व समस्या या परिस्थितीत उद्भवतात. प्रथम, जर तुमच्याकडे भरपूर RAM असेल आणि ते सर्व लहान भागांमध्ये वाटप केले असेल, तर हा बफर खूप मोठा होईल. आणि जर कॅशे मोठा असेल तर त्याद्वारे शोधणे धीमे आहे. ओव्हरहेड हे निरोगी आहे आणि ते स्वतःच जागा घेते, म्हणजे RAM काहीतरी चुकीच्या द्वारे वापरली जात आहे. यावेळी डॉ.

दोन - अशा परिस्थितीत कॅशे जितकी जास्त वाढेल तितकी तुमच्याकडे कॅशे चुकण्याची शक्यता जास्त आहे. आणि या कॅशेची कार्यक्षमता झपाट्याने कमी होते कारण त्याचा आकार वाढतो. म्हणून, ऑपरेटिंग सिस्टम एक सोपा दृष्टीकोन घेऊन आले. हे लिनक्समध्ये बर्याच काळापासून वापरले जात आहे. हे फ्रीबीएसडीमध्ये फार पूर्वी दिसले नाही. पण आपण लिनक्सबद्दल बोलत आहोत. ही मोठी पाने आहेत.

आणि येथे हे लक्षात घेतले पाहिजे की एक कल्पना म्हणून प्रचंड पृष्ठे, सुरुवातीला ओरॅकल आणि IBM समाविष्ट असलेल्या समुदायांद्वारे ढकलली गेली होती, म्हणजे डेटाबेस उत्पादकांना ठामपणे वाटले की हे डेटाबेससाठी देखील उपयुक्त ठरेल.

आणि हे PostgreSQL शी मैत्री कशी करता येईल? प्रथम, लिनक्स कर्नलमध्ये मोठी पृष्ठे सक्षम करणे आवश्यक आहे.

दुसरे म्हणजे, ते sysctl पॅरामीटरने स्पष्टपणे निर्दिष्ट केले पाहिजे - तेथे किती आहेत. येथील क्रमांक काही जुन्या सर्व्हरचे आहेत. तुमच्याकडे किती सामायिक बफर आहेत याची तुम्ही गणना करू शकता जेणेकरून मोठी पृष्ठे तेथे बसू शकतील.

आणि जर तुमचा संपूर्ण सर्व्हर PostgreSQL ला समर्पित असेल, तर RAM च्या 25% शेअर केलेल्या बफरसाठी किंवा 75% तुमचा डेटाबेस निश्चितपणे या 75% मध्ये बसेल याची तुम्हाला खात्री असल्यास 256% वाटप करणे हा एक चांगला प्रारंभ बिंदू आहे. सुरुवातीचा मुद्दा एक. आणि विचार करा, जर तुमच्याकडे 64 GB RAM असेल, तर त्यानुसार, तुमच्याकडे XNUMX GB मोठे बफर असतील. काही फरकाने अंदाजे गणना करा - ही आकृती कशावर सेट करावी.

आवृत्ती 9.2 पूर्वी (जर माझी चूक नसेल तर आवृत्ती 8.2 पासून), तृतीय-पक्ष लायब्ररी वापरून पोस्टग्रेएसक्यूएलला मोठ्या पृष्ठांसह कनेक्ट करणे शक्य होते. आणि हे नेहमी केले पाहिजे. प्रथम, तुम्हाला प्रचंड पृष्ठे योग्यरित्या वाटप करण्यास सक्षम होण्यासाठी कर्नल आवश्यक आहे. आणि, दुसरे म्हणजे, जेणेकरुन त्यांच्यासह कार्य करणारे अनुप्रयोग त्यांचा वापर करू शकतील. ते फक्त अशा प्रकारे वापरले जाणार नाही. PostgreSQL ने प्रणाली 5 शैलीमध्ये मेमरी वाटप केल्यामुळे, हे libhugetlbfs वापरून केले जाऊ शकते - हे लायब्ररीचे पूर्ण नाव आहे.

9.3 मध्ये, मेमरीसह कार्य करताना PostgreSQL कार्यप्रदर्शन सुधारले गेले आणि सिस्टम 5 मेमरी वाटप पद्धत सोडण्यात आली. प्रत्येकजण खूप आनंदी होता, कारण अन्यथा तुम्ही एका मशीनवर दोन PostgreSQL उदाहरणे चालवण्याचा प्रयत्न कराल आणि तो म्हणतो की माझ्याकडे पुरेशी सामायिक मेमरी नाही. आणि तो म्हणतो की sysctl दुरुस्त करणे आवश्यक आहे. आणि असे एक sysctl आहे की आपल्याला अद्याप रीबूट करणे आवश्यक आहे, इ. सर्वसाधारणपणे, प्रत्येकजण आनंदी होता. परंतु mmap मेमरी वाटपाने प्रचंड पृष्ठांचा वापर खंडित केला. आमचे बहुतेक क्लायंट मोठ्या सामायिक बफर वापरतात. आणि आम्ही 9.3 वर स्विच न करण्याची जोरदार शिफारस केली, कारण तेथे ओव्हरहेड चांगल्या टक्केवारीत मोजले जाऊ लागले.

परंतु समुदायाने या समस्येकडे लक्ष दिले आणि 9.4 मध्ये त्यांनी हा कार्यक्रम अतिशय चांगल्या प्रकारे पुन्हा केला. आणि 9.4 मध्ये postgresql.conf मध्ये एक पॅरामीटर दिसला ज्यामध्ये तुम्ही प्रयत्न, चालू किंवा बंद सक्षम करू शकता.

प्रयत्न हा सर्वात सुरक्षित पर्याय आहे. जेव्हा PostgreSQL सुरू होते, जेव्हा ते सामायिक मेमरी वाटप करते, तेव्हा ती ही मेमरी मोठ्या पृष्ठांवरून हस्तगत करण्याचा प्रयत्न करते. आणि जर ते कार्य करत नसेल, तर ते सामान्य निवडीवर परत येईल. आणि जर तुमच्याकडे फ्रीबीएसडी किंवा सोलारिस असेल तर तुम्ही प्रयत्न करू शकता, ते नेहमीच सुरक्षित असते.

जर चालू असेल, तर ते मोठ्या पृष्ठांमधून निवडू शकत नसल्यास ते सुरू होत नाही. कोण आणि काय चांगले आहे याबद्दल येथे आधीच आहे. परंतु जर तुम्ही प्रयत्न केला असेल, तर तुम्हाला जे हवे आहे ते तुमच्याकडे ठळकपणे आहे का ते तपासा, कारण त्रुटीसाठी भरपूर जागा आहे. सध्या ही कार्यक्षमता फक्त Linux वर कार्य करते.

आपण पुढे जाण्यापूर्वी आणखी एक छोटी टीप. पारदर्शक प्रचंड पृष्ठे अद्याप PostgreSQL बद्दल नाहीत. तो त्यांचा सामान्यपणे वापर करू शकत नाही. आणि अशा वर्कलोडसाठी पारदर्शक प्रचंड पृष्ठांसह, जेव्हा सामायिक मेमरीचा मोठा तुकडा आवश्यक असतो, तेव्हा फायदे फक्त खूप मोठ्या प्रमाणात येतात. जर तुमच्याकडे टेराबाइट्सची मेमरी असेल तर हे लागू होऊ शकते. जर आम्ही अधिक रोजच्या ऍप्लिकेशन्सबद्दल बोलत आहोत, जेव्हा तुमच्या मशीनवर 32, 64, 128, 256 GB मेमरी असते, तेव्हा नेहमीची मोठी पृष्ठे ओके असतात आणि आम्ही फक्त पारदर्शक अक्षम करतो.

आणि स्मरणशक्तीची शेवटची गोष्ट थेट फ्रूटशी संबंधित नाही, ती खरोखरच तुमचे जीवन उध्वस्त करू शकते. सर्व्हर सतत अदलाबदल होत असल्यामुळे सर्व थ्रुपुटवर मोठ्या प्रमाणात परिणाम होईल.

आणि हे बर्याच मार्गांनी खूप अप्रिय असेल. आणि मुख्य समस्या अशी आहे की आधुनिक कर्नल जुन्या लिनक्स कर्नलपेक्षा थोड्या वेगळ्या पद्धतीने वागतात. आणि ही गोष्ट पुढे जाणे खूप अप्रिय आहे, कारण जेव्हा आपण स्वॅपसह काही प्रकारच्या कामाबद्दल बोलतो तेव्हा ते ओओएम-किलरच्या अकाली आगमनाने संपते. आणि OOM-किलर, जो वेळेवर आला नाही आणि PostgreSQL सोडला, तो अप्रिय आहे. प्रत्येकाला याबद्दल माहिती असेल, म्हणजेच शेवटच्या वापरकर्त्यापर्यंत.

काय चाललय? तुमच्याकडे मोठ्या प्रमाणात RAM आहे, सर्वकाही चांगले कार्य करते. परंतु काही कारणास्तव सर्व्हर स्वॅपमध्ये हँग होतो आणि यामुळे स्लो होतो. असे दिसते की खूप स्मृती आहे, परंतु हे घडते.

पूर्वी, आम्ही vm.swappiness शून्यावर सेट करण्याचा सल्ला दिला, म्हणजे स्वॅप अक्षम करणे. पूर्वी, असे दिसत होते की 32 GB RAM आणि संबंधित सामायिक बफर ही खूप मोठी रक्कम होती. जर आपण खाली पडलो तर कवच फेकण्यासाठी जागा असणे हा स्वॅपचा मुख्य हेतू आहे. आणि यापुढे ते विशेषतः पूर्ण झाले नाही. आणि मग या कवचाचे काय करणार आहात? हे असे कार्य आहे जेथे स्वॅप का आवश्यक आहे हे अगदी स्पष्ट नाही, विशेषत: अशा आकाराचे.

परंतु अधिक आधुनिक, म्हणजे कर्नलच्या तिसऱ्या आवृत्त्यांमध्ये, वर्तन बदलले आहे. आणि जर तुम्ही स्वॅप शून्यावर सेट केले, म्हणजे ते बंद केले, तर लवकरच किंवा नंतर, काही रॅम शिल्लक असली तरीही, सर्वात गहन ग्राहकांना मारण्यासाठी एक OOM किलर तुमच्याकडे येईल. कारण तो विचार करेल की एवढ्या वर्कलोडसह आपल्याकडे अजून थोडासा शिल्लक आहे आणि आपण बाहेर उडी मारू, म्हणजे, सिस्टम प्रक्रियेला खिळखिळे करण्यासाठी नाही, परंतु कमी महत्त्वाचे काहीतरी कमी करण्यासाठी. हे कमी महत्त्वाचे म्हणजे शेअर्ड मेमरीचा सखोल ग्राहक असेल, म्हणजे पोस्टमास्टर. आणि त्यानंतर बेस पुनर्संचयित करणे आवश्यक नसल्यास ते चांगले होईल.

म्हणून, आता डिफॉल्ट, माझ्या लक्षात आल्याप्रमाणे, बहुतेक वितरणे 6 च्या आसपास आहेत, म्हणजे किती मेमरी शिल्लक आहे यावर अवलंबून तुम्ही स्वॅप वापरणे कोणत्या टप्प्यावर सुरू करावे. आम्ही आता vm.swappiness = 1 सेट करण्याची शिफारस करतो, कारण हे व्यावहारिकरित्या ते बंद करते, परंतु OOM-किलर सारखे परिणाम देत नाही जे अनपेक्षितपणे आले आणि संपूर्ण गोष्ट मारली.

पुढे काय? जेव्हा आपण डेटाबेसच्या कार्यक्षमतेबद्दल बोलतो आणि हळूहळू डिस्ककडे जातो तेव्हा प्रत्येकजण आपले डोके पकडू लागतो. कारण डिस्क मंद असते आणि स्मरणशक्ती जलद असते हे सत्य लहानपणापासून सर्वांनाच परिचित आहे. आणि प्रत्येकाला माहित आहे की डेटाबेसमध्ये डिस्क कार्यप्रदर्शन समस्या असतील.

चेकपॉईंट स्पाइकशी संबंधित मुख्य PostgreSQL कार्यप्रदर्शन समस्या उद्भवत नाही कारण डिस्क मंद आहे. हे बहुधा मेमरी आणि डिस्क बँडविड्थ संतुलित नसल्यामुळे आहे. तथापि, ते वेगवेगळ्या ठिकाणी संतुलित असू शकत नाहीत. PostgreSQL कॉन्फिगर केलेले नाही, OS कॉन्फिगर केलेले नाही, हार्डवेअर कॉन्फिगर केलेले नाही आणि हार्डवेअर चुकीचे आहे. आणि ही समस्या तेव्हाच घडत नाही जेव्हा सर्वकाही जसे पाहिजे तसे घडते, म्हणजे एकतर कोणतेही लोड नसते किंवा सेटिंग्ज आणि हार्डवेअर योग्यरित्या निवडलेले असतात.

ते काय आहे आणि ते कसे दिसते? सहसा PostgreSQL सह काम करणारे लोक या प्रकरणात एकापेक्षा जास्त वेळा प्रवेश करतात. मी समजावून सांगेन. मी म्हटल्याप्रमाणे, PostgreSQL वेळोवेळी डिस्कवर शेअर केलेल्या मेमरीमधील गलिच्छ पृष्ठे टाकण्यासाठी चेकपॉईंट बनवते. आमच्याकडे मोठ्या प्रमाणात सामायिक मेमरी असल्यास, चेकपॉईंटचा डिस्कवर तीव्र प्रभाव पडू लागतो, कारण ते ही पृष्ठे fsync सह डंप करते. हे कर्नल बफरमध्ये येते आणि fsync वापरून डिस्कवर लिहिले जाते. आणि जर या व्यवसायाचे प्रमाण मोठे असेल तर आम्ही एक अप्रिय परिणाम पाहू शकतो, म्हणजे डिस्कचा खूप मोठा वापर.

येथे माझ्याकडे दोन चित्रे आहेत. ते काय आहे ते मी आता स्पष्ट करेन. हे दोन वेळ-संबंधित आलेख आहेत. पहिला आलेख डिस्कचा वापर आहे. येथे ते या वेळी जवळजवळ 90% पर्यंत पोहोचते. जर तुमच्याकडे RAID कंट्रोलरच्या 90% वापरासह भौतिक डिस्कसह डेटाबेस अपयशी ठरला असेल, तर ही वाईट बातमी आहे. याचा अर्थ असा की थोडे अधिक आणि ते 100 पर्यंत पोहोचेल आणि I/O थांबेल.

जर तुमच्याकडे डिस्क अॅरे असेल तर ती थोडी वेगळी कथा आहे. ते कसे कॉन्फिगर केले आहे, ते कोणत्या प्रकारचे अॅरे आहे, इत्यादींवर अवलंबून असते.

आणि समांतर, अंतर्गत पोस्टग्रेस दृश्याचा आलेख येथे कॉन्फिगर केला आहे, जो चेकपॉईंट कसा होतो हे सांगते. आणि येथे हिरवा रंग दर्शवितो की किती बफर, ही गलिच्छ पृष्ठे, त्या क्षणी या चेकपॉईंटवर सिंक्रोनाइझेशनसाठी आली होती. आणि आपल्याला येथे माहित असणे आवश्यक असलेली ही मुख्य गोष्ट आहे. आम्ही पाहतो की आमच्याकडे येथे बरीच पृष्ठे आहेत आणि काही क्षणी आम्ही बोर्डवर आदळतो, म्हणजे, आम्ही लिहिले आणि लिहिले, येथे डिस्क सिस्टम स्पष्टपणे खूप व्यस्त आहे. आणि आमच्या चेकपॉईंटचा डिस्कवर खूप मजबूत प्रभाव आहे. आदर्शपणे, परिस्थिती यासारखी दिसली पाहिजे, म्हणजे आमच्याकडे येथे कमी रेकॉर्डिंग होते. आणि आम्ही सेटिंग्जसह त्याचे निराकरण करू शकतो जेणेकरून ते असेच चालू राहील. म्हणजे, रिसायकलिंग लहान आहे, परंतु कुठेतरी आपण येथे काहीतरी लिहित आहोत.

या समस्येवर मात करण्यासाठी काय करणे आवश्यक आहे? जर तुम्ही डेटाबेस अंतर्गत IO थांबवले असेल, तर याचा अर्थ असा की त्यांच्या विनंत्या पूर्ण करण्यासाठी आलेले सर्व वापरकर्ते प्रतीक्षा करतील.

तुम्ही लिनक्सच्या दृष्टिकोनातून पाहिल्यास, तुम्ही चांगले हार्डवेअर घेतले असल्यास, ते योग्यरितीने कॉन्फिगर केले असल्यास, PostgreSQL साधारणपणे कॉन्फिगर केले आहे जेणेकरुन ते या चेकपॉइंट्स कमी वेळा बनवतील, ते एकमेकांमध्ये कालांतराने पसरतील, तर तुम्ही डीफॉल्ट डेबियन पॅरामीटर्समध्ये पाऊल टाकाल. बहुतेक लिनक्स वितरणासाठी, हे चित्र आहे: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

याचा अर्थ काय? कर्नल 2.6 मधून एक फ्लशिंग राक्षस दिसला. Pdglush, कोण कोणते वापरत आहे यावर अवलंबून आहे, जे कर्नल बफरमधून गलिच्छ पृष्ठे काढून टाकण्यात गुंतलेले आहे आणि घाणेरडी पृष्ठे टाकून देणे आवश्यक असताना टाकून देणे आवश्यक आहे, काहीही असो, जेव्हा बॅकग्राउंड टाकून देणे मदत करत नाही.

पार्श्वभूमी कधी येते? जेव्हा सर्व्हरवर उपलब्ध असलेल्या एकूण RAMपैकी 10% कर्नल बफरमधील गलिच्छ पृष्ठांनी व्यापलेले असते, तेव्हा पार्श्वभूमीत एक विशेष लेखन-ऑफ फंक्शन कॉल केले जाते. त्याची पार्श्वभूमी का आहे? पॅरामीटर म्हणून, किती पृष्ठे लिहायची हे विचारात घेते. आणि, समजा, तो N पृष्ठे लिहितो. आणि थोडा वेळ ही गोष्ट झोपी जाते. आणि मग ती पुन्हा येते आणि आणखी काही पाने कॉपी करते.

ही एक अत्यंत साधी कथा आहे. येथे समस्या जलतरण तलावासारखी आहे, जेव्हा ते एका पाईपमध्ये ओतले जाते तेव्हा ते दुसर्यामध्ये वाहते. आमचा चेकपॉईंट आला आणि जर त्याने काही गलिच्छ पृष्ठे टाकून देण्यासाठी पाठवली, तर हळूहळू संपूर्ण गोष्ट कर्नल बफर pgflush मधून व्यवस्थितपणे सोडवली जाईल.

जर ही घाणेरडी पृष्ठे जमा होत राहिली तर ते 20% पर्यंत जमा होतात, त्यानंतर OS प्राधान्य म्हणजे संपूर्ण गोष्ट डिस्कवर लिहिणे, कारण शक्ती अयशस्वी होईल आणि सर्व काही आपल्यासाठी वाईट होईल. आम्ही हा डेटा गमावू, उदाहरणार्थ.

युक्ती काय आहे? युक्ती अशी आहे की आधुनिक जगात हे पॅरामीटर्स मशीनवर असलेल्या एकूण RAM च्या 20 आणि 10% आहेत, ते तुमच्याकडे असलेल्या कोणत्याही डिस्क सिस्टमच्या थ्रूपुटच्या बाबतीत पूर्णपणे राक्षसी आहेत.

कल्पना करा की तुमच्याकडे 128 GB RAM आहे. 12,8 GB तुमच्या डिस्क सिस्टममध्ये येतो. आणि तुमच्याकडे तिथे कोणती कॅशे आहे, तुमच्याकडे कोणता अॅरे आहे हे महत्त्वाचे नाही, ते फार काळ टिकणार नाहीत.

म्हणून, आम्ही शिफारस करतो की तुम्ही तुमच्या RAID कंट्रोलरच्या क्षमतेवर आधारित हे क्रमांक त्वरित समायोजित करा. 512 MB कॅशे असलेल्या कंट्रोलरसाठी मी त्वरित येथे शिफारस केली आहे.

सर्व काही अगदी सोपे मानले जाते. तुम्ही vm.dirty_background बाइट्समध्ये टाकू शकता. आणि या सेटिंग्ज मागील दोन रद्द करतात. एकतर गुणोत्तर डीफॉल्टनुसार आहे, किंवा बाइट्स असलेले सक्रिय केले आहेत, नंतर बाइट्स असलेले कार्य करतील. पण मी डीबीए सल्लागार असल्याने आणि वेगवेगळ्या क्लायंटसोबत काम करत असल्याने, मी स्ट्रॉ काढण्याचा प्रयत्न करतो आणि म्हणून, जर बाइटमध्ये असेल तर बाइटमध्ये. एक चांगला प्रशासक सर्व्हरमध्ये अधिक मेमरी जोडणार नाही, तो रीबूट करणार नाही आणि आकृती तशीच राहील याची कोणीही हमी दिली नाही. फक्त या संख्यांची गणना करा जेणेकरून सर्व काही हमीसह बसेल.

आपण फिट न झाल्यास काय होईल? मी लिहिले आहे की कोणतीही फ्लशिंग प्रभावीपणे थांबविली जाते, परंतु प्रत्यक्षात ही भाषणाची आकृती आहे. ऑपरेटिंग सिस्टममध्ये एक मोठी समस्या आहे - त्यात बरीच घाणेरडी पृष्ठे आहेत, त्यामुळे तुमचे क्लायंट तयार करत असलेला IO प्रभावीपणे थांबला आहे, म्हणजे अनुप्रयोग डेटाबेसला sql क्वेरी पाठवण्यासाठी आला आहे, तो प्रतीक्षा करत आहे. त्यात कोणतेही इनपुट/आउटपुट हे सर्वात कमी प्राधान्य असते, कारण डेटाबेस चेकपॉईंटने व्यापलेला असतो. आणि ती कधी पूर्ण करेल हे पूर्णपणे अस्पष्ट आहे. आणि जेव्हा तुम्ही पार्श्वभूमी नसलेले फ्लशिंग साध्य करता, तेव्हा याचा अर्थ असा होतो की तुमचे सर्व IO त्यात व्यापलेले आहेत. आणि तो संपेपर्यंत तुम्ही काहीही करणार नाही.

येथे आणखी दोन महत्त्वाचे मुद्दे आहेत जे या अहवालाच्या व्याप्तीच्या बाहेर आहेत. या सेटिंग्ज postgresql.conf मधील सेटिंग्जशी जुळल्या पाहिजेत, म्हणजे चेकपॉइंट सेटिंग्ज. आणि तुमची डिस्क सिस्टम पुरेशी कॉन्फिगर केलेली असणे आवश्यक आहे. आपल्याकडे RAID वर कॅशे असल्यास, त्यात बॅटरी असणे आवश्यक आहे. लोक बॅटरीशिवाय चांगल्या कॅशेसह RAID खरेदी करतात. जर तुमच्याकडे RAID मध्ये SSD असतील, तर ते सर्व्हर असले पाहिजेत, तेथे कॅपेसिटर असणे आवश्यक आहे. येथे तपशीलवार चेकलिस्ट आहे. या दुव्यामध्ये PostgreSQL मध्ये परफॉर्मन्स डिस्क कशी कॉन्फिगर करावी याबद्दलचा माझा अहवाल आहे. तेथे या सर्व चेकलिस्ट आहेत.

दुसरे काय जीवन खूप कठीण करू शकते? हे दोन पॅरामीटर्स आहेत. ते तुलनेने नवीन आहेत. डीफॉल्टनुसार, ते वेगवेगळ्या अनुप्रयोगांमध्ये समाविष्ट केले जाऊ शकतात. आणि जर ते चुकीच्या पद्धतीने चालू केले तर ते जीवन तितकेच कठीण बनवू शकतात.

दोन तुलनेने नवीन गोष्टी आहेत. ते आधीच तिसऱ्या कोरमध्ये दिसू लागले आहेत. ही sched_migration_cost आहे नॅनोसेकंद आणि sched_autogroup_enabled, जी डीफॉल्टनुसार एक आहे.

आणि ते तुमचे आयुष्य कसे उध्वस्त करतात? शेड_माइग्रेशन_कॉस्ट म्हणजे काय? लिनक्सवर, शेड्युलर प्रक्रिया एका CPU वरून दुसऱ्या CPU मध्ये स्थलांतरित करू शकतो. आणि PostgreSQL साठी, जे क्वेरी कार्यान्वित करते, दुसर्या CPU वर स्थलांतर करणे पूर्णपणे अस्पष्ट आहे. ऑपरेटिंग सिस्टमच्या दृष्टिकोनातून, जेव्हा तुम्ही ओपन ऑफिस आणि टर्मिनल दरम्यान विंडो स्विच करता तेव्हा हे चांगले असू शकते, परंतु डेटाबेससाठी हे खूप वाईट आहे. त्यामुळे, स्थलांतर_किंमत काही मोठ्या मूल्यावर, किमान हजारो नॅनोसेकंदांवर सेट करणे हे वाजवी धोरण आहे.

शेड्युलरसाठी याचा अर्थ काय असेल? हे मानले जाईल की या काळात प्रक्रिया अद्याप गरम आहे. म्हणजेच, जर तुमच्याकडे दीर्घकाळ चालणारा व्यवहार असेल जो बर्याच काळापासून काहीतरी करत असेल तर शेड्युलरला हे समजेल. तो असे गृहीत धरेल की हा कालबाह्य होईपर्यंत, ही प्रक्रिया कोठेही स्थलांतरित करण्याची आवश्यकता नाही. जर त्याच वेळी प्रक्रियेने काही केले तर ते कोठेही स्थलांतरित केले जाणार नाही, ते त्याला वाटप केलेल्या CPU वर शांतपणे कार्य करेल. आणि परिणाम उत्कृष्ट आहे.

दुसरा मुद्दा ऑटोग्रुप आहे. आधुनिक डेटाबेसशी संबंधित नसलेल्या विशिष्ट वर्कलोड्ससाठी एक चांगली कल्पना आहे - हे व्हर्च्युअल टर्मिनलद्वारे प्रक्रियांचे गट करणे आहे ज्यावरून ते लॉन्च केले जातात. हे काही कामांसाठी सोयीचे आहे. सराव मध्ये, PostgreSQL ही प्रीफोर्क असलेली मल्टी-प्रोसेस सिस्टीम आहे जी एकाच टर्मिनलवरून चालते. तुमच्याकडे लॉक रायटर, चेकपॉईंट आहे आणि तुमच्या सर्व क्लायंट विनंत्या एका शेड्युलरमध्ये, प्रत्येक CPU मध्ये गटबद्ध केल्या जातील. आणि एकमेकांमध्ये व्यत्यय आणण्यासाठी आणि त्याला अधिक काळ व्यापून ठेवण्यासाठी ते मोकळे होण्याची प्रतीक्षा करतील. ही एक कथा आहे जी अशा लोडच्या बाबतीत पूर्णपणे अनावश्यक आहे आणि म्हणून ती बंद करणे आवश्यक आहे.

माझे सहकारी अॅलेक्सी लेसोव्स्की यांनी एका साध्या pgbench सह चाचण्या केल्या, जेथे त्याने परिमाणाच्या ऑर्डरने migration_cost वाढवले ​​आणि ऑटोग्रुप बंद केले. खराब हार्डवेअरवरील फरक जवळजवळ 10% होता. पोस्टग्रेस मेलिंग लिस्टवर चर्चा आहे जिथे लोक क्वेरी स्पीडमध्ये समान बदलांचे परिणाम देतात ५०% प्रभावित. अशा अनेक कथा आहेत.

आणि शेवटी, वीज बचत धोरणाबद्दल. चांगली गोष्ट म्हणजे लिनक्स आता लॅपटॉपवर वापरता येणार आहे. आणि त्यामुळे बॅटरी चांगल्या प्रकारे वापरली जाईल. परंतु अचानक असे दिसून आले की हे सर्व्हरवर देखील होऊ शकते.

शिवाय, तुम्ही काही होस्टरकडून सर्व्हर भाड्याने घेतल्यास, "चांगले" होस्टर्सना तुमची कामगिरी चांगली आहे याची काळजी नाही. त्यांचे कार्य हे सुनिश्चित करणे आहे की त्यांचे लोह शक्य तितक्या कार्यक्षमतेने वापरला जाईल. म्हणून, डीफॉल्टनुसार ते ऑपरेटिंग सिस्टमवर लॅपटॉप पॉवर सेव्हिंग मोड सक्षम करू शकतात.

जर तुम्ही ही सामग्री जास्त भाराखाली डेटाबेस असलेल्या सर्व्हरवर वापरत असाल, तर तुमची निवड acpi_cpufreq + permormance आहे. ओंडमांड करूनही समस्या असतील.

Intel_pstate हा थोडा वेगळा ड्रायव्हर आहे. आणि आता याला प्राधान्य दिले जाते, कारण ते नंतरचे आहे आणि चांगले कार्य करते.

आणि त्यानुसार, राज्यपाल ही केवळ कामगिरी आहे. ओन्डमांड, पॉवरसेव्ह आणि इतर सर्व काही तुमच्याबद्दल नाही.

तुम्ही पॉवरसेव्ह सक्षम केल्यास स्पष्टीकरण विश्लेषण पोस्टग्रेएसक्यूएलचे परिणाम भिन्न असू शकतात, कारण तुमच्या डेटाबेस अंतर्गत सीपीयू व्यावहारिकदृष्ट्या पूर्णपणे अप्रत्याशित मार्गाने चालत असेल.

हे आयटम डीफॉल्टनुसार समाविष्ट केले जाऊ शकतात. त्यांनी ते डीफॉल्टनुसार चालू केले आहे का ते पाहण्यासाठी काळजीपूर्वक पहा. ही खरोखर मोठी समस्या असू शकते.

आणि सरतेशेवटी, मला आमच्या PosgreSQL-कन्सल्टिंग डीबीए टीम, मॅक्स बोगुक आणि अॅलेक्सी लेसोव्स्की, जे या प्रकरणात दररोज प्रगती करत आहेत, त्यांचे आभार मानायचे होते. आणि आम्ही आमच्या क्लायंटसाठी शक्य तितके सर्वोत्तम करण्याचा प्रयत्न करतो जेणेकरून हे सर्व त्यांच्यासाठी कार्य करेल. हे विमान वाहतूक सुरक्षा निर्देशांसारखे आहे. इथे सर्व काही रक्ताने लिहिलेले आहे. यातील प्रत्येक नट कोणत्या ना कोणत्या प्रक्रियेत सापडतो. ते तुमच्यासोबत शेअर करताना मला आनंद होत आहे.

प्रश्नः

धन्यवाद! उदाहरणार्थ, एखाद्या कंपनीला पैसे वाचवायचे असतील आणि डेटाबेस आणि अॅप्लिकेशन लॉजिक एका सर्व्हरवर ठेवायचे असेल किंवा कंपनी मायक्रोसर्व्हिस आर्किटेक्चरच्या फॅशनेबल ट्रेंडचे अनुसरण करत असेल, ज्यामध्ये PostgreSQL कंटेनरमध्ये चालते. युक्ती काय आहे? Sysctl संपूर्ण कर्नलवर जागतिक स्तरावर परिणाम करेल. मी sysctls कसेतरी वर्च्युअलाइज केले आहे असे ऐकले नाही जेणेकरून ते कंटेनरवर स्वतंत्रपणे कार्य करतात. तेथे फक्त एक cgroup आहे आणि तेथे फक्त नियंत्रणाचा भाग आहे. आपण यासह कसे जगू शकता? किंवा तुम्हाला परफॉर्मन्स हवा असेल तर वेगळ्या हार्डवेअर सर्व्हरवर PostgreSQL चालवा आणि ट्यून करा?

आम्ही तुमच्या प्रश्नाचे उत्तर तीन प्रकारे दिले. जर आपण हार्डवेअर सर्व्हरबद्दल बोलत नसाल जे ट्यून केले जाऊ शकते, इत्यादी, नंतर आराम करा, या सेटिंग्जशिवाय सर्व काही ठीक होईल. जर तुमच्याकडे एवढा भार असेल की तुम्हाला या सेटिंग्ज बनवण्याची आवश्यकता असेल, तर तुम्ही या सेटिंग्जच्या आधी लोह सर्व्हरवर याल.

काय अडचण आहे? जर हे व्हर्च्युअल मशीन असेल, तर बहुधा तुम्हाला बर्‍याच समस्या असतील, उदाहरणार्थ, बहुतेक व्हर्च्युअल मशीनवर डिस्कची विलंबता अगदी विसंगत आहे. जरी डिस्क थ्रूपुट चांगला असला तरीही, चेकपॉईंटच्या वेळी किंवा WAL ला लिहिण्याच्या वेळी झालेल्या सरासरी थ्रूपुटवर एक अयशस्वी I/O व्यवहार झाला, तर डेटाबेसला याचा मोठा फटका बसेल. आणि आपण या समस्यांकडे जाण्यापूर्वी हे लक्षात येईल.

तुमच्याकडे त्याच सर्व्हरवर NGINX असल्यास, तुम्हालाही हीच समस्या असेल. तो सामायिक स्मरणशक्तीसाठी लढेल. आणि तुम्ही येथे वर्णन केलेल्या समस्यांकडे जाणार नाही.

परंतु दुसरीकडे, यापैकी काही पॅरामीटर्स अद्याप आपल्यासाठी संबंधित असतील. उदाहरणार्थ, sysctl सह dirty_ratio सेट करा जेणेकरून ते इतके वेडे होणार नाही - कोणत्याही परिस्थितीत, हे मदत करेल. एक मार्ग किंवा दुसरा, तुमचा डिस्कशी संवाद असेल. आणि ते चुकीच्या पद्धतीनुसार असेल. मी दर्शविलेल्या पॅरामीटर्ससाठी हे सामान्यतः डीफॉल्ट आहे. आणि कोणत्याही परिस्थितीत ते बदलणे चांगले.

परंतु NUMA मध्ये समस्या असू शकतात. VmWare, उदाहरणार्थ, NUMA सह अगदी उलट सेटिंग्जसह चांगले कार्य करते. आणि येथे तुम्हाला निवडावे लागेल - लोखंडी सर्व्हर किंवा लोह नसलेला.

मला Amazon AWS शी संबंधित प्रश्न आहे. त्यांच्याकडे पूर्व-कॉन्फिगर केलेल्या प्रतिमा आहेत. त्यापैकी एकाला Amazon RDS म्हणतात. त्यांच्या ऑपरेटिंग सिस्टमसाठी काही कस्टम सेटिंग्ज आहेत का?

तेथे सेटिंग्ज आहेत, परंतु त्या भिन्न सेटिंग्ज आहेत. डेटाबेस ही गोष्ट कशी वापरेल या संदर्भात आम्ही ऑपरेटिंग सिस्टम कॉन्फिगर करतो. आणि असे पॅरामीटर्स आहेत जे ठरवतात की आपण आता कुठे जायचे आहे, जसे की आकार देणे. म्हणजेच, आपल्याला बर्याच संसाधनांची आवश्यकता आहे, आपण आता ते खाऊ. यानंतर, Amazon RDS ही संसाधने घट्ट करते आणि कार्यप्रदर्शन कमी होते. लोक या प्रकरणाशी कसे गोंधळ करू लागले आहेत याच्या वैयक्तिक कथा आहेत. कधीकधी अगदी यशस्वीपणे. परंतु याचा OS सेटिंग्जशी काहीही संबंध नाही. हे क्लाउड हॅक करण्यासारखे आहे. ती वेगळी कथा आहे.

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

देऊ नकोस. हे अनेक प्रकारे स्पष्ट केले जाऊ शकते. पण प्रत्यक्षात ते ते देत नाहीत. PostgreSQL चा इतिहास काय आहे? स्टार्टअपवर, ते सामायिक मेमरीचा एक मोठा भाग वाटप करते. ते पारदर्शक आहेत की नाही हे पूर्णपणे अप्रासंगिक आहे. सुरुवातीला ते वेगळे दिसतात हे सर्व काही स्पष्ट करते. आणि जर भरपूर मेमरी असेल आणि तुम्हाला शेअर्ड_मेमरी सेगमेंट पुन्हा तयार करायचा असेल, तर पारदर्शक विशाल पृष्ठे संबंधित असतील. PostgreSQL मध्ये, हे फक्त सुरुवातीला मोठ्या प्रमाणात वाटप केले जाते आणि तेच आहे, आणि नंतर तेथे काहीही विशेष घडत नाही. तुम्ही अर्थातच, ते वापरू शकता, परंतु शेअर्ड_मेमरी जेव्हा काहीतरी पुन्हा वाटप करते तेव्हा ते खराब होण्याची शक्यता असते. PostgreSQL ला याबद्दल माहिती नाही.

स्त्रोत: www.habr.com