Mengkonfigurasi Pilihan Kernel Linux untuk Mengoptimumkan PostgreSQL

Mengkonfigurasi Pilihan Kernel Linux untuk Mengoptimumkan PostgreSQL Prestasi PostgreSQL yang optimum bergantung pada parameter sistem pengendalian yang ditakrifkan dengan betul. Tetapan kernel OS yang dikonfigurasikan dengan buruk boleh mengakibatkan prestasi pelayan pangkalan data yang lemah. Oleh itu, adalah penting bahawa tetapan ini dikonfigurasikan mengikut pelayan pangkalan data dan beban kerjanya. Dalam siaran ini, kami akan membincangkan beberapa parameter kernel Linux penting yang boleh menjejaskan prestasi pelayan pangkalan data dan cara mengkonfigurasinya.

SHMMAX / SHMALL

SHMMAX ialah parameter kernel yang digunakan untuk menentukan saiz maksimum segmen memori kongsi tunggal yang boleh diperuntukkan oleh proses Linux. Sebelum versi 9.2, PostgreSQL menggunakan Sistem V (SysV), yang memerlukan tetapan SHMMAX. Selepas 9.2, PostgreSQL bertukar kepada memori kongsi POSIX. Jadi kini lebih sedikit bait memori kongsi Sistem V diperlukan.

Sebelum versi 9.3, SHMMAX ialah parameter kernel yang paling penting. Nilai SHMMAX ditentukan dalam bait.

Begitu juga, SHMALL ialah satu lagi parameter kernel yang digunakan untuk menentukan
volum seluruh sistem halaman memori yang dikongsi. Untuk melihat nilai SHMMAX, SHMALL atau SHMMIN semasa, gunakan arahan ipcs.

Butiran 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

Butiran 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 menggunakan Sistem V IPC untuk memperuntukkan memori bersama. Parameter ini adalah salah satu parameter kernel yang paling penting. Setiap kali anda menerima mesej ralat berikut, ini bermakna anda mempunyai versi PostgreSQL yang lebih lama dan nilai SHMMAX anda sangat rendah. Pengguna dijangka melaraskan dan meningkatkan nilai mengikut memori kongsi yang mereka ingin gunakan.

Kemungkinan ralat salah konfigurasi

Jika SHMMAX tidak dikonfigurasikan dengan betul, anda mungkin menerima ralat apabila cuba memulakan kluster PostgreSQL menggunakan arahan initdb.

initdb Kegagalan
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

Begitu juga, anda mungkin menerima ralat semasa memulakan pelayan PostgreSQL menggunakan arahan pg_ctl.

pg_ctl Kegagalan
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.

Memahami perbezaan definisi

Mentakrifkan parameter SHMMAX/SHMALL sedikit berbeza pada Linux dan MacOS X:

  • Linux: kernel.shmmax, kernel.shmall
  • MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Pasukan sysctl boleh digunakan untuk menukar nilai buat sementara waktu. Untuk menetapkan nilai malar, tambahkan entri ke /etc/sysctl.conf. Butiran ada di bawah.

Menukar Tetapan Kernel pada 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

Menukar Parameter Kernel pada 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

Jangan lupa: Untuk membuat perubahan kekal, tambahkan nilai ini pada /etc/sysctl.conf

Halaman Besar

Linux menggunakan halaman memori 4 KB secara lalai, BSD menggunakan halaman memori XNUMX KB. Super Pages, dan pada Windows - Halaman Besar. Halaman ialah sekeping RAM yang diperuntukkan kepada proses. Satu proses boleh mempunyai berbilang halaman bergantung pada keperluan memori. Lebih banyak memori yang diperlukan oleh proses, lebih banyak halaman ia diperuntukkan. OS mengekalkan jadual peruntukan halaman untuk proses. Lebih kecil saiz halaman, lebih besar jadual, lebih lama masa yang diperlukan untuk mencari halaman dalam jadual halaman tersebut. Oleh itu, halaman yang besar membenarkan jumlah memori yang besar digunakan dengan overhed yang dikurangkan; paparan halaman yang lebih sedikit, kerosakan halaman yang lebih sedikit, operasi baca/tulis yang lebih pantas berbanding penimbal yang lebih besar. Hasilnya adalah prestasi yang lebih baik.

