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

इस चक्र में चार भाग शामिल होंगे:

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

क्यों जरूरी है जर्नलिंग?

इस प्रक्रिया में, डेटा का वह हिस्सा जो डीबीएमएस के साथ काम करता है, रैम में संग्रहीत किया जाता है और डिस्क (या अन्य गैर-वाष्पशील मीडिया) को आस्थगित तरीके से लिखा जाता है। कम अक्सर ऐसा होता है, कम इनपुट-आउटपुट और सिस्टम तेजी से काम करता है।

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

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

बफर कैश

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

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

ध्यान दें कि ऑपरेटिंग सिस्टम में एक डिस्क कैश भी है जो समान समस्या को हल करता है। इसलिए, डीबीएमएस आमतौर पर ओएस कैश को दरकिनार करते हुए सीधे डिस्क तक पहुंचकर दोहरे कैशिंग से बचने की कोशिश करते हैं। लेकिन PostgreSQL के मामले में, ऐसा नहीं है: सभी डेटा साधारण फ़ाइल संचालन का उपयोग करके पढ़ा और लिखा जाता है।

इसके अलावा, डिस्क एरे, और यहां तक कि डिस्क भी, अपने स्वयं के कैश हैं। यह तथ्य अभी भी हमारे लिए उपयोगी है जब हम विश्वसनीयता के मुद्दे पर आते हैं।

लेकिन वापस DBMS बफर कैश के लिए।

इसे इसलिए कहा जाता है क्योंकि यह बफ़र्स की एक सरणी है। प्रत्येक बफ़र एक डेटा पेज (ब्लॉक), और एक हेडर के लिए एक जगह है। शीर्षक, अन्य बातों के अलावा, शामिल हैं:

बफर में पृष्ठ की डिस्क पर स्थान (इसमें फ़ाइल और ब्लॉक नंबर);
एक संकेत जो पृष्ठ पर डेटा बदल गया है और जल्द ही या बाद में डिस्क पर लिखा जाना चाहिए (ऐसे बफर को गंदा कहा जाता है );
बफर को कॉल की संख्या (उपयोग गणना);
बफर को पिन करने का झंडा (पिन काउंट)।

बफर कैश सर्वर की साझा मेमोरी में स्थित है और सभी प्रक्रियाओं के लिए सुलभ है। डेटा के साथ काम करने के लिए - पढ़ें या संशोधित करें, - प्रक्रियाएं कैश में पृष्ठों को पढ़ती हैं। जबकि पेज कैश में है, हम इसके साथ रैम में काम करते हैं और डिस्क एक्सेस पर सेव करते हैं।

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

कैश में पेज खोजें

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

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

यदि वांछित पेज कैश में पाया जाता है, तो प्रक्रिया को पिन काउंट बढ़ाकर बफर को "फ्रीज" करना चाहिए (कई प्रक्रियाएं एक साथ ऐसा कर सकती हैं)। जब तक बफर तय किया जाता है (काउंटर वैल्यू शून्य से अधिक है), यह माना जाता है कि बफर का उपयोग किया जाता है और इसकी सामग्री को "मौलिक" नहीं बदला जाना चाहिए। उदाहरण के लिए, पृष्ठ में लाइन का एक नया संस्करण दिखाई दे सकता है - यह बहु-संस्करण और दृश्यता नियमों के कारण किसी को परेशान नहीं करता है। लेकिन दूसरे पेज को पिन किए गए बफर में नहीं पढ़ा जा सकता है।

बाहर भीड़ हो रही है

ऐसा हो सकता है कि कैश में आवश्यक पृष्ठ नहीं मिला है। इस मामले में, इसे डिस्क से कुछ बफर में पढ़ा जाना चाहिए।

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

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

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

एक शून्य हिट काउंटर (उपयोग गणना),
और निश्चित नहीं (शून्य पिन गणना)।

आप देख सकते हैं कि यदि सभी बफ़र्स के पास नॉन-जीरो हिट काउंटर है, तो एल्गोरिथ्म को एक से अधिक सर्कल करने होंगे, काउंटरों को रीसेट करना होगा, जब तक कि उनमें से एक अंततः शून्य तक नहीं जाता। "घुमावदार मंडलियों" से बचने के लिए हिट काउंटर का अधिकतम मूल्य 5. तक सीमित है, लेकिन फिर भी, एक बड़े बफर कैश आकार के साथ, यह एल्गोरिथ्म महत्वपूर्ण ओवरहेड का कारण बन सकता है।

