PostgreSQL प्रदर्शन सुधार गर्न लिनक्स ट्युनिङ। इल्या Kosmodemyansky

Ilya Kosmodemyansky द्वारा 2015 रिपोर्ट को ट्रान्सक्रिप्ट "PostgreSQL प्रदर्शन सुधार गर्न लिनक्स ट्युनिंग"

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

मेरो नाम Ilya Kosmodemyansky हो। PostgreSQL-Consulting मा काम गर्नुहुन्छ र अब म सामान्यमा डेटाबेस र PostgreSQL को सम्बन्धमा लिनक्ससँग के गर्ने भन्ने बारे थोरै कुरा गर्नेछु, किनकि सिद्धान्तहरू एकदम समान छन्।

हामी के कुरा गर्ने? यदि तपाइँ PostgreSQL सँग सञ्चार गर्नुहुन्छ भने, केहि हदसम्म तपाइँ UNIX प्रशासक हुन आवश्यक छ। यसको मतलब के हो? यदि हामी Oracle र PostgreSQL को तुलना गर्छौं भने, Oracle मा तपाइँ 80% DBA डाटाबेस प्रशासक र 20% लिनक्स प्रशासक हुन आवश्यक छ।

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

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

र मलाई लाग्छ कि सबैजना सोलारिस जस्ता एक्सोटिक्समा कम चासो राख्छन्, त्यसैले जाऔं।

तपाईंले कर्नेल कसरी निर्माण गर्नुहुन्छ भन्ने आधारमा आधुनिक लिनक्स वितरणमा 1 syctl विकल्पहरू छन्। एकै समयमा, यदि हामी विभिन्न नटहरू हेर्छौं, हामी धेरै तरिकामा केहि समायोजन गर्न सक्छौं। तिनीहरूलाई कसरी माउन्ट गर्ने भन्ने बारे फाइल प्रणाली प्यारामिटरहरू छन्। यदि तपाइँसँग यो कसरी सुरु गर्ने बारे प्रश्नहरू छन्: BIOS मा के सक्षम गर्ने, कसरी हार्डवेयर कन्फिगर गर्ने, आदि।

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

लिनक्समा कुन परम्परागत ट्युनिङ लक्ष्यहरू छन्? मलाई लाग्छ कि तपाईं सबै लिनक्स प्रशासनसँग व्यवहार गर्दै हुनुहुन्छ, लक्ष्यहरू के हो भनेर व्याख्या गर्न कुनै विशेष आवश्यकता छैन।

तपाईं धुन गर्न सक्नुहुन्छ:

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

PostgreSQL को विशिष्टता र सामान्य मा डाटाबेस के हो? समस्या यो हो कि तपाइँ कुनै पनि व्यक्तिगत नट ट्वीक गर्न सक्नुहुन्न र हाम्रो प्रदर्शनमा उल्लेखनीय सुधार भएको छ।

हो, त्यहाँ त्यस्ता ग्याजेटहरू छन्, तर डाटाबेस एक जटिल कुरा हो। यसले सर्भरसँग भएका सबै स्रोतहरूसँग अन्तर्क्रिया गर्दछ र पूर्ण रूपमा अन्तरक्रिया गर्न रुचाउँछ। यदि तपाइँ होस्ट OS कसरी प्रयोग गर्ने बारे ओरेकलको हालको सिफारिसहरू हेर्नुभयो भने, यो मङ्गोलियन अन्तरिक्ष यात्रीको बारेमा मजाक जस्तै हुनेछ - कुकुरलाई खुवाउनुहोस् र केहि पनि नछुनुहोस्। डाटाबेसलाई सबै स्रोतहरू दिनुहोस्, डाटाबेसले नै सबै कुराहरू क्रमबद्ध गर्नेछ।

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

