Linux-ის ბირთვის პარამეტრების კონფიგურაცია PostgreSQL-ის ოპტიმიზაციისთვის

PostgreSQL-ის ოპტიმალური შესრულება დამოკიდებულია ოპერაციული სისტემის სწორად განსაზღვრულ პარამეტრებზე. OS-ის ბირთვის ცუდად კონფიგურირებულმა პარამეტრებმა შეიძლება გამოიწვიოს მონაცემთა ბაზის სერვერის ცუდი მუშაობა. ამიტომ, აუცილებელია, რომ ეს პარამეტრები კონფიგურირებული იყოს მონაცემთა ბაზის სერვერისა და მისი დატვირთვის მიხედვით. ამ პოსტში განვიხილავთ Linux-ის ბირთვის რამდენიმე მნიშვნელოვან პარამეტრს, რომლებსაც შეუძლიათ გავლენა მოახდინონ მონაცემთა ბაზის სერვერის მუშაობაზე და მათი კონფიგურაციის შესახებ.

SHMMAX / SHMALL

SHMMAX არის ბირთვის პარამეტრი, რომელიც გამოიყენება ერთი საერთო მეხსიერების სეგმენტის მაქსიმალური ზომის დასადგენად, რომელიც Linux პროცესს შეუძლია გამოყოს. 9.2 ვერსიამდე PostgreSQL იყენებდა System V (SysV), რომელიც მოითხოვს SHMMAX პარამეტრს. 9.2-ის შემდეგ, PostgreSQL გადავიდა POSIX საერთო მეხსიერებაზე. ასე რომ, ახლა საჭიროა System V-ის საზიარო მეხსიერების ნაკლები ბაიტი.

9.3 ვერსიამდე SHMMAX იყო ბირთვის ყველაზე მნიშვნელოვანი პარამეტრი. SHMMAX მნიშვნელობა მითითებულია ბაიტებში.

ანალოგიურად, SHMALL არის ბირთვის კიდევ ერთი პარამეტრი, რომელიც გამოიყენება განსაზღვრისთვის
საერთო მეხსიერების გვერდების სისტემური მოცულობა. მიმდინარე SHMMAX, SHMALL ან SHMMIN მნიშვნელობების სანახავად გამოიყენეთ ბრძანება ipcs.

SHM* დეტალები - Linux

$ 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-ის ძველი ვერსია და თქვენი 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-ზე:

• Linux: kernel.shmmax, kernel.shmall
• 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

ბირთვის პარამეტრების შეცვლა Linux-ზე

# 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

უზარმაზარი გვერდები

Linux ნაგულისხმევად იყენებს 4 KB მეხსიერების გვერდებს, BSD იყენებს XNUMX KB მეხსიერების გვერდებს. სუპერ გვერდებიდა Windows-ზე - დიდი გვერდები. გვერდი არის RAM-ის ნაწილი, რომელიც გამოყოფილია პროცესზე. პროცესს შეიძლება ჰქონდეს რამდენიმე გვერდი, რაც დამოკიდებულია მეხსიერების მოთხოვნილებებზე. რაც უფრო მეტ მეხსიერებას მოითხოვს პროცესი, მით მეტი გვერდია გამოყოფილი. OS ინახავს პროცესების გვერდის განაწილების ცხრილს. რაც უფრო მცირეა გვერდის ზომა, რაც უფრო დიდია ცხრილი, მით უფრო მეტი დრო სჭირდება ამ გვერდის ცხრილში გვერდის პოვნას. ამიტომ დიდი გვერდები საშუალებას იძლევა დიდი რაოდენობით მეხსიერების გამოყენება შემცირებული ზედნადებით; ნაკლები გვერდის ნახვა, ნაკლები გვერდის შეცდომები, უფრო სწრაფი წაკითხვის/ჩაწერის ოპერაციები უფრო დიდ ბუფერებზე. შედეგი არის გაუმჯობესებული შესრულება.

PostgreSQL მხარს უჭერს მხოლოდ დიდ გვერდებს Linux-ზე. ნაგულისხმევად, Linux იყენებს 4 KB მეხსიერების გვერდებს, ამიტომ იმ შემთხვევებში, როდესაც მეხსიერების ძალიან ბევრი ოპერაციაა, საჭიროა უფრო დიდი გვერდების დაყენება. ეფექტურობის ზრდა შეინიშნება 2 მბ და 1 გბ-მდე დიდი გვერდების გამოყენებისას. გვერდის დიდი ზომის დაყენება შესაძლებელია ჩატვირთვის დროს. თქვენ შეგიძლიათ მარტივად შეამოწმოთ დიდი გვერდის პარამეტრები და მათი გამოყენება თქვენს Linux აპარატზე ბრძანების გამოყენებით კატა /proc/meminfo | grep -ი უზარმაზარი.

დიდი გვერდების შესახებ ინფორმაციის მიღება (მხოლოდ Linux)

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-ზე. ეს ნიშნავს, რომ დიდი გვერდები გამორთულია.

სკრიპტი დიდი გვერდების რაოდენობის დასადგენად

ეს მარტივი სკრიპტი აბრუნებს დიდი გვერდების საჭირო რაოდენობას. გაუშვით სკრიპტი თქვენს Linux სერვერზე, სანამ PostgreSQL მუშაობს. დარწმუნდით, რომ გარემოს ცვლადი $PGDATA მითითებულია 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).

დიდი გვერდები ხელახლა განხილულია (მხოლოდ Linux)

$ 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

ახლა დააყენეთ უზარმაზარი_pages პარამეტრი "on"-ზე $PGDATA/postgresql.conf-ში და გადატვირთეთ სერვერი.

კიდევ ერთხელ, ინფორმაცია დიდი გვერდების შესახებ (მხოლოდ Linux)