बफर पाए जाने के बाद, निम्नलिखित इसके साथ होता है।

अन्य प्रक्रियाओं को दिखाने के लिए बफर को पिन किया जाता है कि इसका उपयोग किया जा रहा है। फिक्सिंग के अलावा, अवरुद्ध करने के अन्य साधनों का भी उपयोग किया जाता है, लेकिन हम इस बारे में अलग से बात करेंगे।

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

अगला, डिस्क से चयनित बफर में एक नया पृष्ठ पढ़ा जाता है। कॉल की संख्या का काउंटर एक पर सेट है। इसके अलावा, लोड किए गए पृष्ठ का लिंक हैश तालिका में पंजीकृत होना चाहिए ताकि यह भविष्य में पाया जा सके।

अब "अगला शिकार" के लिए लिंक अगले बफर को इंगित करता है, और सिर्फ लोड किए गए व्यक्ति के पास हिट काउंटर को बढ़ाने का समय होता है जब तक कि सूचक पूरे बफर कैश के आसपास नहीं जाता है और फिर से वापस आ जाता है।

अपनी आँखों से

जैसा कि PostgreSQL में प्रथागत है, एक विस्तार है जो आपको बफर कैश के अंदर देखने की अनुमति देता है।

=> CREATE EXTENSION pg_buffercache;

एक तालिका बनाएं और उसमें एक पंक्ति डालें।

 => CREATE TABLE cacheme( id integer ) WITH (autovacuum_enabled = off); => INSERT INTO cacheme VALUES (1);

बफर कैश में क्या होगा? कम से कम, एक पृष्ठ को इसमें एक एकल पंक्ति के साथ जोड़ा जाना चाहिए। हम इसे निम्नलिखित प्रश्न के साथ सत्यापित करेंगे, जिसमें हम केवल अपनी तालिका से संबंधित बफ़र्स (फ़ाइल संख्या relfilenode द्वारा) का चयन करते हैं, और परत संख्या (relforknumber) को डिकोड करते हैं:

 => SELECT bufferid, CASE relforknumber WHEN 0 THEN 'main' WHEN 1 THEN 'fsm' WHEN 2 THEN 'vm' END relfork, relblocknumber, isdirty, usagecount, pinning_backends FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('cacheme'::regclass);

  bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends ----------+---------+----------------+---------+------------+------------------ 15735 | main | 0 | t | 1 | 0 (1 row)

तो यह है - बफर में एक पृष्ठ है। यह गंदा (isdirty) है, हिट काउंटर एक (यूसेजाउंट) के बराबर है, और यह किसी भी प्रक्रिया (पिनिंग_बैक) द्वारा तय नहीं है।

अब दूसरी पंक्ति जोड़ें और क्वेरी दोहराएं। अक्षरों को बचाने के लिए, हम दूसरे सत्र में एक पंक्ति सम्मिलित करते हैं, और \g कमांड के साथ लंबे अनुरोध को दोहराते हैं।

 | => INSERT INTO cacheme VALUES (2);

 => \g

  bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends ----------+---------+----------------+---------+------------+------------------ 15735 | main | 0 | t | 2 | 0 (1 row)

कोई नया बफ़र नहीं जोड़ा गया - उसी पृष्ठ पर दूसरी पंक्ति फिट है। कृपया ध्यान दें कि उपयोग काउंटर बढ़ गया है।

 | => SELECT * FROM cacheme;

 | id | ---- | 1 | 2 | (2 rows)

 => \g

  bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends ----------+---------+----------------+---------+------------+------------------ 15735 | main | 0 | t | 3 | 0 (1 row)

और पढ़ने के लिए पृष्ठ तक पहुंचने के बाद, काउंटर भी बढ़ जाता है।

और अगर आप साफ करते हैं?

 | => VACUUM cacheme;

 => \g

  bufferid | relfork | relblocknumber | isdirty | usagecount | pinning_backends ----------+---------+----------------+---------+------------+------------------ 15731 | fsm | 1 | t | 1 | 0 15732 | fsm | 0 | t | 1 | 0 15733 | fsm | 2 | t | 2 | 0 15734 | vm | 0 | t | 2 | 0 15735 | main | 0 | t | 3 | 0 (5 rows)