मुख्य विचार एकल लक्ष्य चयन गर्न र यसलाई ट्युन गर्न सुरु गर्नु होइन, उदाहरणका लागि, मेमोरी, CPU वा त्यस्ता केहि, तर कार्यभारको विश्लेषण गर्न र सकेसम्म थ्रुपुट सुधार गर्ने प्रयास गर्नुहोस् ताकि राम्रो प्रोग्रामरहरूले यसलाई सिर्जना गरेको लोड। हाम्रो लागि, हाम्रा प्रयोगकर्ताहरू सहित।

यो के हो भनेर व्याख्या गर्न यहाँ एक तस्वीर छ। त्यहाँ लिनक्स ओएस बफर छ र त्यहाँ साझा मेमोरी छ र त्यहाँ PostgreSQL साझा बफरहरू छन्। PostgreSQL, Oracle को विपरीत, केवल कर्नेल बफर मार्फत मात्र काम गर्दछ, अर्थात्, डिस्कबाट पृष्ठको लागि यसको साझा मेमोरीमा जानको लागि, यो कर्नेल बफर र पछाडि जानुपर्छ, ठ्याक्कै उही स्थिति।

डिस्क यस प्रणाली अन्तर्गत रहन्छ। मैले यसलाई डिस्कको रूपमा कोरें। वास्तवमा, त्यहाँ RAID नियन्त्रक, आदि हुन सक्छ।

र यो इनपुट-आउटपुट एक वा अर्को तरिका यो मामला मार्फत हुन्छ।

PostgreSQL एक क्लासिक डाटाबेस हो। भित्र एउटा पाना छ। र सबै इनपुट र आउटपुट पृष्ठहरू प्रयोग गरेर हुन्छ। हामी पानाहरु संग मेमोरी मा ब्लक उठाउँदै छौँ। र यदि केहि भएन भने, हामीले तिनीहरूलाई पढ्छौं, त्यसपछि बिस्तारै तिनीहरू यस क्यासबाट, साझा बफरहरूबाट गायब हुन्छन् र डिस्कमा फिर्ता समाप्त हुन्छन्।

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

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

र थ्रुपुट अधिकतम गर्ने कार्य यी सबै चरणहरूमा राम्रो-ट्यून गर्नु हो ताकि यो सबै छिटो अगाडि र पछाडि सर्छ। साझा मेमोरी मूलतया एक पृष्ठ क्यास हो। PostgreSQL मा हामीले चयन क्वेरी वा केहि पठायौं, यसले डिस्कबाट यो डाटा पुन: प्राप्त गर्यो। तिनीहरू साझा बफरहरूमा समाप्त भए। तदनुसार, यो राम्रो काम गर्न को लागी, त्यहाँ धेरै मेमोरी हुनुपर्छ।

यो सबै राम्रो र चाँडै काम गर्न को लागी, तपाईले सबै चरणहरूमा अपरेटिङ सिस्टमलाई सही रूपमा कन्फिगर गर्न आवश्यक छ। र सन्तुलित हार्डवेयर छनौट गर्नुहोस्, किनकि यदि तपाइँसँग कुनै ठाउँमा असंतुलन छ भने, तपाइँ धेरै मेमोरी बनाउन सक्नुहुन्छ, तर यो पर्याप्त गतिमा सेवा हुनेछैन।

र यी प्रत्येक बिन्दुहरू मार्फत जाऔं।

यी पृष्ठहरू अगाडि र छिटो यात्रा गर्नको लागि, तपाईंले निम्न प्राप्त गर्न आवश्यक छ:

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

यदि तपाइँसँग सर्भरमा 512 GB RAM छ र यो सबै बिना क्यास SATA हार्ड ड्राइभमा समाप्त हुन्छ, तब सम्पूर्ण डाटाबेस सर्भर कद्दू मात्र होइन, तर SATA इन्टरफेसको साथ कद्दूमा परिणत हुन्छ। तपाईं यसमा सीधै भाग्नुहुनेछ। र केहि पनि तपाईंलाई बचाउने छैन।

