बड़े लिनक्स पन्नों के साथ बेंचमार्किंग पोस्टग्रेक्यूएल

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

परीक्षण मशीन

• सुपरमाइक्रो सर्वर:
  
  • Intel® Xeon® CPU E5-2683 v3 @ 2.00GHz
  • 2 सॉकेट / 28 कोर / 56 धागे
  • मेमोरी: 256GB RAM
  • भंडारण: सैमसंग SM863 1.9TB एंटरप्राइज एसएसडी
  • फाइलसिस्टम: ext4 / xfs
• OS: Ubuntu 16.04.4, कर्नेल 4.13.0-36-जेनेरिक
• PostgreSQL: संस्करण 11

लिनक्स कर्नेल सेटिंग्स

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

PostgreSQL सेटिंग्स

मैंने सभी पोस्टग्रेएसक्यूएल वर्कलोड को बड़े लिनक्स पन्नों के लिए अलग-अलग सेटिंग्स के साथ रिकॉर्ड करने के लिए सभी टेस्ट के लिए एक समान पोस्टग्रेक्यूएल सेटिंग्स का उपयोग किया। यहाँ सभी परीक्षणों के लिए PostgreSQL सेटअप का उपयोग किया गया है:

^{postgresql.conf}

shared_buffers = '64GB' work_mem = '1GB' random_page_cost = '1' maintenance_work_mem = '2GB' synchronous_commit = 'on' seq_page_cost = '1' max_wal_size = '100GB' checkpoint_timeout = '10min' synchronous_commit = 'on' checkpoint_completion_target = '0.9' autovacuum_vacuum_scale_factor = '0.4' effective_cache_size = '200GB' min_wal_size = '1GB' wal_compression = 'ON' 

परीक्षण योजना

परीक्षण में, परीक्षण योजना एक महत्वपूर्ण भूमिका निभाती है। सभी परीक्षण प्रत्येक रन के लिए 30 मिनट के लिए तीन बार किए जाते हैं। मैंने इन तीन संकेतकों का औसत लिया। PostgreSQL pgbench प्रदर्शन परीक्षण उपकरण का उपयोग करके परीक्षण किए गए थे। pgbench एक स्केल फैक्टर के साथ काम करता है, जिसमें एक स्केल फैक्टर लगभग 16 एमबी का होता है।

बड़े पृष्ठ (विशाल पृष्ठ)

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

यहां 1 जीबी के बड़े पृष्ठ आकार का उपयोग करते समय बड़े पृष्ठों के लिए सेटअप है। आप इसकी जानकारी हमेशा / खरीद से प्राप्त कर सकते हैं।

^{$ बिल्ली / proc / meminfo | grep -i विशाल}

 AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 100 HugePages_Free: 97 HugePages_Rsvd: 63 HugePages_Surp: 0 Hugepagesize: 1048576 kB 

बड़े पृष्ठों की अधिक जानकारी के लिए, कृपया मेरे पिछले ब्लॉग पोस्ट को पढ़ें।

https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

आमतौर पर, बड़े पृष्ठ 2 एमबी और 1 जीबी होते हैं, इसलिए यह बहुत छोटे 2 एमबी के बजाय 1 जीबी का उपयोग करने के लिए समझ में आता है।

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/performance_tuning_guide/s-memory-transhuge
https://kerneltalks.com/services/what-is-huge-pages-in-linux/

परीक्षण के परिणाम

यह परीक्षण विभिन्न आकारों के बड़े पृष्ठों के समग्र प्रभाव को दर्शाता है। पहला परीक्षण सूट बड़े 4K को शामिल किए बिना लिनक्स 4K पर डिफ़ॉल्ट पृष्ठ आकार के साथ बनाया गया था। ध्यान दें कि पारदर्शी विशाल पृष्ठ भी इन सभी परीक्षणों में अक्षम और निष्क्रिय रहे।

फिर 2 एमबी के बड़े पृष्ठों पर परीक्षणों का दूसरा सेट किया गया। अंत में, परीक्षणों का तीसरा सेट 1 जीबी के बड़े पृष्ठों के साथ चलता है।

ये सभी परीक्षण PostgreSQL संस्करण 11 में किए गए थे। सेट में डेटाबेस और क्लाइंट के विभिन्न आकारों का संयोजन शामिल है। नीचे दिया गया ग्राफ, X अक्ष के साथ Y अक्ष, डेटाबेस आकार और प्रति डेटाबेस आकार के ग्राहकों की संख्या के साथ TPS (प्रति सेकंड लेनदेन) के साथ इन परीक्षणों के लिए तुलनात्मक प्रदर्शन परिणाम दिखाता है।



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

यह परीक्षण ग्राहकों की संख्या की तुलना में टीपीएस दिखाता है। इस स्थिति में, डेटाबेस का आकार 48 GB है। Y- अक्ष पर, हमारे पास TPS है, और X- अक्ष पर, हमारे पास जुड़े क्लाइंट की संख्या है। डेटाबेस का आकार एक साझा बफर में फिट होने के लिए काफी छोटा है जो 64 जीबी पर सेट है।



यदि बड़े पृष्ठों को 1 जीबी पर सेट किया जाता है, तो जितने अधिक ग्राहक होंगे, सापेक्ष प्रदर्शन उतना अधिक होगा।

निम्नलिखित ग्राफ़ 96 GB डेटाबेस आकार को छोड़कर, ऊपर के समान है। यह साझा बफर के आकार से अधिक है, जो 64 जीबी पर सेट है।



यहां मुख्य अवलोकन यह है कि 1 जीबी के बड़े पृष्ठों के साथ प्रदर्शन बढ़ जाता है क्योंकि ग्राहकों की संख्या बढ़ जाती है, और अंततः यह 2 एमबी के बड़े पृष्ठों या 4 केबी के मानक पृष्ठ आकार से अधिक प्रदर्शन देता है।

यह परीक्षण डेटाबेस के आकार के आधार पर टीपीएस दिखाता है। इस स्थिति में, कनेक्ट किए गए क्लाइंट की संख्या 32 है। Y- अक्ष पर, हमारे पास TPS है, और X- अक्ष पर - डेटाबेस आकार।



जैसा कि अपेक्षित था, जब डेटाबेस पहले से आवंटित बड़े पृष्ठों से आगे निकल जाता है, तो प्रदर्शन काफी कम हो जाता है।

सारांश

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