PostgreSQL संगति: गोलाकार नहीं, घोड़ा नहीं, निर्वात में नहीं

एक DBMS स्केलिंग एक लगातार आगे बढ़ने वाला भविष्य है। DBMSs बेहतर और हार्डवेयर प्लेटफ़ॉर्म पर स्केल करते हैं, जबकि हार्डवेयर प्लेटफ़ॉर्म स्वयं उत्पादकता, कोर की संख्या और मेमोरी बढ़ाते हैं - Achilles कछुए के साथ पकड़ रहा है, लेकिन फिर भी नहीं। डीबीएमएस स्केलिंग की समस्या जोरों पर है।

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

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

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

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

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

इसलिए, लेख के रूप में अगर दोहरे उपयोग किया जाएगा:

• अनुभव साझा करें: क्या करें अगर मल्टी-नोड सिस्टम में डेटाबेस बयाना में धीमा हो जाता है। कहां से शुरू करें, कैसे निदान करें, कहां स्थानांतरित करें।
• बताएं कि पोस्टग्रेसीक्यूबी डीबीएमएस की समस्याओं को कैसे उच्च स्तर की संगामिति के साथ हल किया जा सकता है। जिनमें ताले को लेने के लिए एल्गोरिदम में बदलाव पोस्टग्रेक्यूएल के प्रदर्शन को प्रभावित करता है।

सर्वर और डीबी

प्रणाली में प्रत्येक में 2 सॉकेट के साथ 8 ब्लेड शामिल थे। कुल में, 300 से अधिक कोर (उच्च रक्तचाप को छोड़कर)। एक तेज टायर (मालिकाना निर्माता तकनीक) ब्लेड को जोड़ता है। ऐसा नहीं है कि यह एक सुपर कंप्यूटर है, लेकिन DBMS के एक उदाहरण के लिए, कॉन्फ़िगरेशन प्रभावशाली है।
लोड भी बड़ा है। 1 से अधिक टेराबाइट डेटा। प्रति सेकंड लगभग 3000 लेनदेन। 1000 से अधिक कनेक्शन पोस्टग्रेज करने के लिए।

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

निदान के साथ शुरू करना: दृश्य

चूंकि समान वस्तुओं पर "दस्तक" करने वाली प्रक्रियाओं की उच्च प्रतिस्पर्धा के कारण समस्याएं सबसे अधिक होने की संभावना थी, इसलिए पहली बात यह है कि ताले की जाँच करें। PostgreSQL में, इस तरह के चेक के लिए एक दृश्य pg.catalog.pg_locks और pg_stat_activity । दूसरा संस्करण, पहले से ही संस्करण 9.6 में, इस जानकारी को जोड़ा गया कि प्रक्रिया का क्या इंतजार है ( अमित कपिला, इल्डस कुर्बानालिवी ) - wait_event_type । इस क्षेत्र के लिए संभावित मूल्य यहां वर्णित हैं ।

लेकिन पहले, बस गिनती:

 postgres=# SELECT COUNT(*) FROM pg_locks; count —---— 88453 (1 row) postgres=# SELECT COUNT(*) FROM pg_stat_activity; count —---— 1826 (1 row) postgres=# SELECT COUNT(*) FROM pg_stat_activity WHERE state ='active'; count —---— 1005 

ये वास्तविक संख्याएँ हैं। 200,000 तालों तक पहुंचे।
उसी समय, इस तरह के ताले को अशुभ अनुरोध पर लटका दिया गया था:

 SELECT COUNT(mode), mode FROM pg_locks WHERE pid =580707 GROUP BY mode; count | mode —-----+---------------— 93 | AccessShareLock 1 | ExclusiveLock 

बफर पढ़ते समय, डीबीएमएस share लॉक का उपयोग करता है, जबकि लेखन - exclusive । अर्थात्, सभी अनुरोधों के 1% से कम के लिए लॉक लॉक लिखें।
pg_locks दृश्य में, लॉक प्रकार हमेशा उपयोगकर्ता दस्तावेज़ में वर्णित के रूप में नहीं दिखते हैं।