स्मृतिको साथ पहिलो बिन्दुको बारेमा, त्यहाँ तीनवटा चीजहरू छन् जसले जीवनलाई धेरै गाह्रो बनाउन सक्छ।

तिनीहरूमध्ये पहिलो NUMA हो। NUMA एक चीज हो जुन प्रदर्शन सुधार गर्न बनाइएको हो। कार्यभारमा निर्भर गर्दै, विभिन्न चीजहरू अनुकूलित गर्न सकिन्छ। र यसको नयाँ हालको फारममा, यो डाटाबेसहरू जस्ता अनुप्रयोगहरूको लागि धेरै राम्रो छैन जसले पृष्ठ क्यास साझा बफरहरू गहन रूपमा प्रयोग गर्दछ।

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

वास्तवमा के भइरहेको छ? NUMA Non-Uniform Memory Access को लागि खडा छ। कुरो के हो? तपाईंसँग CPU छ, यसको छेउमा यसको स्थानीय मेमोरी छ। र यो मेमोरी इन्टरकनेक्टले अन्य CPU बाट मेमोरी तान्न सक्छ।

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

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

त्यसकारण, डाटाबेसको लागि अझ सही विकल्प लिनक्स अपरेटिङ सिस्टमको लागि त्यहाँ के भइरहेको छ थाहा छैन। जसले गर्दा यसले मेमोरीमा जस्तै पहुँच गर्छ।

त्यो किन हो? यो उल्टो बाटो हुनुपर्छ जस्तो देखिन्छ। यो एउटा साधारण कारणको लागि हुन्छ: हामीलाई पृष्ठ क्यासको लागि धेरै मेमोरी चाहिन्छ - दसौं, सयौं गीगाबाइटहरू।

र यदि हामीले यो सबै आवंटित गर्यौं र हाम्रो डाटा त्यहाँ क्यास गर्यौं भने, क्यास प्रयोग गर्ने लाभ मेमोरीमा यस्तो कठिन पहुँचबाट प्राप्त हुने लाभ भन्दा महत्त्वपूर्ण हुनेछ। र हामी यस तथ्यको तुलनामा अतुलनीय रूपमा लाभ उठाउनेछौं कि हामीले NUMA प्रयोग गरेर मेमोरीलाई अझ कुशलतापूर्वक पहुँच गर्नेछौं।

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

त्यसकारण, सही दृष्टिकोण भनेको NUMA लाई पूर्ण रूपमा असक्षम पार्नु हो, उदाहरणका लागि, रिबुट गर्दा। धेरै जसो अवस्थामा, जीतहरू परिमाणको यस्तो आदेशका हुन्छन् कि कुन राम्रो हो भन्ने प्रश्न उठ्दैन।

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

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

कृपया ध्यान दिनुहोस् कि यो सबै सेटिङहरूमा लागू हुन्छ जुन म कुरा गर्नेछु। तर सामान्यतया डाटाबेसहरू दोष सहिष्णुताको लागि मास्टर-स्लेभ मोडमा सङ्कलन गरिन्छ। दासमा यी सेटिङहरू बनाउन नबिर्सनुहोस् किनभने एक दिन तपाईंसँग दुर्घटना हुनेछ र तपाईं दासमा स्विच गर्नुहुनेछ र यो मालिक बन्नेछ।

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

अर्को बिन्दु ठूलो पृष्ठ हो। ठूला पृष्ठहरू छुट्टै परीक्षण गर्न गाह्रो छ, र त्यसो गर्नको लागि कुनै अर्थ छैन, यद्यपि त्यहाँ बेन्चमार्कहरू छन् जसले यो गर्न सक्छ। तिनीहरू Google मा सजिलो छन्।

कुरो के हो? तपाईंसँग धेरै RAM भएको धेरै महँगो सर्भर छैन, उदाहरणका लागि, 30 GB भन्दा बढी। तपाईं ठूलो पृष्ठहरू प्रयोग गर्नुहुन्न। यसको मतलब मेमोरी प्रयोगको सन्दर्भमा तपाईसँग निश्चित रूपमा ओभरहेड छ। र यो ओभरहेड सबैभन्दा सुखद देखि टाढा छ।

