👨‍🎨 💃🏾 🚝 PostgreSQL का अनुकूलन करने के लिए लिनक्स कर्नेल पैरामीटर ट्यूनिंग 👩🏼‍💼 🚵🏿 🤫

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

SHMMAX / SHMALL

SHMMAX एक कर्नेल पैरामीटर है जिसका उपयोग एकल साझा मेमोरी सेगमेंट के अधिकतम आकार को निर्धारित करने के लिए किया जाता है, जिसे लिनक्स प्रक्रिया आवंटित कर सकती है। संस्करण 9.2 से पहले, PostgreSQL ने सिस्टम V (SysV) का उपयोग किया, जिसके लिए SHMMAX कॉन्फ़िगरेशन की आवश्यकता होती है। 9.2 के बाद, PostgreSQL ने POSIX साझा की गई मेमोरी पर स्विच कर दिया। तो अब सिस्टम वी शेयर्ड मेमोरी के कम बाइट्स की आवश्यकता है।

संस्करण 9.3 से पहले, SHMMAX सबसे महत्वपूर्ण कर्नेल पैरामीटर था। SHMMAX मान बाइट्स में निर्दिष्ट है।

इसी तरह, SHMALL एक और कर्नेल पैरामीटर है जिसे निर्धारित करने के लिए उपयोग किया जाता है
सिस्टम-वाइड साझा मेमोरी पेज। वर्तमान SHMMAX, SHMALL या SHMMIN मान देखने के लिए ipcs कमांड का उपयोग करें।

^{SHM * विवरण - लिनक्स}

$ ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 1073741824 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1

^{SHM * विवरण - MacOS X}

 $ ipcs -M IPC status from as of Thu Aug 16 22:20:35 PKT 2018 shminfo: shmmax: 16777216 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 32 (max number of shared memory identifiers) shmseg: 8 (max shared memory segments per process) shmall: 1024 (max amount of shared memory in pages)

साझा मेमोरी आवंटित करने के लिए PostgreSQL सिस्टम V IPC का उपयोग करता है। यह पैरामीटर सबसे महत्वपूर्ण कर्नेल मापदंडों में से एक है। जब भी आपको निम्न त्रुटि संदेश मिलते हैं, तो इसका मतलब है कि आपके पास PostgreSQL का पुराना संस्करण है और आपके पास SHMAXAX का मूल्य बहुत कम है। यह उम्मीद की जाती है कि उपयोगकर्ता साझा की गई मेमोरी के अनुसार मूल्य को समायोजित और बढ़ाएंगे जो वे उपयोग करने जा रहे हैं।

संभव ग़लतफ़हमी त्रुटियों

यदि SHMMAX को सही तरीके से कॉन्फ़िगर नहीं किया गया है, तो आप इनबिलट कमांड का उपयोग करके पोस्टग्रेएसक्यूएल क्लस्टर को इनिशियलाइज़ करने की कोशिश करते समय एक त्रुटि प्राप्त कर सकते हैं।

^{initdb की विफलता}

DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

इसी तरह, आपको pg_ctl कमांड का उपयोग करके PostgreSQL सर्वर शुरू करते समय एक त्रुटि प्राप्त हो सकती है।

^{pg_ctl विफलता}

DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

परिभाषाओं में अंतर समझना

SHMMAX / SHMALL मापदंडों की परिभाषा लिनक्स और MacOS X पर थोड़ी अलग है:

लिनक्स: कर्नेल।शम्मैक्स, कर्नेल।शमॉल
MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Sysctl कमांड का उपयोग अस्थायी रूप से मान बदलने के लिए किया जा सकता है। निरंतर मान सेट करने के लिए, /etc/sysctl.conf में एक प्रविष्टि जोड़ें । विवरण नीचे दिया गया है।

^{MacOS X पर कर्नेल सेटिंग्स बदलें}

 # Get the value of SHMMAX sudo sysctl kern.sysv.shmmax kern.sysv.shmmax: 4096 # Get the value of SHMALL sudo sysctl kern.sysv.shmall kern.sysv.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kern.sysv.shmmax=16777216 kern.sysv.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kern.sysv.shmall=16777216 kern.sysv.shmall: 4096 -> 16777216

