
Kinerja optimal PostgreSQL tergantung pada parameter sistem operasi yang ditetapkan dengan benar. Parameter kernel OS yang disetel dengan buruk dapat menurunkan kinerja server database. Oleh karena itu, sangat penting bahwa parameter ini dikonfigurasi sesuai dengan server database dan beban kerjanya. Dalam posting ini, kita akan membahas beberapa parameter kernel Linux penting yang dapat mempengaruhi kinerja server database dan cara menyetelnya.
SHMMAX / SHMALL
SHMMAX adalah parameter kernel yang digunakan untuk menentukan ukuran maksimum dari satu segmen memori bersama yang dapat dialokasikan oleh proses Linux. Sebelum versi 9.2, PostgreSQL menggunakan System V (SysV), yang membutuhkan konfigurasi SHMMAX. Setelah 9.2, PostgreSQL beralih ke memori bersama POSIX. Jadi sekarang diperlukan lebih sedikit byte memori bersama System V.
Sebelum versi 9.3, SHMMAX adalah parameter kernel yang paling penting. Nilai SHMMAX ditentukan dalam byte.
Demikian pula,
SHMALL adalah parameter kernel lain yang digunakan untuk menentukan
halaman memori bersama di seluruh sistem. Gunakan perintah
ipcs untuk melihat nilai SHMMAX, SHMALL, atau SHMMIN saat ini.
SHM * Detail - 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 * Detail - 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
System V IPC untuk mengalokasikan memori bersama. Parameter ini adalah salah satu parameter kernel yang paling penting. Setiap kali Anda menerima pesan kesalahan berikut, itu berarti Anda memiliki versi PostgreSQL yang lebih lama dan Anda memiliki nilai SHMMAX yang sangat rendah. Diharapkan bahwa pengguna akan menyesuaikan dan meningkatkan nilai sesuai dengan memori bersama yang akan mereka gunakan.
Kemungkinan kesalahan konfigurasi
Jika SHMMAX tidak dikonfigurasi dengan benar, Anda mungkin menerima kesalahan ketika mencoba untuk menginisialisasi cluster PostgreSQL menggunakan perintah
initdb .
kegagalan initdbDETAIL: 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
Demikian pula, Anda mungkin menerima kesalahan saat memulai server PostgreSQL menggunakan perintah
pg_ctl .
kegagalan pg_ctlDETAIL: 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 Perbedaan dalam Definisi
Definisi parameter SHMMAX / SHMALL sedikit berbeda di Linux dan MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Perintah
sysctl dapat digunakan untuk sementara mengubah nilai. Untuk menetapkan nilai konstan, tambahkan entri di
/etc/sysctl.conf . Detail diberikan di bawah ini.
Ubah pengaturan 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
Mengubah parameter kernel 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
Ingat : untuk membuat perubahan permanen, tambahkan nilai-nilai ini ke /etc/sysctl.confHalaman Besar (Halaman Besar)
Linux default ke halaman 4K, BSD menggunakan
Super Pages , dan Windows menggunakan
Halaman Besar . Halaman adalah sepotong RAM yang dialokasikan untuk suatu proses. Suatu proses dapat memiliki beberapa halaman, tergantung pada kebutuhan memori. Semakin banyak memori yang dibutuhkan suatu proses, semakin banyak halaman yang telah dialokasikan. OS mendukung tabel alokasi halaman untuk proses. Semakin kecil ukuran halaman, semakin besar tabel, semakin lama waktu yang dibutuhkan untuk menemukan halaman di tabel halaman ini. Oleh karena itu, halaman yang besar memungkinkan Anda untuk menggunakan sejumlah besar memori dengan overhead yang berkurang; lebih sedikit tampilan halaman, lebih sedikit kesalahan halaman, operasi baca / tulis lebih cepat melalui buffer besar. Hasilnya adalah peningkatan kinerja.
PostgreSQL hanya mendukung halaman besar di Linux. Secara default, Linux menggunakan 4 KB halaman memori, jadi jika Anda memiliki terlalu banyak operasi memori, Anda harus menginstal halaman yang lebih besar. Ada peningkatan kinerja saat menggunakan halaman besar 2 MB dan hingga 1 GB. Ukuran halaman besar dapat diatur saat boot. Anda dapat dengan mudah memeriksa parameter halaman besar dan penggunaannya di komputer Linux Anda menggunakan perintah
cat / proc / meminfo | grep -sangat besar .
Mendapatkan informasi tentang halaman besar (hanya 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
Dalam contoh ini, meskipun ukuran halaman besar diatur ke 2048 (2 MB), jumlah total halaman besar adalah 0. Ini berarti bahwa halaman besar dinonaktifkan.
Script untuk menentukan jumlah halaman besar
Skrip sederhana ini mengembalikan jumlah halaman besar yang diperlukan. Jalankan skrip di server Linux Anda saat PostgreSQL berjalan. Pastikan direktori data PostgreSQL disetel untuk variabel lingkungan
$ PGDATA .
Mendapatkan jumlah halaman besar yang dibutuhkan
Output skrip adalah sebagai berikut:
Output skrip Pid: 12737 VmPeak: 180932 kB Hugepagesize: 2048 kB Set Huge Pages: 88
Nilai yang disarankan untuk halaman besar adalah 88, jadi Anda harus mengaturnya ke 88.
Pasang halaman besar sysctl -w vm.nr_hugepages=88
Periksa halaman besar sekarang, Anda akan melihat bahwa halaman besar tidak digunakan (HugePages_Free = HugePages_Total).
Informasi tentang halaman besar lagi (hanya 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
Sekarang atur huge_pages βonβ ke $ PGDATA / postgresql.conf dan restart server.
Dan lagi, informasi tentang halaman besar (hanya 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
Sekarang Anda dapat melihat bahwa sangat sedikit halaman besar yang digunakan. Sekarang mari kita coba menambahkan beberapa data ke database.
Beberapa operasi basis data untuk mendaur ulang halaman besar postgres=
Mari kita lihat apakah kita menggunakan halaman yang lebih besar sekarang daripada sebelumnya.
Sekali lagi informasi pada halaman besar (hanya 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
Sekarang Anda dapat melihat bahwa sebagian besar halaman besar sedang digunakan.
Catatan: nilai perkiraan untuk HugePages yang digunakan di sini sangat rendah, yang bukan merupakan nilai normal untuk mesin di lingkungan makanan. Harap evaluasi jumlah halaman yang dibutuhkan untuk sistem Anda dan atur sesuai dengan itu tergantung pada beban dan sumber daya.vm. kebahagiaan
vm.swappiness adalah parameter kernel lain yang dapat mempengaruhi kinerja database. Parameter ini digunakan untuk mengontrol perilaku swappiness (menukar halaman ke dan dari memori) di Linux. Nilainya berkisar dari 0 hingga 100. Ini menentukan berapa banyak memori yang akan dibongkar atau dibongkar. Nol berarti menonaktifkan pertukaran, dan 100 berarti pertukaran agresif.
Anda bisa mendapatkan kinerja yang baik dengan menetapkan nilai yang lebih rendah.
Menyetel nilai ke 0 di kernel yang lebih baru dapat menyebabkan OOM Killer (proses pembersihan memori Linux) mematikan proses. Dengan demikian, Anda dapat dengan aman mengatur nilai ke 1 jika Anda ingin meminimalkan swapping. Nilai default di Linux adalah 60. Nilai yang lebih tinggi menyebabkan MMU (unit manajemen memori) menggunakan lebih banyak ruang paging daripada RAM, sementara nilai yang lebih rendah menyimpan lebih banyak data / kode dalam memori.
Nilai yang lebih rendah adalah taruhan yang bagus untuk meningkatkan kinerja di PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Aplikasi menerima memori dan membebaskannya ketika tidak lagi diperlukan. Tetapi dalam beberapa kasus, aplikasi mendapat terlalu banyak memori dan tidak membebaskannya. Ini dapat menyebabkan pembunuh OOM. Berikut adalah nilai yang mungkin untuk parameter
vm.overcommit_memory dengan deskripsi untuk masing-masing:
- Heuristic overcommit (default); heuristik berbasis inti
- Biarkan overcommit
- Jangan berlebihan, jangan melebihi rasio kelebihan komitmen.
Tautan: https://www.kernel.org/doc/Documentation/vm/overcommit-accountingvm.overcommit_ratio - persentase RAM yang tersedia untuk overloading. Nilai 50% dalam sistem dengan 2 GB RAM dapat mengalokasikan hingga 3 GB RAM.
Nilai 2 untuk vm.overcommit_memory memberikan kinerja yang lebih baik untuk PostgreSQL. Nilai ini memaksimalkan penggunaan RAM oleh proses server tanpa risiko signifikan terbunuh oleh proses pembunuh OOM. Aplikasi akan dapat memulai kembali, tetapi hanya dalam pengeluaran berlebih, yang mengurangi risiko bahwa pembunuh OOM akan membunuh proses. Oleh karena itu, nilai 2 memberikan kinerja yang lebih baik daripada nilai standar 0. Namun, keandalan dapat ditingkatkan dengan memastikan bahwa memori di luar rentang yang dapat diterima tidak kelebihan beban. Ini menghilangkan risiko bahwa proses tersebut akan dibunuh oleh pembunuh-OOM.
Pada sistem non-paging, masalah dapat terjadi dengan vm.overcommit_memory sama dengan 2.
https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMITvm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio adalah persentase memori yang diisi dengan halaman kotor yang perlu ditulis ke disk. Atur ulang ke disk di latar belakang. Nilai parameter ini berkisar dari 0 hingga 100; Namun, nilai di bawah 5 mungkin tidak efisien, dan beberapa kernel tidak mendukungnya. 10 adalah nilai default pada kebanyakan sistem Linux. Anda dapat meningkatkan kinerja untuk operasi perekaman intensif pada tingkat yang lebih rendah, yang berarti bahwa Linux akan membuang halaman kotor di latar belakang.
Anda perlu mengatur nilai
vm.dirty_background_bytes tergantung pada kecepatan disk Anda.
Tidak ada nilai "baik" untuk dua parameter ini, karena keduanya bergantung pada perangkat keras. Namun, pengaturan vm.dirty_background_ratio ke 5 dan vm.dirty_background_bytes pada 25% dari kecepatan disk akan meningkatkan kinerja hingga ~ 25% dalam kebanyakan kasus.
vm.dirty_ratio / dirty_bytes
Ini sama dengan
vm.dirty_background_ratio / dirty_background_bytes , kecuali bahwa pengaturan ulang dilakukan dalam sesi kerja, memblokir aplikasi. Karena itu, vm.dirty_ratio harus lebih tinggi dari
vm.dirty_background_ratio . Ini memastikan bahwa proses latar belakang akan dimulai lebih awal untuk menghindari pemblokiran aplikasi sebanyak mungkin. Anda dapat menyesuaikan perbedaan antara dua rasio ini tergantung pada beban I / O disk.
Ringkasan
Anda dapat mengonfigurasi parameter lain untuk meningkatkan produktivitas, tetapi peningkatannya akan minimal dan Anda tidak akan mendapatkan banyak manfaat. Kita harus ingat bahwa tidak semua parameter berlaku untuk semua jenis aplikasi. Beberapa aplikasi bekerja lebih baik ketika kita mengkonfigurasi beberapa pengaturan, dan beberapa tidak. Anda harus menemukan keseimbangan yang tepat antara konfigurasi parameter-parameter ini untuk beban kerja yang diharapkan dan jenis aplikasi, dan ketika mengatur, Anda harus mempertimbangkan perilaku OS. Mengkonfigurasi parameter kernel tidak semudah menyetel parameter basis data: lebih sulit untuk memberikan rekomendasi Anda di sini.