सफाई ने एक दृश्यता मानचित्र (एक पृष्ठ) और एक मुफ्त अंतरिक्ष मानचित्र (तीन पृष्ठ - इस मानचित्र का न्यूनतम आकार) बनाया।

अच्छी तरह से और इतने पर।

आकार सेटिंग

कैशे का आकार शेअर_बफर्स पैरामीटर द्वारा निर्धारित किया जाता है। डिफ़ॉल्ट मान 128 एमबी हास्यास्पद है। यह एक पैरामीटर है कि यह PostgreSQL को स्थापित करने के तुरंत बाद बढ़ाने के लिए समझ में आता है।

 => SELECT setting, unit FROM pg_settings WHERE name = 'shared_buffers';

  setting | unit ---------+------ 16384 | 8kB (1 row)

ध्यान रखें कि पैरामीटर को बदलने के लिए सर्वर पुनरारंभ की आवश्यकता होती है, क्योंकि सर्वर स्टार्टअप पर सभी आवश्यक कैश मेमोरी आवंटित की जाती है।

उचित मूल्य चुनने के लिए किन कारणों से?

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

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

मानक अनुशंसा को पहले सन्निकटन के रूप में 1/4 रैम लेना है (पोस्टग्रेएसक्यूएल 10 से पहले विंडोज के लिए यह एक आकार छोटा चुनने की सिफारिश की गई थी)।

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

PgConf-2019 पर निकोले समोखावलोव की रिपोर्ट पर गौर करना सुनिश्चित करें: " पोस्टग्रेज्यूकल ट्यूनिंग के लिए एक औद्योगिक दृष्टिकोण: डेटाबेस प्रयोग "

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

उदाहरण के लिए, आप उनके उपयोग की डिग्री के अनुसार बफ़र्स के वितरण का अध्ययन कर सकते हैं:

 => SELECT usagecount, count(*) FROM pg_buffercache GROUP BY usagecount ORDER BY usagecount;

  usagecount | count ------------+------- 1 | 221 2 | 869 3 | 29 4 | 12 5 | 564 | 14689 (6 rows)

इस मामले में, बहुत सारे खाली काउंटर मूल्य मुक्त बफर हैं। ऐसी व्यवस्था के लिए आश्चर्य नहीं जिसमें कुछ भी नहीं होता है।

आप देख सकते हैं कि हमारे डेटाबेस में कितनी टेबल कैश्ड हैं और इन डेटा का कितनी सक्रियता से उपयोग किया जाता है (इस क्वेरी में सक्रिय उपयोग से हमारा मतलब है बफ़र्स 3 से अधिक के उपयोग काउंटर के साथ):

 => SELECT c.relname, count(*) blocks, round( 100.0 * 8192 * count(*) / pg_table_size(c.oid) ) "% of rel", round( 100.0 * 8192 * count(*) FILTER (WHERE b.usagecount > 3) / pg_table_size(c.oid) ) "% hot" FROM pg_buffercache b JOIN pg_class c ON pg_relation_filenode(c.oid) = b.relfilenode WHERE b.reldatabase IN ( 0, (SELECT oid FROM pg_database WHERE datname = current_database()) ) AND b.usagecount is not null GROUP BY c.relname, c.oid ORDER BY 2 DESC LIMIT 10;

  relname | blocks | % of rel | % hot ---------------------------+--------+----------+------- vac | 833 | 100 | 0 pg_proc | 71 | 85 | 37 pg_depend | 57 | 98 | 19 pg_attribute | 55 | 100 | 64 vac_s | 32 | 4 | 0 pg_statistic | 27 | 71 | 63 autovac | 22 | 100 | 95 pg_depend_reference_index | 19 | 48 | 35 pg_rewrite | 17 | 23 | 8 pg_class | 16 | 100 | 100 (10 rows)

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

आप अन्य वर्गों के साथ आ सकते हैं जो विचार के लिए उपयोगी जानकारी प्रदान करेंगे। केवल इस तरह के अनुरोधों पर विचार करना आवश्यक है:

कई बार दोहराया जाना चाहिए: संख्या कुछ सीमाओं के भीतर अलग-अलग होगी;
यह इस तथ्य के कारण लगातार (निगरानी के भाग के रूप में) प्रदर्शन करने के लिए आवश्यक नहीं है कि एक्सटेंशन थोड़े समय के लिए बफर कैश के साथ संचालन को अवरुद्ध करता है।

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

बड़े पैमाने पर विस्थापन

बल्क रीडिंग या डेटा लिखने के संचालन में, "एक बार" डेटा के साथ बफर कैश से उपयोगी पृष्ठों को जल्दी से विस्थापित करने का खतरा है।

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

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

आइए इसे देखें। ऐसा करने के लिए, एक तालिका बनाएं ताकि एक पंक्ति पूरे पृष्ठ पर कब्जा कर ले - यह गिनती के लिए अधिक सुविधाजनक है। डिफ़ॉल्ट बफ़र कैश आकार 128 MB = 16384 पृष्ठों की 8 KB है। इसलिए, आपको तालिका में 4096 से अधिक पृष्ठ-पंक्तियाँ सम्मिलित करने की आवश्यकता है।

 => CREATE TABLE big( id integer PRIMARY KEY GENERATED ALWAYS AS IDENTITY, s char(1000) ) WITH (fillfactor=10); => INSERT INTO big(s) SELECT 'FOO' FROM generate_series(1,4096+1);

आइए तालिका का विश्लेषण करें।

 => ANALYZE big; => SELECT relpages FROM pg_class WHERE oid = 'big'::regclass;

  relpages ---------- 4097 (1 row)

अब हमें उस तालिका डेटा के कैश को खाली करने के लिए सर्वर को पुनरारंभ करना होगा जो विश्लेषण पढ़ा है।

 student$ sudo pg_ctlcluster 11 main restart

रिबूट के बाद, पूरी तालिका पढ़ें:

 => EXPLAIN (ANALYZE, COSTS OFF) SELECT count(*) FROM big;

  QUERY PLAN --------------------------------------------------------------------- Aggregate (actual time=14.472..14.473 rows=1 loops=1) -> Seq Scan on big (actual time=0.031..13.022 rows=4097 loops=1) Planning Time: 0.528 ms Execution Time: 14.590 ms (4 rows)

और यह सुनिश्चित करें कि बफर कैश में केवल 32 बफ़र्स को सारणीबद्ध पृष्ठ पर कब्जा है:

 => SELECT count(*) FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('big'::regclass);

  count ------- 32 (1 row)

यदि अनुक्रमिक स्कैनिंग निषिद्ध है, तो तालिका सूचकांक द्वारा पढ़ी जाएगी:

 => SET enable_seqscan = off; => EXPLAIN (ANALYZE, COSTS OFF) SELECT count(*) FROM big;

  QUERY PLAN ------------------------------------------------------------------------------------------- Aggregate (actual time=50.300..50.301 rows=1 loops=1) -> Index Only Scan using big_pkey on big (actual time=0.098..48.547 rows=4097 loops=1) Heap Fetches: 4097 Planning Time: 0.067 ms Execution Time: 50.340 ms (5 rows)

इस स्थिति में, बफर रिंग का उपयोग नहीं किया जाता है और पूरी तालिका बफर कैश में दिखाई देती है (और लगभग संपूर्ण सूचकांक भी):

 => SELECT count(*) FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('big'::regclass);

  count ------- 4097 (1 row)

इसी तरह, बफर रिंग्स का उपयोग सफाई प्रक्रिया (32 पेज भी) के लिए किया जाता है और थोक लिखने के संचालन के लिए COP IN IN और CREATE TABLE AS SELECT (आमतौर पर 2048 पेज, लेकिन कुल बफर कैश का 1/8 से अधिक नहीं)।

अस्थायी टेबल

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

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

सामान्य बफर कैश के विपरीत, स्थानीय कैश के लिए मेमोरी को आवश्यकतानुसार आवंटित किया जाता है, क्योंकि सभी सत्रों में अस्थायी तालिकाओं का उपयोग नहीं किया जाता है। एक सत्र में अस्थायी तालिकाओं के लिए मेमोरी की अधिकतम मात्रा temp_buffers पैरामीटर द्वारा सीमित है।