त्यो किन हो? अनि के हुदै छ? अपरेटिङ सिस्टमले मेमोरीलाई सानो टुक्रामा बाँड्छ। यो धेरै सुविधाजनक छ, यो ऐतिहासिक रूपमा कसरी भयो। र यदि हामी विस्तारमा जान्छौं भने, OS ले भर्चुअल ठेगानाहरूलाई भौतिक ठेगानाहरूमा अनुवाद गर्नुपर्छ। र यो प्रक्रिया सरल छैन, त्यसैले OS ले अनुवाद लुकसाइड बफर (TLB) मा यो अपरेशनको परिणाम क्यास गर्दछ।

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

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

र यहाँ यो ध्यान दिनुपर्छ कि विशाल पृष्ठहरू, एक विचारको रूपमा, सुरुमा समुदायहरू द्वारा धकेलिएको थियो जसमा Oracle र IBM समावेश थियो, अर्थात् डाटाबेस निर्माताहरूले दृढतापूर्वक सोचेका थिए कि यो डाटाबेसहरूको लागि पनि उपयोगी हुनेछ।

र यसलाई कसरी PostgreSQL सँग मित्र बनाउन सकिन्छ? पहिले, लिनक्स कर्नेलमा विशाल पृष्ठहरू सक्षम हुनुपर्छ।

दोस्रो, तिनीहरू स्पष्ट रूपमा sysctl प्यारामिटर द्वारा निर्दिष्ट हुनुपर्छ - त्यहाँ कति छन्। यहाँ नम्बरहरू केही पुरानो सर्भरबाट छन्। तपाईंसँग कतिवटा साझा बफरहरू छन् भनेर गणना गर्न सक्नुहुन्छ ताकि विशाल पृष्ठहरू त्यहाँ फिट हुन सक्छन्।

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

संस्करण 9.2 अघि (यदि म गल्ती छैन, संस्करण 8.2 देखि), यो तेस्रो-पक्ष पुस्तकालय प्रयोग गरेर विशाल पृष्ठहरूसँग PostgreSQL जडान गर्न सम्भव थियो। र यो सधैं गर्नुपर्छ। पहिले, तपाईलाई ठूला पृष्ठहरू सही रूपमा आवंटित गर्न सक्षम हुन कर्नेल चाहिन्छ। र, दोस्रो, ताकि तिनीहरूसँग काम गर्ने अनुप्रयोगले तिनीहरूलाई प्रयोग गर्न सक्छ। त्यसरी मात्र प्रयोग हुने होइन। PostgreSQL ले प्रणाली 5 शैलीमा मेमोरी आवंटित गरेको हुनाले, यो libhugetlbfs प्रयोग गरेर गर्न सकिन्छ - यो पुस्तकालयको पूरा नाम हो।

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

तर समुदायले यस समस्यामा ध्यान दिए र 9.4 मा उनीहरूले यो घटनालाई राम्रोसँग पुन: काम गरे। र 9.4 मा postgresql.conf मा एउटा प्यारामिटर देखा पर्‍यो जसमा तपाईंले प्रयास गर्न सक्नुहुन्छ, अन वा अफ गर्न सक्नुहुन्छ।

प्रयास सबैभन्दा सुरक्षित विकल्प हो। जब PostgreSQL सुरु हुन्छ, जब यसले साझा मेमोरी आवंटित गर्दछ, यसले यो मेमोरीलाई विशाल पृष्ठहरूबाट समात्न प्रयास गर्दछ। र यदि यसले काम गर्दैन भने, यो सामान्य चयनमा फिर्ता हुन्छ। र यदि तपाइँसँग FreeBSD वा सोलारिस छ भने, तपाइँ प्रयास गर्न सक्नुहुन्छ, यो सधैं सुरक्षित छ।

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