^{लिनक्स कर्नेल पैरामीटर बदलना}

 # Get the value of SHMMAX sudo sysctl kernel.shmmax kernel.shmmax: 4096 # Get the value of SHMALL sudo sysctl kernel.shmall kernel.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kernel.shmmax=16777216 kernel.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kernel.shmall=16777216 kernel.shmall: 4096 -> 16777216

_{याद रखें : परिवर्तन को स्थायी बनाने के लिए, इन मानों को /etc/sysctl.conf में जोड़ें}

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

4K पेजों के लिए लिनक्स डिफॉल्ट, बीएसडी सुपर पेज का उपयोग करता है, और विंडोज बड़े पेज का उपयोग करता है। एक पेज एक प्रक्रिया को आवंटित रैम का एक टुकड़ा है। स्मृति आवश्यकताओं के आधार पर एक प्रक्रिया में कई पृष्ठ हो सकते हैं। एक प्रक्रिया को जितनी अधिक मेमोरी की आवश्यकता होती है, उतने अधिक पृष्ठ इसे आवंटित किए गए हैं। ओएस प्रक्रियाओं के लिए एक पृष्ठ आवंटन तालिका का समर्थन करता है। पेज का आकार जितना छोटा होगा, टेबल उतना बड़ा होगा, इस पेज टेबल में पेज खोजने में अधिक समय लगेगा। इसलिए, बड़े पृष्ठ आपको कम ओवरहेड के साथ बड़ी मात्रा में मेमोरी का उपयोग करने की अनुमति देते हैं; कम पृष्ठ दृश्य, कम पृष्ठ त्रुटियां, बड़े बफ़र्स के माध्यम से तेज़ी से पढ़ना / लिखना। परिणाम बेहतर प्रदर्शन है।

PostgreSQL केवल लिनक्स पर बड़े पृष्ठों का समर्थन करता है। डिफ़ॉल्ट रूप से, लिनक्स 4 KB मेमोरी पेज का उपयोग करता है, इसलिए यदि आपके पास बहुत सारे मेमोरी ऑपरेशन हैं, तो आपको बड़े पेज इंस्टॉल करने होंगे। 2 एमबी के बड़े पृष्ठों और 1 जीबी तक का उपयोग करने पर प्रदर्शन लाभ होता है। बड़े पृष्ठ का आकार बूट समय पर सेट किया जा सकता है। आप कमांड बिल्ली / proc / meminfo का उपयोग करके अपने लिनक्स कंप्यूटर पर बड़े पृष्ठ के मापदंडों और उनके उपयोग को आसानी से देख सकते हैं grep -i विशाल ।

^{बड़े पृष्ठों के बारे में जानकारी प्राप्त करना (केवल लिनक्स)}

 Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:      0 HugePages_Free:       0 HugePages_Rsvd:       0 HugePages_Surp:       0 Hugepagesize:      2048 kB

इस उदाहरण में, हालांकि बड़े पृष्ठ का आकार 2048 (2 एमबी) पर सेट है, बड़े पृष्ठों की कुल संख्या 0. है। इसका मतलब है कि बड़े पृष्ठ अक्षम हैं।

बड़े पृष्ठों की संख्या के निर्धारण के लिए स्क्रिप्ट

यह सरल स्क्रिप्ट बड़े पृष्ठों की आवश्यक संख्या लौटाती है। PostgreSQL चल रहा है, जबकि अपने लिनक्स सर्वर पर स्क्रिप्ट चलाएँ। सत्यापित करें कि PostgreSQL डेटा निर्देशिका $ PGDATA पर्यावरण चर के लिए सेट की गई है।

^{आवश्यक बड़े पृष्ठों की संख्या प्राप्त करना}

 #!/bin/bash pid=`head -1 $PGDATA/postmaster.pid` echo "Pid:           $pid" peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'` echo "VmPeak:          $peak kB" hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'` echo "Hugepagesize:  $hps kB" hp=$((peak/hps)) echo Set Huge Pages:    $hp

