🥇PostgreSQL को अनुकूलित करने के लिए Linux कर्नेल मापदंडों में बदलाव

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

SHMMAX/SHMMAL

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

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

इसी तरह, SHMALL एक अन्य कर्नेल पैरामीटर है जिसका उपयोग निर्धारित करने के लिए किया जाता है
साझा स्मृति पृष्ठों का कुल सिस्टम आकार। वर्तमान SHMMAX, SHMALL, या SHMMIN मान देखने के लिए, कमांड का उपयोग करें आईपीसी.

एसएचएम* विवरण - लिनक्स

$ 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

एसएचएम* विवरण - मैकओएस एक्स

$ 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 का उपयोग करता है सिस्टम वी आईपीसी साझा स्मृति आवंटित करने के लिए. यह सेटिंग सबसे महत्वपूर्ण कर्नेल विकल्पों में से एक है. जब भी आपको निम्नलिखित त्रुटि संदेश मिलते हैं, तो इसका मतलब है कि आपके पास PostgreSQL का पुराना संस्करण है और उसका SHMMAX मान बहुत कम है। उपयोगकर्ताओं से अपेक्षा की जाती है कि वे जिस साझा मेमोरी का उपयोग करना चाहते हैं उसके अनुसार मूल्य को समायोजित और बढ़ाएं।

संभावित गलत कॉन्फ़िगरेशन त्रुटियाँ

यदि SHMMAX गलत तरीके से कॉन्फ़िगर किया गया है, तो कमांड के साथ PostgreSQL क्लस्टर को प्रारंभ करने का प्रयास करते समय आपको एक त्रुटि मिल सकती है initdb.

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

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

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 विकल्पों की परिभाषा Linux और 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 में जोड़ें

विशाल पन्ने

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

PostgreSQL केवल Linux पर बड़े पेजों का समर्थन करता है। डिफ़ॉल्ट रूप से, लिनक्स 4 केबी मेमोरी पेजों का उपयोग करता है, इसलिए ऐसे मामलों में जहां बहुत अधिक मेमोरी ऑपरेशन हैं, बड़े पेज स्थापित करना आवश्यक है। 2 एमबी और 1 जीबी तक के बड़े पेजों का उपयोग करने पर प्रदर्शन में वृद्धि होती है। लोड समय पर बड़े पेज का आकार सेट किया जा सकता है। आप कमांड का उपयोग करके अपने लिनक्स मशीन पर बड़े पेज विकल्पों और उनके उपयोग को आसानी से जांच सकते हैं बिल्ली /proc/meminfo | ग्रेप-मैं विशाल.

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

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 चल रहा हो तो स्क्रिप्ट को अपने Linux सर्वर पर चलाएँ। सुनिश्चित करें कि पर्यावरण चर पर सेट है $पीजीडेटा PostgreSQL डेटा निर्देशिका निर्दिष्ट है।

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

#!/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 में big_pages विकल्प को "चालू" पर सेट करें और सर्वर को पुनरारंभ करें।

बड़े पृष्ठ की जानकारी फिर से (केवल लिनक्स पर)

$ 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

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

बड़े पेजों के बारे में अधिक जानकारी (केवल Linux)

$ 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 का उदाहरण मान बहुत कम है, जो एक उत्पादन मशीन के लिए सामान्य नहीं है। कृपया अपने सिस्टम के लिए पृष्ठों की आवश्यक संख्या का अनुमान लगाएं और लोड और संसाधनों के आधार पर उन्हें तदनुसार सेट करें।

वी.एम.स्वैपीनेस

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

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

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

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

vm.overcommit_memory / vm.overcommit_ratio

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

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

संदर्भ: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

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

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

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

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.डर्टी_बैकग्राउंड_बाइट्स आपकी डिस्क की गति के आधार पर.

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

vm.dirty_ratio/dirty_bytes

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

संपूर्ण

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

स्रोत: www.habr.com

PostgreSQL को अनुकूलित करने के लिए Linux कर्नेल विकल्पों को ट्यून करना