हामी अगाडी जानु अघि अर्को सानो नोट। पारदर्शी विशाल पृष्ठहरू अझै PostgreSQL को बारेमा होइनन्। उसले तिनीहरूलाई सामान्य रूपमा प्रयोग गर्न सक्दैन। र यस्तो कार्यभारको लागि पारदर्शी विशाल पृष्ठहरूको साथ, जब साझा मेमोरीको ठूलो टुक्रा आवश्यक हुन्छ, फाइदाहरू केवल धेरै ठूलो मात्रामा आउँछन्। यदि तपाइँसँग टेराबाइट मेमोरी छ भने यो खेलमा आउन सक्छ। यदि हामी थप दैनिक अनुप्रयोगहरूको बारेमा कुरा गर्दैछौं, जब तपाइँसँग तपाइँको मेसिनमा 32, 64, 128, 256 GB मेमोरी हुन्छ, तब सामान्य ठूला पृष्ठहरू ठीक छ, र हामी केवल पारदर्शी असक्षम पार्छौं।

र मेमोरीको बारेमा अन्तिम कुरा फलफूलसँग प्रत्यक्ष रूपमा सम्बन्धित छैन, यसले वास्तवमै तपाईंको जीवनलाई बर्बाद गर्न सक्छ। सबै थ्रुपुट यस तथ्यबाट धेरै प्रभावित हुनेछ कि सर्भर निरन्तर स्वैप भइरहेको छ।

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

के भइरहेको छ? तपाईंसँग त्यहाँ ठूलो मात्रामा RAM छ, सबै कुरा राम्रोसँग काम गर्दछ। तर केही कारणले सर्भर स्व्यापमा ह्याङ्ग हुन्छ र यस कारणले गर्दा ढिलो हुन्छ। यस्तो देखिन्छ कि त्यहाँ धेरै मेमोरी छ, तर यो हुन्छ।

पहिले, हामीले vm.swappiness लाई शून्यमा सेट गर्न सल्लाह दियौं, अर्थात् स्वैप असक्षम गर्ने। पहिले, यस्तो देखिन्थ्यो कि 32 GB को RAM र सम्बन्धित साझा बफरहरू ठूलो रकम थियो। स्वैपको मुख्य उद्देश्य यदि हामी खसेको खण्डमा क्रस्ट फाल्ने ठाउँ हुनु हो। र यो अब विशेष गरी पूरा भएको थिएन। र त्यसपछि तपाईं यो क्रस्ट संग के गर्न जाँदै हुनुहुन्छ? यो एउटा कार्य हो जहाँ यो धेरै स्पष्ट छैन किन स्वैप आवश्यक छ, विशेष गरी यस्तो आकारको।

तर अधिक आधुनिक, अर्थात्, कर्नेलको तेस्रो संस्करणमा, व्यवहार परिवर्तन भएको छ। र यदि तपाईंले स्व्यापलाई शून्यमा सेट गर्नुभयो, अर्थात् यसलाई बन्द गर्नुभयो भने, ढिलो वा चाँडो, यदि त्यहाँ केही 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।

यसको मतलब के हो? कर्नेल २.६ बाट एउटा फ्लशिंग राक्षस देखा पर्‍यो। Pdglush, कसले प्रयोग गरिरहेको छ भन्ने कुरामा निर्भर गर्दछ, जुन कर्नेल बफरबाट फोहोर पृष्ठहरू खारेज गर्ने पृष्ठभूमिमा संलग्न छ र फोहोर पृष्ठहरू खारेज गर्न आवश्यक हुँदा खारेज गर्दैछ, जे होस्, जब ब्याकग्राउन्ड खारेजले मद्दत गर्दैन।