स्क्रिप्ट आउटपुट निम्नानुसार है:

^{स्क्रिप्ट आउटपुट}

 Pid:           12737 VmPeak:        180932 kB Hugepagesize:  2048 kB Set Huge Pages: 88

बड़े पृष्ठों के लिए अनुशंसित मूल्य 88 है, इसलिए आपको इसे 88 पर सेट करना चाहिए।

^{बड़े पृष्ठ स्थापित करें}

 sysctl -w vm.nr_hugepages=88

अब बड़े पृष्ठों की जाँच करें, आप देखेंगे कि बड़े पृष्ठों का उपयोग नहीं किया गया है (HugePages_Free = HugePages_Total)।

^{बड़े पृष्ठों के बारे में फिर से जानकारी (केवल लिनक्स)}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      88 HugePages_Rsvd:       0 HugePages_Surp:       0 Hugepagesize:      2048 kB

अब $ PGDATA / postgresql.conf के लिए "पर" विशाल_पृष्ठ सेट करें और सर्वर को पुनरारंभ करें।

^{और फिर से, बड़े पृष्ठों (केवल लिनक्स) के बारे में जानकारी}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      81 HugePages_Rsvd:       64 HugePages_Surp:       0 Hugepagesize:      2048 kB

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

^{कुछ डेटाबेस बड़े पृष्ठों के पुनर्चक्रण के लिए संचालन करते हैं}

 postgres=# CREATE TABLE foo(a INTEGER); CREATE TABLE postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000)); INSERT 0 10000000

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

^{एक बार फिर बड़े पृष्ठों पर जानकारी (केवल लिनक्स)}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      18 HugePages_Rsvd:       1 HugePages_Surp:       0 Hugepagesize:      2048 kB

अब आप देख सकते हैं कि अधिकांश बड़े पृष्ठ उपयोग में हैं।

_{नोट: यहां उपयोग किए गए HugePages के लिए अनुमानित मूल्य बहुत कम है, जो कि खाद्य वातावरण में मशीन के लिए एक सामान्य मूल्य नहीं है।} _{कृपया अपने सिस्टम के लिए आवश्यक पृष्ठों की संख्या का मूल्यांकन करें और उन्हें लोड और संसाधनों के आधार पर निर्धारित करें।}

vm.swappiness

vm.swappiness एक अन्य कर्नेल पैरामीटर है जो डेटाबेस प्रदर्शन को प्रभावित कर सकता है। इस पैरामीटर का उपयोग लिनक्स पर स्वपनदोष व्यवहार (मेमोरी से पेज को और मेमोरी को स्वैप करने) को नियंत्रित करने के लिए किया जाता है। मान 0 से 100 तक होता है। यह निर्धारित करता है कि मेमोरी कितनी अनलोड या अनलोड होगी। शून्य का अर्थ है विनिमय को अक्षम करना, और 100 का अर्थ है आक्रामक विनिमय।

आप निम्न मान सेट करके अच्छा प्रदर्शन प्राप्त कर सकते हैं।

नए कर्नेल में मान को 0 पर सेट करने से ओओएम किलर (लिनक्स मेमोरी क्लीनअप प्रक्रिया) हो सकती है। इस प्रकार, आप सुरक्षित रूप से 1 को मान सेट कर सकते हैं यदि आप स्वैपिंग को कम से कम करना चाहते हैं। लिनक्स पर डिफ़ॉल्ट मान 60 है। एक उच्च मूल्य रैम की तुलना में अधिक पेजिंग स्थान का उपयोग करने के लिए MMU (मेमोरी मैनेजमेंट यूनिट) का कारण बनता है, जबकि कम मूल्य मेमोरी में अधिक डेटा / कोड बचाता है।

एक कम मूल्य PostgreSQL में प्रदर्शन में सुधार करने के लिए एक अच्छा शर्त है।

vm.overcommit_memory / vm.overcommit_ratio

