🧙🏾 🔤 👩🏽 लिनक्स पर HugePages के साथ PostgreSQL का परीक्षण 🌗 🙂 📂

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

पीसी जिस पर परीक्षण किया गया था

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

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

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

PostgreSQL सेटिंग्स

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

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 मिनट है। इन 3 परीक्षणों के परिणामों के आधार पर, मैंने औसत मूल्य घटाया। PostgreSQL pgbench टूल का उपयोग करके परीक्षण किया गया था, यह लगभग 16 एमबी के लोड की वृद्धि में स्केलिंग कारक के साथ काम करता है।

hugepages

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

यहाँ विशाल आकार में 1 जीबी के लिए सेटिंग्स हैं। यह जानकारी किसी भी समय / खरीद के उपयोग पर उपलब्ध है।

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

मैंने पिछले पोस्ट में HugePages के बारे में और लिखा है।

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

सामान्य तौर पर, HugePages 2 एमबी और 1 जीबी आकार में हैं, इसलिए यह 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/

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

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

तब 2 एमबी के आकार के साथ हेजपेज के लिए परीक्षणों का दूसरा सेट किया गया था। अंत में, 1GB HugePages के लिए परीक्षणों का तीसरा सेट चलाया गया।

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

उपरोक्त ग्राफ से, यह देखा जा सकता है कि, HugePages के उपयोग से, लाभ बढ़ता है क्योंकि ग्राहकों की संख्या और डेटाबेस का आकार बढ़ता है, जब तक कि यह आकार पूर्व-आवंटित साझा बफर के भीतर रहता है।

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

जब HugePages 1 GB आकार का है, तो तुलनात्मक प्रदर्शन लाभ ग्राहकों की संख्या के साथ बढ़ता है।

अगला ग्राफ़ पिछले वाले के समान है, लेकिन डेटाबेस का आकार 96 जीबी है। यह 64 जीबी के निश्चित कुल बफर आकार से बड़ा है।

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

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

जैसा कि अपेक्षित था, जब डेटाबेस का आकार पूर्व-आवंटित किए गए HugePages के आकार से अधिक हो जाता है, तो प्रदर्शन काफी कम हो जाता है।

निष्कर्ष

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

लिनक्स पर HugePages के साथ PostgreSQL का परीक्षण