पृष्ठभूमि कहिले आउँछ? जब सर्भरमा उपलब्ध कुल RAM को 10% कर्नेल बफरमा फोहोर पृष्ठहरूले ओगटेको हुन्छ, पृष्ठभूमिमा विशेष लेखन-अफ प्रकार्य भनिन्छ। यसको पृष्ठभूमि किन छ? प्यारामिटरको रूपमा, यसले कति पृष्ठहरू लेख्नको लागि खातामा लिन्छ। र, मानौं, उसले N पृष्ठहरू लेख्छ। अनि केही समयको लागि यो कुरा सुत्छ। र त्यसपछि उनी फेरि आउँछिन् र केही थप पृष्ठहरू प्रतिलिपि गर्छिन्।

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

यदि यी फोहोर पृष्ठहरू सञ्चित हुन जारी राख्छन् भने, तिनीहरू 20% सम्म जम्मा हुन्छन्, जस पछि OS प्राथमिकता डिस्कमा सम्पूर्ण कुरा लेख्नु हो, किनभने शक्ति असफल हुनेछ र सबै कुरा हाम्रो लागि खराब हुनेछ। हामीले यो डेटा गुमाउनेछौं, उदाहरणका लागि।

चाल के हो? चाल यो हो कि आधुनिक संसारमा यी प्यारामिटरहरू मेसिनमा रहेको कुल RAM को 20 र 10% हो, तिनीहरू तपाइँसँग भएको कुनै पनि डिस्क प्रणालीको थ्रुपुटको सन्दर्भमा बिल्कुल राक्षसी छन्।

कल्पना गर्नुहोस् कि तपाईंसँग 128 GB RAM छ। 12,8 GB तपाईको डिस्क प्रणालीमा आउँछ। र कुनै फरक पर्दैन तपाईंसँग त्यहाँ के क्यास छ, तपाईंसँग त्यहाँ जुनसुकै एरे छ, तिनीहरू त्यति लामो समयसम्म रहँदैनन्।

तसर्थ, हामी सुझाव दिन्छौं कि तपाइँ तपाइँको RAID नियन्त्रक को क्षमताहरु को आधार मा तुरुन्तै यी नम्बरहरु समायोजन गर्नुहोस्। मैले तुरुन्तै यहाँ 512 MB क्यास भएको नियन्त्रकको लागि सिफारिस गरें।

सबै कुरा धेरै सरल मानिन्छ। तपाईले vm.dirty_background लाई बाइटमा राख्न सक्नुहुन्छ। र यी सेटिङहरूले अघिल्लो दुई रद्द गर्दछ। या त पूर्वनिर्धारित रूपमा अनुपात हो, वा बाइटहरू सक्रिय हुन्छन्, त्यसपछि बाइटहरू भएकाहरूले काम गर्नेछन्। तर म एक DBA सल्लाहकार हुँ र विभिन्न ग्राहकहरूसँग काम गरेकोले, म स्ट्राहरू कोर्न प्रयास गर्छु र त्यसैले, यदि बाइटमा, त्यसपछि बाइटहरूमा। कसैले ग्यारेन्टी दिएन कि राम्रो प्रशासकले सर्भरमा थप मेमोरी थप्दैन, यसलाई रिबुट गर्दैन, र आंकडा उस्तै रहनेछ। केवल यी संख्याहरू गणना गर्नुहोस् ताकि सबै कुरा त्यहाँ ग्यारेन्टीको साथ फिट हुन्छ।