एप्लिकेशन मेमोरी प्राप्त करते हैं और इसे तब फ्री करते हैं जब इसकी आवश्यकता नहीं होती है। लेकिन कुछ मामलों में, एप्लिकेशन को बहुत अधिक मेमोरी मिलती है और इसे मुक्त नहीं करता है। यह एक OOM किलर का कारण बन सकता है। यहां प्रत्येक के लिए विवरण के साथ vm.overcommit_memory पैरामीटर के संभावित मान दिए गए हैं:

हेयुरिस्टिक ओवरकमिट (डिफ़ॉल्ट); कोर-आधारित हेयुरिस्टिक
फिर भी ओवरकम की अनुमति दें
इसे ज़्यादा मत करो, ओवरकम के अनुपात से अधिक न हो।

लिंक: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - अधिभार के लिए उपलब्ध RAM का प्रतिशत। 2 जीबी रैम वाले सिस्टम में 50% का मान 3 जीबी तक रैम आवंटित कर सकता है।

Vm.overcommit_memory के लिए 2 का मान PostgreSQL के लिए बेहतर प्रदर्शन प्रदान करता है। यह मान OOM किलर प्रक्रिया द्वारा मारे जाने के किसी भी महत्वपूर्ण जोखिम के बिना सर्वर प्रक्रिया द्वारा रैम उपयोग को अधिकतम करता है। एप्लिकेशन को पुनरारंभ करने में सक्षम होगा, लेकिन केवल ओवरस्पेंडिंग के भीतर, जो जोखिम को कम करता है कि ओओएम हत्यारा प्रक्रिया को मार देगा। इसलिए, 2 का मान 0. के डिफ़ॉल्ट मान से बेहतर प्रदर्शन देता है। हालांकि, यह सुनिश्चित करके विश्वसनीयता में सुधार किया जा सकता है कि स्वीकार्य सीमा से बाहर की मेमोरी ओवरलोड नहीं है। यह जोखिम को समाप्त करता है कि प्रक्रिया OOM- हत्यारे द्वारा मार दी जाएगी।

नॉन-पेजिंग सिस्टम पर, 2 के बराबर vm.overcommit_memory के साथ कोई समस्या हो सकती है।

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio गंदे पृष्ठों से भरी हुई मेमोरी का प्रतिशत है जिसे डिस्क पर लिखने की आवश्यकता होती है। पृष्ठभूमि में डिस्क पर रीसेट करें। इस पैरामीटर का मान 0 से 100 तक है; हालाँकि, 5 से नीचे का मूल्य अक्षम हो सकता है, और कुछ कर्नेल इसका समर्थन नहीं करते हैं। 10 अधिकांश लिनक्स सिस्टम पर डिफ़ॉल्ट मान है। आप कम दर पर गहन रिकॉर्डिंग संचालन के लिए प्रदर्शन में सुधार कर सकते हैं, जिसका अर्थ होगा कि लिनक्स पृष्ठभूमि में गंदे पृष्ठों को डंप करेगा।

आपको अपनी डिस्क की गति के आधार पर vm.dirty_background_bytes का मान सेट करना होगा।

इन दोनों मापदंडों के लिए कोई "अच्छा" मान नहीं है, क्योंकि दोनों हार्डवेयर निर्भर हैं। हालाँकि, डिस्क की गति में vm.dirty_background_ratio को 5 और vm.dirty_background_bytes पर सेट करने से अधिकांश मामलों में प्रदर्शन 25% तक बढ़ जाएगा।

vm.dirty_ratio / dirty_bytes

यह vm.dirty_background_ratio / dirty_background_bytes के समान है , सिवाय इसके कि रीसेट कार्यशील सत्र में किया जाता है, जिससे अनुप्रयोग अवरुद्ध हो जाता है। इसलिए, vm.dirty_ratio vm.dirty_background_ratio से अधिक होना चाहिए। यह सुनिश्चित करता है कि पृष्ठभूमि की प्रक्रिया पहले से शुरू हो जाएगी ताकि आवेदन को यथासंभव अवरुद्ध करने से बचा जा सके। आप डिस्क I / O लोड के आधार पर इन दो अनुपातों के बीच अंतर को समायोजित कर सकते हैं।

परिणाम

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

PostgreSQL का अनुकूलन करने के लिए लिनक्स कर्नेल पैरामीटर ट्यूनिंग