आपको याद दिला दूं कि हमने पहले से ही रिलेशनशिप लॉक, रो-लेवल लॉक , अन्य ऑब्जेक्ट्स के लॉक के बारे में (डेडिकेटेड सहित) और विभिन्न प्रकार के लॉक के बीच संबंध के बारे में बात की थी।

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

स्पिन लॉक

सामान्य के विपरीत, "भारी" ताले, लाइटर और सस्ते (ओवरहेड के संदर्भ में) ताले का उपयोग साझा रैम में संरचनाओं की रक्षा के लिए किया जाता है।

उनमें से सबसे सरल स्पिन-लॉक या स्पिनलॉक हैं । उन्हें बहुत कम समय (कई प्रोसेसर निर्देशों) पर कब्जा करने और एक साथ बदलाव से स्मृति के व्यक्तिगत वर्गों की रक्षा करने के लिए डिज़ाइन किया गया है।

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

स्पिन लॉक गतिरोधों का पता लगाने की सुविधा नहीं देते हैं (पोस्टग्रेक्यूएल डेवलपर्स इसकी निगरानी कर रहे हैं) और कोई निगरानी उपकरण प्रदान नहीं करते हैं। स्पिन लॉक के साथ केवल एक चीज जो हम कर सकते हैं, वह है उनके अस्तित्व के बारे में जानना।

प्रकाश ताले

अगला तथाकथित प्रकाश ताले (हल्के ताले, lwlocks) आते हैं।

उन्हें डेटा संरचना के साथ काम करने के लिए कम समय के लिए कब्जा कर लिया जाता है (उदाहरण के लिए, एक हैश टेबल या पॉइंटर्स की सूची)। एक नियम के रूप में, एक लाइट लॉक को लंबे समय तक नहीं रखा जाता है, लेकिन कुछ मामलों में, एक लाइट लॉक आई / ओ संचालन की सुरक्षा करता है, इसलिए सिद्धांत रूप में, समय महत्वपूर्ण हो सकता है।

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

गतिरोधों की जांच करने के लिए एक तंत्र प्रदान नहीं किया गया है, यह कर्नेल डेवलपर्स के विवेक पर रहता है। हालांकि, प्रकाश ताले में निगरानी उपकरण होते हैं, इसलिए, स्पिन ताले के विपरीत, उन्हें "देखा जा सकता है" (थोड़ी देर बाद मैं दिखाऊंगा कि कैसे)।

क्लिप बफर

एक अन्य प्रकार का ताला जिसे हमने पहले ही आलेख में चर्चा की है बफर कैश के बारे में बफर पिनिंग है ।

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

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

निगरानी के लिए समेकन की उम्मीदें उपलब्ध हैं।

उदाहरण: बफर कैश

अब, कुछ (अधूरा!) प्राप्त करने के लिए कि कैसे और कहाँ ताले का उपयोग किया जाता है, एक बफर कैश के उदाहरण पर विचार करें।

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

स्पिन-लॉक का उपयोग करके प्रक्रिया बफर के हेडर तक पहुंच जाती है। व्यक्तिगत संचालन (जैसे काउंटर को बढ़ाना) भी प्रोसेसर से परमाणु निर्देशों का उपयोग करके स्पष्ट ताले के बिना किया जा सकता है।

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

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

बफ़र्स को और अगले शिकार को पॉइंटर्स को सिंगल बफर स्ट्रैटेजी लॉक स्पिन लॉक द्वारा संरक्षित किया जाता है।

उदाहरण: लॉग बफ़र्स

एक और उदाहरण: लॉग बफ़र्स।

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

डिस्क पर पृष्ठों को लिखना हल्के वॉकलाइट लॉक द्वारा सुरक्षित है ताकि एक बार में केवल एक ही प्रक्रिया इस ऑपरेशन को कर सके।

जर्नल प्रविष्टि बनाने के लिए, प्रक्रिया को पहले वाल पेज पर एक स्थान आरक्षित करना होगा। ऐसा करने के लिए, यह स्पिन लॉक डालने की स्थिति लॉक को कैप्चर करता है। एक जगह आरक्षित होने के बाद, प्रक्रिया अपने रिकॉर्ड की सामग्री को निर्दिष्ट स्थान पर कॉपी करती है। नकल एक ही समय में कई प्रक्रियाओं द्वारा की जा सकती है, जिसके लिए रिकॉर्ड को 8 आसान लॉक डालने वाले ताले की एक ट्रेच द्वारा संरक्षित किया जाता है (प्रक्रिया को उनमें से किसी पर कब्जा करना होगा)।

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