PostgreSQL hanya menyokong halaman besar di Linux. Secara lalai, Linux menggunakan halaman memori 4 KB, jadi dalam kes di mana terdapat terlalu banyak operasi memori, adalah perlu untuk menetapkan halaman yang lebih besar. Peningkatan prestasi diperhatikan apabila menggunakan halaman besar 2 MB dan sehingga 1 GB. Saiz halaman yang besar boleh ditetapkan pada masa boot. Anda boleh menyemak dengan mudah parameter halaman besar dan penggunaannya pada mesin Linux anda menggunakan arahan kucing /proc/meminfo | grep -i besar.

Mendapatkan maklumat tentang halaman besar (Linux sahaja)

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

Dalam contoh ini, walaupun saiz halaman besar ditetapkan kepada 2048 (2 MB), jumlah bilangan halaman besar ditetapkan kepada 0. Ini bermakna halaman besar dilumpuhkan.

Skrip untuk menentukan bilangan halaman yang besar

Skrip ringkas ini mengembalikan bilangan halaman besar yang diperlukan. Jalankan skrip pada pelayan Linux anda semasa PostgreSQL sedang berjalan. Pastikan untuk pembolehubah persekitaran $PGDATA Direktori data PostgreSQL ditentukan.

Mendapatkan bilangan halaman besar yang diperlukan

#!/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

Output skrip kelihatan seperti ini:

Keluaran skrip

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

Nilai yang disyorkan untuk halaman besar ialah 88, jadi anda harus menetapkannya kepada 88.

Memasang Halaman Besar

sysctl -w vm.nr_hugepages=88

Semak halaman besar sekarang, anda akan melihat bahawa halaman besar tidak digunakan (HugePages_Free = HugePages_Total).

Halaman Besar Dilawati Semula (Linux Sahaja)

$ 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

Sekarang tetapkan parameter huge_pages kepada "on" dalam $PGDATA/postgresql.conf dan mulakan semula pelayan.

Sekali lagi, maklumat tentang halaman besar (Linux sahaja)

$ 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

Kini anda dapat melihat bahawa sangat sedikit halaman besar digunakan. Sekarang mari cuba menambah beberapa data ke pangkalan data.

Beberapa operasi pangkalan data untuk mengitar semula halaman besar

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

Mari lihat sama ada kita menggunakan lebih banyak halaman besar sekarang berbanding sebelum ini.

Maklumat lanjut tentang halaman besar (Linux sahaja)

$ 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

Kini anda dapat melihat bahawa kebanyakan halaman besar sedang digunakan.

Nota: Anggaran nilai untuk HugePages yang digunakan di sini adalah sangat rendah, yang bukan nilai biasa untuk mesin yang menjalankan persekitaran produk. Sila anggarkan bilangan halaman yang diperlukan untuk sistem anda dan tetapkan dengan sewajarnya berdasarkan beban dan sumber.

vm.swappiness

vm.swappiness ialah satu lagi parameter kernel yang boleh menjejaskan prestasi pangkalan data. Pilihan ini digunakan untuk mengawal tingkah laku swappiness (menukar halaman masuk dan keluar dari memori) dalam Linux. Nilainya berkisar antara 0 hingga 100. Ia menentukan jumlah memori yang akan dihalakan atau dihalakan. Sifar bermakna tiada pertukaran dan 100 bermakna pertukaran agresif.

Anda boleh mendapatkan prestasi yang baik dengan menetapkan nilai yang lebih rendah.

Menetapkan ini kepada 0 pada kernel yang lebih baru boleh menyebabkan OOM Killer (proses pembersihan memori Linux) untuk mematikan proses tersebut. Jadi adalah selamat untuk menetapkannya kepada 1 jika anda ingin meminimumkan pertukaran. Nilai lalai dalam Linux ialah 60. Nilai yang lebih tinggi menyebabkan MMU (unit pengurusan memori) menggunakan lebih banyak ruang swap daripada RAM, manakala nilai yang lebih rendah menyimpan lebih banyak data/kod dalam memori.

Nilai yang lebih rendah ialah pertaruhan yang baik untuk prestasi yang lebih baik dalam PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