कैश को गर्म करना

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

 => CREATE EXTENSION pg_prewarm;

पहले, कोई एक्सटेंशन केवल बफ़र कैश (या केवल OS कैशे में) में कुछ तालिकाएँ पढ़ सकता था। लेकिन PostgreSQL 11 में, यह सर्वर को रीबूट करने के बाद वर्तमान कैश स्थिति को डिस्क में सहेजने और इसे पुनर्स्थापित करने में सक्षम था। इसका लाभ उठाने के लिए, आपको लाइब्रेरी को साझा_प्रभार_ लाइब्रेरी में जोड़ना होगा और सर्वर को पुनरारंभ करना होगा।

 => ALTER SYSTEM SET shared_preload_libraries = 'pg_prewarm';

 student$ sudo pg_ctlcluster 11 main restart

पुनरारंभ क्षेत्र, अगर pg_prewarm.autoprewarm पैरामीटर नहीं बदला है, तो स्वतः पूर्णता मास्टर पृष्ठभूमि प्रक्रिया स्वचालित रूप से शुरू हो जाएगी, जो एक बार pg_prewarm.autoprewarm_interval में कैश में पृष्ठों की सूची को डिस्क में डंप कर देगा ( अधिकतम प्रक्रिया शुरू करते समय नई प्रक्रिया को ध्यान में रखना न भूलें)।

 => SELECT name, setting, unit FROM pg_settings WHERE name LIKE 'pg_prewarm%';

  name | setting | unit ---------------------------------+---------+------ pg_prewarm.autoprewarm | on | pg_prewarm.autoprewarm_interval | 300 | s (2 rows)

 postgres$ ps -o pid,command --ppid `head -n 1 /var/lib/postgresql/11/main/postmaster.pid` | grep prewarm

 10436 postgres: 11/main: autoprewarm master

अब कैश में कोई बड़ी तालिका नहीं है:

 => SELECT count(*) FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('big'::regclass);

  count ------- 0 (1 row)

यदि हम मानते हैं कि इसकी सभी सामग्रियां बहुत महत्वपूर्ण हैं, तो हम निम्नलिखित कार्य को कॉल करके बफर कैश में पढ़ सकते हैं:

 => SELECT pg_prewarm('big');

  pg_prewarm ------------ 4097 (1 row)

 => SELECT count(*) FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('big'::regclass);

  count ------- 4097 (1 row)

पृष्ठों की सूची को autoprewarm.blocks फ़ाइल में डंप कर दिया जाता है। इसे देखने के लिए, आप तब तक इंतजार कर सकते हैं जब तक कि ऑटोप्रेवर्म मास्टर प्रक्रिया पहली बार नहीं चलती है, लेकिन हम इसे मैन्युअल रूप से आरंभ करते हैं:

 => SELECT autoprewarm_dump_now();

  autoprewarm_dump_now ---------------------- 4340 (1 row)

त्याग किए गए पृष्ठों की संख्या 4097 से अधिक है - इसमें सर्वर द्वारा पहले से पढ़े गए सिस्टम कैटलॉग ऑब्जेक्ट्स के पृष्ठ शामिल हैं। और यहाँ फाइल है:

 postgres$ ls -l /var/lib/postgresql/11/main/autoprewarm.blocks

 -rw------- 1 postgres postgres 102078  29 15:51 /var/lib/postgresql/11/main/autoprewarm.blocks

अब सर्वर को फिर से रीस्टार्ट करें।

 student$ sudo pg_ctlcluster 11 main restart

और लॉन्च के तुरंत बाद, हमारी तालिका फिर से कैश में दिखाई देती है।

 => SELECT count(*) FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('big'::regclass);

  count ------- 4097 (1 row)

यह एक ही ऑटोप्रेवर्म मास्टर प्रक्रिया प्रदान करता है: यह फ़ाइल को पढ़ता है, पृष्ठों को डेटाबेस में विभाजित करता है, उन्हें सॉर्ट करता है (ताकि डिस्क से पढ़ना जितना संभव हो उतना संगत हो), और प्रसंस्करण के लिए अलग वर्कफ़्लो में ऑटोप्रेवर्म कार्यकर्ता को पास करता है।

जारी रखा जाए ।

PostgreSQL में चलें: 1. बफर कैश