उम्मीद की निगरानी

PostgreSQL 9.6 के साथ शुरू, प्रतीक्षा निगरानी उपकरण pg_stat_activity दृश्य में बनाए गए हैं। जब कोई प्रक्रिया (सिस्टम या रखरखाव) अपना काम नहीं कर सकती है और किसी चीज़ की प्रतीक्षा कर रही है, तो यह अपेक्षा दृश्य में देखी जा सकती है: Wait_event_type कॉलम अपेक्षा के प्रकार को इंगित करता है, और प्रतीक्षा_इवेंट कॉलम किसी विशिष्ट अपेक्षा के नाम को इंगित करता है।

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

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

नमूना लेने की संभावित प्रकृति को ध्यान में रखना आवश्यक है। अधिक या कम विश्वसनीय चित्र प्राप्त करने के लिए, माप की संख्या काफी बड़ी होनी चाहिए। कम आवृत्ति पर नमूना लेना एक विश्वसनीय तस्वीर नहीं दे सकता है, और आवृत्ति बढ़ने से ओवरहेड में वृद्धि होगी। इसी कारण से, अल्पकालिक सत्रों के विश्लेषण के लिए नमूना बेकार है।

सभी अपेक्षाओं को कई प्रकारों में विभाजित किया जा सकता है।

माना ताले की उम्मीदें एक बड़ी श्रेणी बनाते हैं:

• ऑब्जेक्ट लॉक की प्रतीक्षा कर रहा है (Wait_event_type कॉलम में लॉक मान);
• प्रकाश ताले (LWLock) की प्रतीक्षा कर रहा है;
• एक पिन किए गए बफर (बफ़रपिन) की प्रतीक्षा कर रहा है।

लेकिन प्रक्रिया अन्य घटनाओं की उम्मीद कर सकती है:

• I / O अपेक्षाएँ (IO) तब होती हैं जब किसी डेटा को लिखने या पढ़ने के लिए प्रक्रिया की आवश्यकता होती है;
• प्रक्रिया क्लाइंट (क्लाइंट) या किसी अन्य प्रक्रिया (IPC) से काम करने के लिए आवश्यक डेटा की प्रतीक्षा कर सकती है;
• एक्सटेंशन उनकी विशिष्ट उम्मीदों (एक्सटेंशन) को पंजीकृत कर सकते हैं।

ऐसी परिस्थितियां होती हैं जब एक प्रक्रिया बस उपयोगी काम नहीं करती है। इस श्रेणी में शामिल हैं:

• अपने मुख्य लूप (गतिविधि) में पृष्ठभूमि प्रक्रियाओं की प्रतीक्षा कर रहा है;
• एक टाइमर (टाइमआउट) की प्रतीक्षा कर रहा है।

एक नियम के रूप में, ऐसी उम्मीदें "सामान्य" हैं और किसी भी समस्या की बात नहीं करती है।

अपेक्षा का प्रकार विशेष अपेक्षा के नाम के बाद है। पूर्ण तालिका प्रलेखन में पाई जा सकती है।

यदि कोई प्रतीक्षा नाम निर्दिष्ट नहीं है, तो प्रक्रिया प्रतीक्षा की स्थिति में नहीं है। ऐसे समय को बेहिसाब माना जाना चाहिए, क्योंकि वास्तव में यह ज्ञात नहीं है कि इस समय वास्तव में क्या हो रहा है।

हालाँकि, यह देखने का समय है।

=> SELECT pid, backend_type, wait_event_type, wait_event FROM pg_stat_activity; 

  pid | backend_type | wait_event_type | wait_event -------+------------------------------+-----------------+--------------------- 28739 | logical replication launcher | Activity | LogicalLauncherMain 28736 | autovacuum launcher | Activity | AutoVacuumMain 28963 | client backend | | 28734 | background writer | Activity | BgWriterMain 28733 | checkpointer | Activity | CheckpointerMain 28735 | walwriter | Activity | WalWriterMain (6 rows) 

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

नमूना

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

 => ALTER SYSTEM SET shared_preload_libraries = 'pg_wait_sampling'; 

 student$ sudo pg_ctlcluster 11 main restart 

अब डेटाबेस में एक्सटेंशन इंस्टॉल करें।

 => CREATE EXTENSION pg_wait_sampling; 

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

यहाँ हम कुछ ही सेकंड में देखेंगे:

 => SELECT * FROM pg_wait_sampling_profile; 

  pid | event_type | event | queryid | count -------+------------+---------------------+---------+------- 29074 | Activity | LogicalLauncherMain | 0 | 220 29070 | Activity | WalWriterMain | 0 | 220 29071 | Activity | AutoVacuumMain | 0 | 219 29069 | Activity | BgWriterMain | 0 | 220 29111 | Client | ClientRead | 0 | 3 29068 | Activity | CheckpointerMain | 0 | 220 (6 rows) 

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