यदि तपाईं फिट हुनुहुन्न भने के हुन्छ? मैले लेखेको छु कि कुनै पनि फ्लशिंग प्रभावकारी रूपमा रोकिएको छ, तर वास्तवमा यो भाषणको आंकडा हो। अपरेटिङ सिस्टममा ठूलो समस्या छ - यसमा धेरै फोहोर पृष्ठहरू छन्, त्यसैले तपाईंको क्लाइन्टहरूले उत्पन्न गर्ने IO प्रभावकारी रूपमा रोकिएको छ, अर्थात् अनुप्रयोग डाटाबेसमा sql क्वेरी पठाउन आएको छ, यो पर्खिरहेको छ। यसमा कुनै पनि इनपुट/आउटपुट सबैभन्दा कम प्राथमिकताको हुन्छ, किनभने डाटाबेस चेकपोइन्टले ओगटेको हुन्छ। र उनी कहिले पूरा गर्छिन् यो पूर्ण रूपमा अस्पष्ट छ। र जब तपाईंले गैर-पृष्ठभूमि फ्लशिंग हासिल गर्नुभयो, यसको मतलब यो हो कि तपाईंको सबै IO यसमा कब्जा गरिएको छ। र यो समाप्त नभएसम्म, तपाईं केहि गर्नुहुनेछैन।

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

जीवनलाई धेरै गाह्रो बनाउन अरू के गर्न सक्छ? यी दुई प्यारामिटरहरू हुन्। तिनीहरू अपेक्षाकृत नयाँ छन्। पूर्वनिर्धारित रूपमा, तिनीहरू विभिन्न अनुप्रयोगहरूमा समावेश गर्न सकिन्छ। र यदि तिनीहरू गलत तरिकाले सक्रिय भएमा तिनीहरूले जीवनलाई त्यति नै कठिन बनाउन सक्छन्।

त्यहाँ दुई अपेक्षाकृत नयाँ चीजहरू छन्। तिनीहरू पहिले नै तेस्रो कोरमा देखा परेका छन्। यो नानोसेकेन्डमा sched_migration_cost र sched_autogroup_enabled हो, जुन पूर्वनिर्धारित रूपमा एक हो।

र तिनीहरूले तपाईंको जीवन कसरी बर्बाद गर्छन्? Sched_migration_cost भनेको के हो? लिनक्समा, अनुसूचकले एउटा प्रक्रियालाई एक सीपीयूबाट अर्कोमा माइग्रेट गर्न सक्छ। र PostgreSQL को लागी, जसले प्रश्नहरू कार्यान्वयन गर्दछ, अर्को CPU मा माइग्रेट गर्ने पूर्ण रूपमा अस्पष्ट छ। अपरेटिङ सिस्टमको दृष्टिकोणबाट, जब तपाइँ ओपन अफिस र टर्मिनल बीचको सञ्झ्याल स्विच गर्नुहुन्छ, यो राम्रो हुन सक्छ, तर डाटाबेसको लागि यो धेरै खराब छ। त्यसकारण, एक उचित नीति भनेको migration_cost लाई केहि ठुलो मान, कम्तिमा धेरै हजार नानोसेकेन्डमा सेट गर्नु हो।

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

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

मेरो सहकर्मी एलेक्सी लेसोभस्कीले साधारण pgbench मार्फत परीक्षणहरू गरे, जहाँ उनले परिमाणको अर्डरद्वारा माइग्रेसन_लागत बढाए र स्वत: समूह बन्द गरे। खराब हार्डवेयरमा भिन्नता लगभग 10% थियो। त्यहाँ postgres मेलिङ सूचीमा छलफल छ जहाँ मानिसहरूले क्वेरी गतिमा समान परिवर्तनहरूको परिणाम दिन्छन् ५०% प्रभावित। यस्ता कथाहरु धेरै छन् ।

र अन्तमा, ऊर्जा बचत नीतिको बारेमा। राम्रो कुरा यो हो कि लिनक्स अब ल्यापटपमा प्रयोग गर्न सकिन्छ। र यसले ब्याट्री राम्रोसँग प्रयोग गर्नेछ। तर अचानक यो सर्भर मा पनि हुन सक्छ कि बाहिर जान्छ।