$ 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-ის სავარაუდო მნიშვნელობა ძალიან დაბალია, რაც არ არის ნორმალური მნიშვნელობა იმ აპარატისთვის, რომელიც მუშაობს პროდუქტის გარემოში. გთხოვთ შეაფასოთ თქვენი სისტემისთვის საჭირო გვერდების რაოდენობა და დააყენოთ ისინი დატვირთვისა და რესურსების შესაბამისად.

vm.swappiness

vm.swappiness არის ბირთვის კიდევ ერთი პარამეტრი, რომელსაც შეუძლია გავლენა მოახდინოს მონაცემთა ბაზის მუშაობაზე. ეს პარამეტრი გამოიყენება Linux-ზე ცვლადი ქცევის გასაკონტროლებლად (გვერდების ჩანაცვლება მეხსიერებიდან და გარეთ). მნიშვნელობა მერყეობს 0-დან 100-მდე. ის განსაზღვრავს, თუ რამდენი მეხსიერების იქნება გვერდი ან გვერდი. ნული ნიშნავს არ გაცვლას და 100 ნიშნავს აგრესიულ გაცვლას.

თქვენ შეგიძლიათ მიიღოთ კარგი შესრულება ქვედა მნიშვნელობების დაყენებით.

ახალ ბირთვებზე ამის 0-ზე დაყენებამ შეიძლება გამოიწვიოს OOM Killer (Linux-ის მეხსიერების გაწმენდის პროცესი) პროცესის მოკვლა. ასე რომ, უსაფრთხოა დააყენოთ ის 1-ზე, თუ გსურთ მინიმუმამდე დაიყვანოთ შეცვლა. ლინუქსის ნაგულისხმევი მნიშვნელობა არის 60. უფრო მაღალი მნიშვნელობა აიძულებს MMU-ს (მეხსიერების მართვის ერთეული) გამოიყენოს მეტი swap სივრცე ვიდრე RAM, ხოლო დაბალი მნიშვნელობა ინახავს მეტ მონაცემს/კოდს მეხსიერებაში.

უფრო დაბალი ღირებულება არის კარგი ფსონი PostgreSQL-ში გაუმჯობესებული მუშაობისთვის.

vm.overcommit_memory / vm.overcommit_ratio

აპლიკაციები იძენენ მეხსიერებას და ათავისუფლებენ მას, როცა აღარ არის საჭირო. მაგრამ ზოგიერთ შემთხვევაში, აპლიკაცია იღებს ძალიან დიდ მეხსიერებას და არ ათავისუფლებს მას. ამან შეიძლება გამოიწვიოს OOM მკვლელი. აქ მოცემულია პარამეტრების შესაძლო მნიშვნელობები vm.overcommit_memory თითოეულის აღწერით:

1. ევრისტიკული გადამეტება (ნაგულისხმევი); ბირთვზე დაფუძნებული ევრისტიკა
2. მაინც დაუშვით გადამეტება
3. ნუ გადააჭარბებთ, ნუ გადააჭარბებთ ზედმეტობის კოეფიციენტს.

ბმული: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - RAM-ის პროცენტი ხელმისაწვდომია გადატვირთვისთვის. 50 GB ოპერატიული მეხსიერების მქონე სისტემაზე 2%-იანი ღირებულება შეიძლება გამოყოს 3 გბ-მდე ოპერატიული მეხსიერება.

2-ის მნიშვნელობა vm.overcommit_memory-სთვის უზრუნველყოფს უკეთეს შესრულებას PostgreSQL-ისთვის. ეს მნიშვნელობა აძლიერებს სერვერის პროცესის ოპერატიული მეხსიერების მოხმარებას OOM მკვლელის პროცესის მიერ მოკვლის მნიშვნელოვანი რისკის გარეშე. აპლიკაციას შეეძლება გადატვირთვა, მაგრამ მხოლოდ გადაჭარბების ფარგლებში, რაც ამცირებს 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 არის ნაგულისხმევი Linux სისტემების უმეტესობაში. თქვენ შეგიძლიათ გააუმჯობესოთ შესრულება ჩაწერის ინტენსიური ოპერაციებისთვის უფრო მცირე ფაქტორით, რაც ნიშნავს, რომ Linux ასუფთავებს ბინძურ გვერდებს ფონზე.

თქვენ უნდა დააყენოთ მნიშვნელობა vm.dirty_background_bytes თქვენი დისკის სიჩქარის მიხედვით.

არ არსებობს "კარგი" მნიშვნელობები ამ ორი პარამეტრისთვის, რადგან ორივე დამოკიდებულია აპარატურაზე. თუმცა, 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 დატვირთვის მიხედვით.

სულ

თქვენ შეგიძლიათ შეცვალოთ სხვა პარამეტრები შესრულების გასაუმჯობესებლად, მაგრამ გაუმჯობესებები მინიმალური იქნება და დიდ სარგებელს ვერ ნახავთ. უნდა გვახსოვდეს, რომ ყველა ვარიანტი არ ვრცელდება ყველა ტიპის აპლიკაციაზე. ზოგიერთი აპი უკეთ მუშაობს, როცა ზოგიერთ პარამეტრს ვარეგულირებთ, ზოგი კი არა. თქვენ უნდა იპოვოთ სწორი ბალანსი ამ პარამეტრების კონფიგურაციას თქვენი მოსალოდნელი დატვირთვისა და აპლიკაციის ტიპისთვის შორის და ასევე უნდა გაითვალისწინოთ OS-ის ქცევა დაყენებისას. ბირთვის პარამეტრების კონფიგურაცია არც ისე ადვილია, როგორც მონაცემთა ბაზის პარამეტრების კონფიგურაცია; უფრო რთულია რეკომენდაციების გაკეთება.

წყარო: www.habr.com