डिफ़ॉल्ट सेटिंग्स ( pg_wait_sampling.profile_period पैरामीटर) के साथ, नमूना अवधि 10 मिलीसेकंड है, अर्थात, मान प्रति सेकंड 100 बार सहेजे जाते हैं। इसलिए, सेकंड में प्रतीक्षा की अवधि का अनुमान लगाने के लिए, गिनती के मूल्य को 100 से विभाजित किया जाना चाहिए।

यह समझने के लिए कि किस प्रक्रिया की अपेक्षाएँ हैं, हम अनुरोध में pg_stat_activity दृश्य जोड़ते हैं:

 => SELECT p.pid, a.backend_type, a.application_name AS app, p.event_type, p.event, p.count FROM pg_wait_sampling_profile p LEFT JOIN pg_stat_activity a ON p.pid = a.pid ORDER BY p.pid, p.count DESC; 

  pid | backend_type | app | event_type | event | count -------+------------------------------+------+------------+----------------------+------- 29068 | checkpointer | | Activity | CheckpointerMain | 222 29069 | background writer | | Activity | BgWriterMain | 222 29070 | walwriter | | Activity | WalWriterMain | 222 29071 | autovacuum launcher | | Activity | AutoVacuumMain | 221 29074 | logical replication launcher | | Activity | LogicalLauncherMain | 222 29111 | client backend | psql | Client | ClientRead | 4 29111 | client backend | psql | IPC | MessageQueueInternal | 1 (7 rows) 

आइए pgbench के साथ लोड करें और देखें कि चित्र कैसे बदलता है।

 student$ pgbench -i test 

हम एकत्रित प्रोफ़ाइल को शून्य पर रीसेट करते हैं और एक अलग प्रक्रिया में 30 सेकंड के लिए परीक्षण चलाते हैं।

 => SELECT pg_wait_sampling_reset_profile(); 

 student$ pgbench -T 30 test 

Pgbench प्रक्रिया पूरी होने से पहले अनुरोध पूरा होना चाहिए:

 => SELECT p.pid, a.backend_type, a.application_name AS app, p.event_type, p.event, p.count FROM pg_wait_sampling_profile p LEFT JOIN pg_stat_activity a ON p.pid = a.pid WHERE a.application_name = 'pgbench' ORDER BY p.pid, p.count DESC; 

  pid | backend_type | app | event_type | event | count -------+----------------+---------+------------+------------+------- 29148 | client backend | pgbench | IO | WALWrite | 8 29148 | client backend | pgbench | Client | ClientRead | 1 (2 rows) 

बेशक, pgbench प्रक्रिया की अपेक्षाएँ विशिष्ट प्रणाली के आधार पर थोड़ी भिन्न होंगी। हमारे मामले में, यह बहुत संभावना है कि एक लॉग प्रविष्टि (IO / WalWrite) की प्रतीक्षा की जाएगी, लेकिन अधिकांश समय यह प्रक्रिया बंद नहीं हुई, लेकिन संभवतः कुछ उपयोगी था।

प्रकाश ताले

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

इसलिए, प्रोफाइल में प्रकाश ताले दिखाई नहीं दिए - लेकिन वे दिखाई देंगे यदि आप लंबे समय तक डेटा एकत्र करते हैं। उन पर एक नज़र की गारंटी देने के लिए, आप कृत्रिम रूप से फ़ाइल सिस्टम को धीमा कर सकते हैं, उदाहरण के लिए, FUSE फ़ाइल सिस्टम पर निर्मित धीमे प्रोजेक्ट का उपयोग करें।

यदि हम किसी भी I / O ऑपरेशन को सेकंड का 1/10 हिस्सा लेते हैं, तो हम इसे एक ही टेस्ट में देख सकते हैं।

 => SELECT pg_wait_sampling_reset_profile(); 

 student$ pgbench -T 30 test 

 => SELECT p.pid, a.backend_type, a.application_name AS app, p.event_type, p.event, p.count FROM pg_wait_sampling_profile p LEFT JOIN pg_stat_activity a ON p.pid = a.pid WHERE a.application_name = 'pgbench' ORDER BY p.pid, p.count DESC; 

  pid | backend_type | app | event_type | event | count -------+----------------+---------+------------+----------------+------- 29240 | client backend | pgbench | IO | WALWrite | 1445 29240 | client backend | pgbench | LWLock | WALWriteLock | 803 29240 | client backend | pgbench | IO | DataFileExtend | 20 (3 rows) 