Aplikasi memperoleh memori dan melepaskannya apabila ia tidak diperlukan lagi. Tetapi dalam beberapa kes, aplikasi mendapat terlalu banyak memori dan tidak melepaskannya. Ini boleh menyebabkan pembunuh OOM. Berikut ialah nilai parameter yang mungkin vm.overcommit_memory dengan penerangan untuk setiap:

  1. Heuristik terlebih komitmen (lalai); heuristik berasaskan kernel
  2. Biarkan terlalu komited
  3. Jangan keterlaluan, jangan melebihi nisbah overcommit.

Бсылка: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio β€” peratusan RAM tersedia untuk beban berlebihan. Nilai 50% pada sistem dengan 2 GB RAM boleh memperuntukkan sehingga 3 GB RAM.

Nilai 2 untuk vm.overcommit_memory memberikan prestasi yang lebih baik untuk PostgreSQL. Nilai ini memaksimumkan penggunaan RAM proses pelayan tanpa sebarang risiko besar untuk dibunuh oleh proses pembunuh OOM. Aplikasi akan dapat memuat semula, tetapi hanya dalam had overrun, yang mengurangkan risiko pembunuh OOM membunuh proses. Oleh itu, nilai 2 memberikan prestasi yang lebih baik daripada nilai lalai 0. Walau bagaimanapun, kebolehpercayaan boleh dipertingkatkan dengan memastikan bahawa memori di luar julat tidak dibebankan. Ini menghapuskan risiko proses dibunuh oleh pembunuh OOM.

Pada sistem tanpa pertukaran, masalah dengan vm.overcommit_memory bersamaan dengan 2 mungkin berlaku.

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

vm.dirty_background_ratio / vm.dirty_background_bait

vm.nisbah_latar_kotor ialah peratusan memori yang diisi dengan halaman kotor yang perlu ditulis ke cakera. Siram ke cakera berlaku di latar belakang. Nilai parameter ini berkisar antara 0 hingga 100; namun, nilai di bawah 5 mungkin tidak berkesan dan sesetengah kernel tidak menyokongnya. 10 ialah lalai pada kebanyakan sistem Linux. Anda boleh meningkatkan prestasi untuk operasi intensif tulis dengan faktor yang lebih kecil, yang bermakna Linux akan membuang halaman kotor di latar belakang.

Anda perlu menetapkan nilai vm.dirty_background_bait bergantung pada kelajuan pemanduan anda.

Tiada nilai "baik" untuk kedua-dua parameter ini kerana kedua-duanya bergantung kepada perkakasan. Walau bagaimanapun, menetapkan vm.dirty_background_ratio kepada 5 dan vm.dirty_background_bytes kepada 25% kelajuan cakera meningkatkan prestasi kepada ~25% dalam kebanyakan kes.

vm.dirty_ratio/dirty_bait

Ia sama seperti vm.dirty_background_ratio/dirty_background_bait, kecuali tetapan semula dilakukan dalam sesi pekerja, menyekat aplikasi. Oleh itu vm.dirty_ratio sepatutnya lebih tinggi daripada vm.nisbah_latar_kotor. Ini memastikan proses latar belakang bermula lebih awal untuk mengelak daripada menyekat aplikasi sebanyak mungkin. Anda boleh melaraskan perbezaan antara kedua-dua nisbah ini bergantung pada beban I/O cakera.

Jumlah

Anda boleh tweak tetapan lain untuk meningkatkan prestasi, tetapi penambahbaikan akan menjadi minimum dan anda tidak akan melihat banyak manfaat. Kita mesti ingat bahawa tidak semua pilihan digunakan untuk semua jenis aplikasi. Sesetengah apl berfungsi lebih baik apabila kami melaraskan beberapa tetapan, dan ada yang tidak. Anda mesti mencari keseimbangan yang betul antara mengkonfigurasi tetapan ini untuk beban kerja yang dijangkakan dan jenis aplikasi anda, dan anda juga mesti mempertimbangkan tingkah laku OS semasa menala. Mengkonfigurasi parameter kernel tidak semudah mengkonfigurasi parameter pangkalan data; lebih sukar untuk membuat cadangan.

Sumber: www.habr.com

Tambah komen