यहाँ मैच प्लेट है:

 AccessShareLock = LockTupleKeyShare RowShareLock = LockTupleShare ExclusiveLock = LockTupleNoKeyExclusive AccessExclusiveLock = LockTupleExclusive 

Pg_locks क्वेरी से सेलेक्ट मोड से पता चलता है कि क्रिएट इंडेक्स (CONCURRENTLY के बिना) buffer content lock लिए 234 INSERTs और 390 INSERT का इंतजार करेगा। एक संभावित समाधान अलग-अलग सत्रों में INSERTs को "पढ़ाना" है ताकि बफ़र्स में कम अंतर किया जा सके।

यह perf का उपयोग करने का समय है

सही उपयोगिता बहुत सारी नैदानिक ​​जानकारी एकत्र करती है। record मोड में ... यह सिस्टम ईवेंट के आंकड़ों को फाइलों में लिखता है (डिफ़ॉल्ट रूप से वे ./perf_data ), और report मोड में यह एकत्र किए गए डेटा का विश्लेषण करता है, उदाहरण के लिए, आप उन घटनाओं को फ़िल्टर कर सकते हैं जो चिंता केवल postgres या दिए गए pid :

 $ perf record -u postgres  $ perf record -p 76876  ,  $ perf report > ./my_results 

नतीजतन, हम कुछ ऐसा देखेंगे



निदान का उपयोग कैसे करें PostgreSQL का वर्णन किया गया है, उदाहरण के लिए, यहाँ , साथ ही साथ pg विकी में भी ।

हमारे मामले में, यहां तक ​​कि सबसे सरल मोड ने संपूर्ण महत्वपूर्ण जानकारी दी - पूर्ण perf top , जो top ऑपरेटिंग सिस्टम की भावना में स्वाभाविक रूप से काम करता है। perf top साथ perf top हमने देखा कि ज्यादातर समय प्रोसेसर मुख्य PinBuffer() , साथ ही PinBuffer() और LWLockAttemptLock(). फ़ंक्शन में खर्च करता है LWLockAttemptLock(). ।

PinBuffer() एक फ़ंक्शन है जो बफर के संदर्भ के काउंटर को बढ़ाता है (रैम के लिए एक डेटा पेज को मैप करता है), धन्यवाद जिसके कारण प्रक्रियाओं को पता चलता है कि कौन से बफ़र्स को मजबूर किया जा सकता है और जो नहीं कर सकते।

LWLockAttemptLock() - LWLock का कैप्चर फ़ंक्शन। LWLock shared और exclusive दो स्तरों के साथ एक प्रकार का ताला है, LWLock को परिभाषित किए बिना, ताले को shared memory पूर्व-आवंटित किया जाता है, प्रतीक्षा प्रक्रिया एक कतार में प्रतीक्षा कर रही है।

ये फ़ंक्शन पहले से ही गंभीरता से PostgreSQL 9.5 और 9.6 में अनुकूलित किए गए हैं। उनके अंदर के स्पिनलॉक को परमाणु संचालन के प्रत्यक्ष उपयोग द्वारा प्रतिस्थापित किया गया था।

ज्वाला रेखांकन

यह उनके बिना असंभव है: भले ही वे बेकार थे, फिर भी यह उनके बारे में बताने लायक होगा - वे असामान्य रूप से सुंदर हैं। लेकिन वे उपयोगी हैं। यहाँ github से एक उदाहरण है, हमारे मामले से नहीं (न तो हम और न ही ग्राहक अभी तक विवरण के प्रकटीकरण के लिए तैयार हैं)।



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

हमारे मामले में, लौ ग्राफ़ पर nestloop की एक बड़ी मात्रा दिखाई दे nestloop थी। जाहिरा तौर पर, कई समवर्ती पढ़ने के अनुरोधों में बड़ी संख्या में तालिकाओं के जोइन ने बड़ी संख्या में access share ताले का कारण बना।

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

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

 SELECT wait_event_type, wait_event, COUNT(*) FROM pg_stat_activity GROUP BY wait_event_type, wait_event; 