यसबाहेक, यदि तपाइँ केहि होस्टरबाट सर्भरहरू भाडामा लिनुहुन्छ भने, "राम्रो" होस्टरहरूले तपाइँसँग राम्रो प्रदर्शन छ भनेर वास्ता गर्दैनन्। तिनीहरूको कार्य भनेको तिनीहरूको फलाम सकेसम्म कुशलतापूर्वक प्रयोग भएको सुनिश्चित गर्नु हो। त्यसकारण, पूर्वनिर्धारित रूपमा तिनीहरूले अपरेटिङ सिस्टममा ल्यापटप पावर बचत मोड सक्षम गर्न सक्छन्।

यदि तपाईले यो सामानलाई सर्भरमा भारी भार अन्तर्गत डाटाबेस प्रयोग गर्नुहुन्छ भने, तपाईको रोजाई acpi_cpufreq + permormance हो। माग भए पनि समस्या हुनेछ।

Intel_pstate अलि फरक चालक हो। र अब यसलाई प्राथमिकता दिइन्छ, किनकि यो पछि छ र राम्रो काम गर्दछ।

र, तदनुसार, राज्यपाल केवल प्रदर्शन हो। ओन्डमान्ड, पावर सेभ र अरू सबै कुरा तपाईंको बारेमा होइन।

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

यी वस्तुहरू पूर्वनिर्धारित रूपमा समावेश गर्न सकिन्छ। तिनीहरूले यसलाई पूर्वनिर्धारित रूपमा खोलेका छन् कि भनेर हेर्न सावधानीपूर्वक हेर्नुहोस्। यो साँच्चै ठूलो समस्या हुन सक्छ।

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

प्रश्नहरू:

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

हामीले तपाईंको प्रश्नको जवाफ लगभग तीन तरिकामा दियौं। यदि हामी हार्डवेयर सर्भरको बारेमा कुरा गरिरहेका छैनौं जुन ट्युन गर्न सकिन्छ, इत्यादि, त्यसपछि आराम गर्नुहोस्, यी सेटिङहरू बिना सबै कुरा राम्रोसँग काम गर्नेछ। यदि तपाइँसँग यस्तो भार छ कि तपाइँ यी सेटिङहरू बनाउन आवश्यक छ भने, तपाइँ यी सेटिङहरू भन्दा पहिले फलामको सर्भरमा आउनुहुनेछ।

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

यदि तपाइँसँग एउटै सर्भरमा NGINX छ भने, तपाइँसँग पनि उही समस्या हुनेछ। उसले साझा मेमोरीको लागि लड्नेछ। र तपाइँ यहाँ वर्णन गरिएका समस्याहरूमा पुग्नुहुनेछैन।

तर अर्कोतर्फ, यी मध्ये केही प्यारामिटरहरू अझै पनि तपाईंसँग सान्दर्भिक हुनेछन्। उदाहरणका लागि, sysctl सँग dirty_ratio सेट गर्नुहोस् ताकि यो यति पागल नहोस् - कुनै पनि अवस्थामा, यसले मद्दत गर्नेछ। एक तरिका वा अर्को, तपाईं डिस्क संग अन्तरक्रिया हुनेछ। र यो गलत ढाँचा अनुसार हुनेछ। यो सामान्यतया मैले देखाएको प्यारामिटरहरूको लागि पूर्वनिर्धारित हो। र कुनै पनि अवस्थामा यो तिनीहरूलाई परिवर्तन गर्न राम्रो छ।

तर NUMA मा समस्या हुन सक्छ। VmWare, उदाहरणका लागि, ठीक उल्टो सेटिङहरूसँग NUMA सँग राम्रोसँग काम गर्दछ। र यहाँ तपाईले छनौट गर्नु पर्छ - फलामको सर्भर वा गैर-फलामको।

मसँग Amazon AWS सम्बन्धित प्रश्न छ। तिनीहरूसँग पूर्व-कन्फिगर गरिएका छविहरू छन्। ती मध्ये एक Amazon RDS भनिन्छ। के त्यहाँ तिनीहरूको अपरेटिङ सिस्टमको लागि कुनै अनुकूलन सेटिङहरू छन्?

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

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

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

स्रोत: www.habr.com