अब, pgbench प्रक्रिया की मुख्य अपेक्षा I / O से संबंधित है, या बल्कि, एक लॉग प्रविष्टि है जो प्रत्येक प्रतिबद्ध के साथ सिंक्रोनस मोड में निष्पादित की जाती है। चूंकि (जैसा कि ऊपर उदाहरण में दिखाया गया है), लॉग को डिस्क लिखना वालवर्टॉक लाइट लॉक द्वारा सुरक्षित है, यह लॉक भी प्रोफाइल में मौजूद है - हम इसे देखना चाहते थे।

क्लिप बफर

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

हम लेनदेन शुरू करते हैं, कर्सर खोलते हैं और एक पंक्ति का चयन करते हैं।

 => BEGIN; => DECLARE c CURSOR FOR SELECT * FROM pgbench_history; => FETCH c; 

  tid | bid | aid | delta | mtime | filler -----+-----+-------+-------+----------------------------+-------- 9 | 1 | 35092 | 477 | 2019-09-04 16:16:18.596564 | (1 row) 

जांचें कि बफर पिन किया गया है (pinning_backends):

 => SELECT * FROM pg_buffercache WHERE relfilenode = pg_relation_filenode('pgbench_history') AND relforknumber = 0 \gx 

 -[ RECORD 1 ]----+------ bufferid | 190 relfilenode | 47050 reltablespace | 1663 reldatabase | 16386 relforknumber | 0 relblocknumber | 0 isdirty | t usagecount | 1 pinning_backends | 1 <--   1  

अब हम तालिका को साफ करेंगे:

 | => SELECT pg_backend_pid(); 

 | pg_backend_pid | ---------------- | 29367 | (1 row) 

 | => VACUUM VERBOSE pgbench_history; 

 | INFO: vacuuming "public.pgbench_history" | INFO: "pgbench_history": found 0 removable, 0 nonremovable row versions in 1 out of 1 pages | DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 732651 | There were 0 unused item pointers. 

 | Skipped 1 page due to buffer pins, 0 frozen pages. 

 | 0 pages are entirely empty. | CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. | VACUUM 

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

और अब हम ठंड से सफाई करेंगे:

 | => VACUUM FREEZE VERBOSE pgbench_history; 

स्पष्ट रूप से अनुरोधित फ्रीज के साथ, आप एक भी पेज को फ्रीज मैप में चिह्नित नहीं कर सकते हैं - अन्यथा pg_class.relfrozenxid में unfrozen लेन-देन की अधिकतम आयु को कम करना असंभव है। इसलिए, कर्सर के बंद होने तक क्लीनअप लटका रहता है।

 => SELECT age(relfrozenxid) FROM pg_class WHERE oid = 'pgbench_history'::regclass; 

  age ----- 27 (1 row) 

 => COMMIT; --    

 | INFO: aggressively vacuuming "public.pgbench_history" | INFO: "pgbench_history": found 0 removable, 26 nonremovable row versions in 1 out of 1 pages | DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 732651 | There were 0 unused item pointers. 

 | Skipped 0 pages due to buffer pins, 0 frozen pages. 

 | 0 pages are entirely empty. | CPU: user: 0.00 s, system: 0.00 s, elapsed: 3.01 s. | VACUUM 

 => SELECT age(relfrozenxid) FROM pg_class WHERE oid = 'pgbench_history'::regclass; 

  age ----- 0 (1 row) 

ठीक है, चलो दूसरे psql सत्र जिसमें VACUUM आदेशों को निष्पादित किया गया था, की अपेक्षाओं को देखते हैं:

 => SELECT p.pid, a.backend_type, a.application_name AS app, p.event_type, p.event, p.count FROM pg_wait_sampling_profile p LEFT JOIN pg_stat_activity a ON p.pid = a.pid WHERE p.pid = 29367 ORDER BY p.pid, p.count DESC; 

  pid | backend_type | app | event_type | event | count -------+----------------+------+------------+------------+------- 29367 | client backend | psql | BufferPin | BufferPin | 294 29367 | client backend | psql | Client | ClientRead | 10 (2 rows) 

प्रतीक्षा प्रकार बफ़रपिन इंगित करता है कि फ्लश बफर के मुक्त होने की प्रतीक्षा कर रहा था।

इस पर हम मानेंगे कि हमने ताले पूरे कर लिए हैं। आपका ध्यान और टिप्पणियों के लिए धन्यवाद!