पता चला है कि:

 LWLockTranche | buffer_content | UPDATE ************* LWLockTranche | buffer_content | INSERT INTO ******** LWLockTranche | buffer_content | \r | | insert into B4_MUTEX | | values (nextval('hib | | returning ID Lock | relation | INSERT INTO B4_***** LWLockTranche | buffer_content | UPDATE ************* Lock | relation | INSERT INTO ******** LWLockTranche | buffer_mapping | INSERT INTO ******** LWLockTranche | buffer_content | \r 

(यहां तारांकन केवल अनुरोध विवरणों को प्रतिस्थापित करते हैं जिन्हें हम प्रकट नहीं करते हैं)।

आप देख सकते हैं मान buffer_content (बफ़र्स की सामग्री को अवरुद्ध करना) और buffer_mapping (हैश प्लेट के घटकों को साझा करना shared_buffers )।

जीडीबी में मदद के लिए

लेकिन इस प्रकार के तालों के लिए इतनी उम्मीदें क्यों हैं? उम्मीदों के बारे में अधिक विस्तृत जानकारी के लिए, मुझे GDB डिबगर का उपयोग करना पड़ा। GDB साथ हम विशिष्ट प्रक्रियाओं का कॉल स्टैक प्राप्त कर सकते हैं। नमूना लगाने से, अर्थात्। एक निश्चित संख्या में रैंडम कॉल स्टैक्स इकट्ठा करने के बाद, आप अंदाजा लगा सकते हैं कि स्टैक की सबसे लंबी अपेक्षाएँ हैं।

आंकड़ों के संकलन की प्रक्रिया पर विचार करें। हम आंकड़ों के "मैनुअल" संग्रह पर विचार करेंगे, हालांकि वास्तविक जीवन में विशेष स्क्रिप्ट का उपयोग किया जाता है जो स्वचालित रूप से ऐसा करते हैं।

सबसे पहले, gdb को PostgreSQL प्रक्रिया से जुड़ा होना चाहिए। ऐसा करने के लिए, सर्वर प्रक्रिया pid ढूंढें, से कहें

 $ ps aux | grep postgres 

मान लीजिए कि हमने पाया:

 postgres 2025 0.0 0.1 172428 1240 pts/17  S   23  0:00 /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data 

और अब डिबगर में pid डालें:

 igor_le:~$gdb -p 2025 

डीबगर के अंदर एक बार, हम bt [कि, backtrace ] या where लिखते हैं। और हमें इस प्रकार के बारे में बहुत सी जानकारी मिलती है:

 (gdb) bt #0 0x00007fbb65d01cd0 in __write_nocancel () from /lib64/libc.so.6 #1 0x00000000007c92f4 in write_pipe_chunks ( data=0x110e6e8 "2018‐06‐01 15:35:38 MSK [524647]: [392‐1] db=bp,user=bp,app=[unknown],client=192.168.70.163 (http://192.168.70.163) LOG: relation 23554 new block 493: 248.389503\n2018‐06‐01 15:35:38 MSK [524647]: [393‐1] db=bp,user=bp,app=["..., len=409, dest=dest@entry=1) at elog.c:3123 #2 0x00000000007cc07b in send_message_to_server_log (edata=0xc6ee60 <errordata>) at elog.c:3024 #3 EmitErrorReport () at elog.c:1479 

सभी पोस्टग्रेज प्रक्रियाओं से कॉल स्टैक्स सहित एकत्रित आंकड़े होने के बाद, समय में अलग-अलग बिंदुओं पर बार-बार एकत्र किए गए, हमने देखा कि relation extension lock अंदर buffer partition lock 3706 सेकंड (लगभग एक घंटे) तक रहता है, अर्थात बफर के हैश टेबल के एक टुकड़े पर ताले। प्रबंधक, जो पुराने बफर को दबाने के लिए आवश्यक था, ताकि बाद में इसे तालिका के विस्तारित हिस्से के अनुरूप एक नए के साथ बदल दिया जा सके। buffer content lock लॉक buffer content lock एक निश्चित संख्या भी ध्यान देने योग्य थी, जो प्रविष्टि के लिए B-tree इंडेक्स के पृष्ठों को लॉक करने की अपेक्षा के अनुरूप थी।



सबसे पहले, इस तरह के एक राक्षसी प्रतीक्षा समय के लिए दो स्पष्टीकरण आए:

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

नैदानिक ​​पैच और पेड़ उपचार

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

सबसे पहले, आपदा की अधिक विस्तृत तस्वीर प्राप्त करना आवश्यक था। कोई फर्क नहीं पड़ता कि तैयार उपकरण कितने अच्छे हैं, उनके स्वयं के निर्माण के नैदानिक ​​पैच भी उपयोगी होंगे।

एक पैच लिखा गया था, जो relation extension में बिताए गए समय के एक विस्तृत लॉगिंग को जोड़ता है, जो RelationAddExtraBlocks() फ़ंक्शन के अंदर हो रहा है। इसलिए हम यह पता लगाते हैं कि RelationAddExtraBlocks(). अंदर क्या समय बिताया जाता है RelationAddExtraBlocks().

और उसके समर्थन में, एक और पैच pg_stat_activity में रिपोर्टिंग के बारे में लिखा गया था कि हम अब relation extension में क्या कर रहे हैं। यह इस तरह से किया गया था: जब relation विस्तार होता है, तो application_name RelationAddExtraBlocks बन जाता है। इस प्रक्रिया को अब gdb bt और perf उपयोग से अधिकतम विवरण के साथ आसानी से विश्लेषण किया जाता है।

वास्तव में चिकित्सा (और नैदानिक ​​नहीं) पैच दो लिखे गए थे। पहले पैच ने B‐tree लीफ लॉक के व्यवहार को बदल दिया: पहले, जब डालने का अनुरोध किया गया था, तो पत्ती को share रूप में अवरुद्ध किया गया था, और उसके बाद यह exclusive हो गया। अब वह तुरंत exclusive हो जाता है। अब यह पैच पहले ही PostgreSQL 12 के लिए शुरू कर दिया गया है । सौभाग्य से, इस वर्ष अलेक्जेंडर कोरोटकोव को एक कमिटर का दर्जा मिला - रूस में दूसरा पोस्टग्रेक्सेल कमिटर और कंपनी में दूसरा।

मैपिंग लॉक्स पर लोड को कम करने के लिए NUM_BUFFER_PARTITIONS मान भी 128 से बढ़ाकर 512 किया गया था: बफर मैनेजर हैश टेबल को छोटे टुकड़ों में विभाजित किया गया था, इस उम्मीद में कि प्रत्येक विशिष्ट टुकड़े पर लोड कम हो जाएगा।

इस पैच को लागू करने के बाद, बफ़र्स की सामग्री पर ताले चले गए थे, लेकिन NUM_BUFFER_PARTITIONS में वृद्धि के बावजूद, buffer_mapping बनी हुई थी, यानी हम आपको बफर प्रबंधक के टेबल के टुकड़ों को अवरुद्ध करने की याद दिलाते हैं

 locks_count | active_session | buffer_content | buffer_mapping ----‐‐‐--‐‐‐+‐------‐‐‐‐‐‐‐‐‐+‐‐‐------‐‐‐‐‐‐‐+‐‐------‐‐‐ 12549 | 1218 | 0 | 15 

और वह भी ज्यादा नहीं। बी - पेड़ अब एक अड़चन नहीं है। heap- विस्तार सामने आया।

अंतरात्मा का उपचार

अगला, सिकंदर ने निम्नलिखित परिकल्पना और समाधान को आगे रखा:

buffer parittion lock समय buffer parittion lock पर हम बहुत समय इंतजार करते हैं। शायद एक ही buffer parittion lock पर कुछ बहुत मांग वाला पृष्ठ है, उदाहरण के लिए, कुछ B‐tree की जड़। इस बिंदु पर रीडिंग अनुरोधों से shared lock लिए अनुरोधों का एक निरंतर प्रवाह है।

LWLock पर प्रतीक्षा रेखा "उचित नहीं है।" चूंकि shared lock को एक ही बार में आवश्यकतानुसार लिया जा सकता है, फिर यदि shared lock पहले ही ले लिया जाता है, तो बाद में shared lock बिना कतार के पास हो जाते हैं। इस प्रकार, यदि साझा किए गए तालों की धारा पर्याप्त तीव्रता की है, ताकि उनके बीच कोई "खिड़कियां" न हों, तो एक exclusive lock इंतजार लगभग अनंत तक जाता है।

इसे ठीक करने के लिए, आप पेशकश करने की कोशिश कर सकते हैं - ताले के "कोमलता से" व्यवहार का एक पैच। यह shared locker के विवेक को जागृत करता है और वे ईमानदारी से कतार में hwlock , जब पहले से ही एक exclusive lock (दिलचस्प रूप से, भारी ताले - hwlock - विवेक के साथ कोई समस्या नहीं है: वे हमेशा ईमानदारी से कतार में रहते हैं)

 locks_count | active_session | buffer_content | buffer_mapping | reladdextra | inserts>30sec ‐‐‐‐‐‐-‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐--‐-‐+‐‐‐‐‐‐-‐‐‐‐‐‐+‐‐‐‐------ 173985 | 1802 | 0 | 569 | 0 | 0 

सब ठीक है! लंबे insert नहीं insert । यद्यपि हैश प्लेटों के टुकड़ों पर ताले बने रहे। लेकिन क्या करें, ये हमारे छोटे सुपर कंप्यूटर के टायरों के गुण हैं।

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

नैतिकता

उच्च-नैतिक हल्के share - ताले - share कतार को लंघन करने वाले ब्लॉक ने बहु-नोड सिस्टम में प्रति घंटा देरी की समस्या को हल किया है। buffer manager हैश टैग ने बहुत अधिक share lock फ्लो के कारण काम नहीं किया, जिससे पुराने बफ़र्स को दबाने और नए लोगों को लोड करने के लिए आवश्यक लॉक के लिए कोई मौका नहीं बचा। डेटाबेस तालिकाओं के लिए बफर के विस्तार के साथ समस्याएं केवल इसका एक परिणाम थी। इससे पहले, B-tree रूट तक पहुंच के साथ अड़चन का विस्तार करना संभव था।

PostgreSQL NUMA आर्किटेक्चर और सुपर कंप्यूटर के लिए डिज़ाइन नहीं किया गया था। इस तरह के पोस्टग्रैज आर्किटेक्चर को अपनाना एक बहुत बड़ा काम है, जिसके लिए कई लोगों और कंपनियों के समन्वित प्रयासों की आवश्यकता होगी (और संभवतः इसकी आवश्यकता होगी)। लेकिन इन वास्तु समस्याओं के अप्रिय परिणामों को कम किया जा सकता है। और हमें यह करना होगा: जिन प्रकार के भारों के कारण देरी हुई, उनका वर्णन बहुत ही विशिष्ट है, अन्य स्थानों से भी इसी तरह के संकट के संकेत हमारे पास आते रहते हैं। इसी तरह की परेशानी पहले दिखाई दी - कम कोर वाले सिस्टम पर, बस परिणाम इतने राक्षसी नहीं थे, और लक्षणों का इलाज अन्य तरीकों और अन्य पैच के साथ किया गया था। अब एक और दवा दिखाई दी है - सार्वभौमिक नहीं है, लेकिन स्पष्ट रूप से उपयोगी है।

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