Mendorong Performa untuk PostgreSQL dengan HAProxy

Kinerja basis data merupakan perhatian yang sangat penting saat memelihara klaster basis data Anda, terutama seiring pertumbuhannya dari waktu ke waktu. Ini terutama benar jika aplikasi Anda dimulai dengan lalu lintas rendah kemudian berkembang menjadi beban kerja baca-tulis yang sedang atau berat.

Yang perlu diingat adalah tidak ada konfigurasi sempurna yang dapat Anda andalkan untuk waktu yang lama, karena beban kerja tertentu dapat berubah seiring waktu.

Dengan ClusterControl, membuat atau menerapkan cluster database PostgreSQL baru melakukan analisis dasar seperti memeriksa sumber daya perangkat keras Anda, kemudian menerapkan penyetelan otomatis dan menetapkan nilai untuk parameter yang dapat disesuaikan yang dipilih. Seiring berkembangnya PostgreSQL, banyak alat telah dikembangkan juga untuk mendukung konfigurasi yang berbeda, terutama untuk penyeimbangan beban.

Di blog ini, kita akan melihat pentingnya HAProxy dan bagaimana hal itu dapat membantu mendorong kinerja. Ini adalah alat lama, namun proxy kuat dan/atau penyeimbang beban yang mendukung tidak hanya server basis data, tetapi juga protokol khusus aplikasi jaringan. HAProxy dapat beroperasi melalui lapisan empat dan lapisan tujuh masing-masing, tergantung pada jenis pengaturan berdasarkan konfigurasi.

Penyesuaian Kinerja PostgreSQL

Salah satu faktor utama untuk mendorong kinerja PostgreSQL dimulai dengan penyetelan parameter dasar dari initdb ke nilai parameter runtime. Ini harus mampu menangani beban kerja yang diinginkan sesuai dengan kebutuhan tertentu Anda. Sebelum kita dapat mengambil rute untuk fitur HAProxy untuk PostgreSQL, server database Anda harus stabil dan disesuaikan dengan variabel yang diinginkan. Mari kita lihat daftar area untuk PostgreSQL tentang hal-hal apa saja yang dapat memengaruhi kinerja drive untuk server database Anda.

Menyetel Untuk Manajemen Memori yang Layak

PostgreSQL efisien dan dapat dijalankan secara efektif hanya dalam memori 256Mb. Memori tidak mahal, namun sebagian besar set data kurang dari 4Gib. Jika Anda memiliki setidaknya 4Gib, kumpulan data aktif Anda dapat tetap berada di file dan/atau cache buffer_bersama.

Menyetel PostgreSQL untuk manajemen memori adalah salah satu hal paling utama dan mendasar yang perlu Anda atur. Mengaturnya dengan tepat dapat berdampak pada peningkatan kinerja server database Anda. Meskipun itu tergantung pada jenis meja yang Anda mainkan. Kueri yang buruk dan definisi tabel yang buruk juga dapat menyebabkan kinerja yang buruk. Dengan indeks yang tepat yang ditetapkan ke tabel Anda dan dengan kueri yang merujuk ke indeks, peluangnya dapat mencapai 80% - 100% kueri dapat diambil dari memori Anda. Ini terutama jika buffer indeks memiliki nilai yang tepat untuk memuat indeks Anda yang ditentukan pada tabel Anda. Mari kita lihat parameter yang biasanya ditetapkan untuk peningkatan kinerja.

shared_buffers - PostgreSQL mengukur ruang memori utamanya dengan shared_buffers. Cache yang berfungsi dari semua hot tuple (dan entri indeks) dalam PostgreSQL. Parameter ini menetapkan jumlah memori yang digunakan server database untuk buffer memori bersama. Ini adalah cache yang telah dialokasikan sebelumnya (buffer). Untuk sistem berbasis Linux, sangat ideal untuk menyetel parameter kernel kernel.shmmax yang dapat disetel terus-menerus melalui file konfigurasi kernel /etc/sysctl.conf.
temp_buffers - Menetapkan jumlah maksimum buffer sementara yang digunakan untuk setiap sesi. Ini adalah buffer sesi lokal yang digunakan hanya untuk mengakses tabel sementara. Sesi akan menetapkan buffer sementara sesuai kebutuhan hingga batas yang diberikan oleh temp_buffers.
work_mem - Memori kerja yang tersedia untuk operasi kerja (semacam) sebelum PostgreSQL akan bertukar. Jangan atur secara global (postgresql.conf). Gunakan per transaksi karena ini bisa buruk per kueri, per koneksi, atau per sortir. Menggunakan EXPLAIN ANALYZE disarankan untuk melihat apakah Anda overflow atau tidak.
maintenance_work_mem - Menentukan jumlah memori yang akan digunakan untuk operasi pemeliharaan (VACUUM, CREATE INDEX, dan ALTER TABLE … ADD FOREIGN KEY…)

Menyetel Untuk Manajemen Disk yang Layak

Sejumlah parameter runtime untuk disetel di sini. Mari kita daftar apa saja ini:

temp_file_limit - Menentukan jumlah maksimum ruang disk yang dapat digunakan sesi untuk file sementara, seperti mengurutkan dan meng-hash file sementara, atau file penyimpanan untuk kursor yang ditahan. Transaksi yang mencoba melampaui batas ini akan dibatalkan.
fsync - Jika fsync diaktifkan, PostgreSQL akan mencoba memastikan bahwa pembaruan secara fisik ditulis ke disk. Ini memastikan bahwa cluster database dapat dipulihkan ke keadaan yang konsisten setelah sistem operasi atau perangkat keras crash. Meskipun menonaktifkan fsync umumnya meningkatkan kinerja, ini dapat menyebabkan hilangnya data jika terjadi kegagalan daya atau sistem crash. Oleh karena itu, sebaiknya nonaktifkan fsync jika Anda dapat dengan mudah membuat ulang seluruh basis data dari data eksternal
synchronous_commit - Digunakan untuk menegakkan bahwa komit akan menunggu WAL ditulis pada disk sebelum mengembalikan status sukses ke klien. Variabel ini memiliki trade-off antara kinerja dan keandalan. Jika Anda membutuhkan lebih banyak kinerja, matikan ini yang berarti ketika server mogok, kecenderungan untuk mengalami kehilangan data. Jika tidak, jika keandalan penting, aktifkan ini. Artinya, akan ada jeda waktu antara status sukses dan jaminan penulisan ke disk, sehingga dapat memengaruhi kinerja.
checkpoint_timeout, checkpoint_completion_target - PostgreSQL menulis perubahan ke dalam WAL, yang merupakan operasi yang mahal. Jika sering menulis perubahan ke WAL, itu dapat berdampak buruk pada kinerja. Jadi cara kerjanya, proses checkpoint mem-flush data ke dalam file data. Aktivitas ini dilakukan saat CHECKPOINT terjadi dan dapat menyebabkan IO dalam jumlah besar. Seluruh proses ini melibatkan operasi baca/tulis disk yang mahal. Meskipun Anda (pengguna admin) selalu dapat mengeluarkan CHECKPOINT kapan pun diperlukan atau mengotomatiskannya dengan menetapkan nilai yang diinginkan untuk parameter ini. Parameter checkpoint_timeout digunakan untuk mengatur waktu antara pos pemeriksaan WAL. Menyetel ini terlalu rendah akan mengurangi waktu pemulihan kerusakan, karena lebih banyak data yang ditulis ke disk, tetapi juga merusak kinerja karena setiap pos pemeriksaan akhirnya menghabiskan sumber daya sistem yang berharga. Checkpoint_completion_target adalah fraksi waktu antara checkpoint untuk penyelesaian checkpoint. Frekuensi pos pemeriksaan yang tinggi dapat memengaruhi kinerja. Untuk pemeriksaan yang lancar, checkpoint_timeout harus bernilai rendah. Jika tidak, OS akan mengakumulasi semua halaman kotor sampai rasio terpenuhi dan kemudian menghasilkan flush besar.

Menyetel Parameter Lain untuk Performa

Ada parameter tertentu yang memberikan dorongan dan dorongan untuk kinerja di PostgreSQL. Mari kita daftar apa saja di bawah ini:

wal_buffers - PostgreSQL menulis catatan WAL (write forward log) ke dalam buffer dan kemudian buffer ini di-flush ke disk. Ukuran default buffer, yang ditentukan oleh wal_buffers, adalah 16 MB, tetapi jika Anda memiliki banyak koneksi bersamaan, nilai yang lebih tinggi dapat memberikan kinerja yang lebih baik.
efektif_cache_size - The effective_cache_size memberikan perkiraan memori yang tersedia untuk caching disk. Ini hanya panduan, bukan alokasi memori atau ukuran cache yang tepat. Itu tidak mengalokasikan memori aktual tetapi memberi tahu pengoptimal jumlah cache yang tersedia di kernel. Jika nilai ini disetel terlalu rendah, perencana kueri dapat memutuskan untuk tidak menggunakan beberapa indeks, bahkan jika itu akan membantu. Oleh karena itu, menetapkan nilai yang besar selalu bermanfaat.
default_statistics_target - PostgreSQL mengumpulkan statistik dari masing-masing tabel dalam databasenya untuk memutuskan bagaimana kueri akan dieksekusi pada tabel tersebut. Secara default, tidak mengumpulkan terlalu banyak informasi, dan jika Anda tidak mendapatkan rencana eksekusi yang baik, Anda harus meningkatkan nilai ini dan kemudian menjalankan ANALYZE dalam database lagi (atau menunggu AUTOVACUUM).

Efisiensi Kueri PostgreSQL

PostgreSQL memiliki fitur yang sangat kuat untuk mengoptimalkan kueri. Dengan Pengoptimal Kueri Genetik bawaan (dikenal sebagai GEQO). Ini menggunakan algoritma genetika yang merupakan metode optimasi heuristik melalui pencarian acak. Ini diterapkan saat melakukan optimasi menggunakan JOINs yang memberikan optimasi kinerja yang sangat baik. Setiap kandidat dalam rencana bergabung diwakili oleh urutan untuk bergabung dengan hubungan dasar. Ini secara acak melakukan hubungan genetik dengan hanya menghasilkan beberapa urutan bergabung yang mungkin tetapi secara acak.

Untuk setiap urutan gabungan yang dipertimbangkan, kode perencana standar dipanggil untuk memperkirakan biaya pelaksanaan kueri menggunakan urutan gabungan tersebut. Jadi untuk setiap urutan JOIN, semua memiliki rencana pemindaian relasi yang ditentukan sebelumnya. Kemudian, rencana kueri akan menghitung rencana yang paling layak dan berkinerja, yaitu dengan perkiraan biaya yang lebih rendah dan dianggap "lebih cocok" daripada rencana dengan biaya yang lebih tinggi.

Mengingat ia memiliki fitur canggih yang terintegrasi dalam PostgreSQL dan parameter yang dikonfigurasi dengan benar sesuai dengan persyaratan yang Anda inginkan, itu tidak mengalahkan kelayakan dalam hal kinerja jika beban hanya dilemparkan ke simpul utama. Penyeimbangan beban dengan HAProxy membantu lebih banyak lagi mendorong kinerja untuk PostgreSQL.

Mendorong Performa untuk PostgreSQL Dengan Pemisahan Baca-Tulis

Anda mungkin memiliki kinerja yang hebat dalam menangani node server PostgreSQL, tetapi Anda mungkin tidak dapat mengantisipasi jenis beban kerja apa yang mungkin Anda miliki terutama ketika lalu lintas tinggi mencapai dan permintaan melampaui batas. Menyeimbangkan beban antara primer dan sekunder memberikan peningkatan kinerja dalam aplikasi Anda dan/atau klien yang terhubung ke cluster database PostgreSQL Anda. Bagaimana hal ini dapat dilakukan, bukanlah pertanyaan lagi karena ini adalah pengaturan yang sangat umum untuk ketersediaan tinggi dan redundansi dalam hal mendistribusikan beban dan menghindari node utama macet karena pemrosesan beban tinggi.

Menyiapkan dengan HAProxy itu mudah. Namun, ini lebih efisien lebih cepat dan layak dengan ClusterControl. Jadi kita akan menggunakan ClusterControl untuk menyiapkan ini untuk kita.

Menyiapkan PostgreSQL dengan HAProxy

Untuk melakukan ini, kita hanya perlu menginstal dan menyiapkan HAProxy di atas cluster PostgreSQL. HAProxy memiliki fitur untuk mendukung PostgreSQL melalui opsi pgsql-check tetapi dukungannya adalah implementasi yang sangat sederhana untuk menentukan apakah sebuah node aktif atau tidak. Itu tidak memiliki pemeriksaan untuk mengidentifikasi node primer dan pemulihan. Pilihannya adalah menggunakan xinetd yang mana kami akan mengandalkan komunikasi HAProxy untuk mendengarkan melalui layanan xinetd kami yang memeriksa kesehatan node tertentu di cluster PostgreSQL kami.

Di bawah ClusterControl, navigasikan ke Manage → Load Balancer seperti di bawah ini,

Kemudian ikuti saja berdasarkan UI per tangkapan layar di bawah ini. Anda dapat mengklik Tampilkan pengaturan lanjutan untuk melihat opsi lanjutan lainnya. Mengikuti UI sangat mudah. Lihat di bawah,

Saya hanya mengimpor satu node HAProxy tanpa redundansi tetapi untuk tujuan blog ini, mari kita buat lebih sederhana.

Contoh tampilan HAProxy saya ditampilkan di bawah,

Seperti yang ditunjukkan di atas, 192.168.30.20 dan 192.168.30.30 adalah yang utama dan node sekunder/pemulihan masing-masing. Sedangkan HAProxy dipasang di node sekunder/pemulihan. Idealnya, Anda dapat menginstal HAProxy Anda pada beberapa node untuk memiliki lebih banyak redundansi dan sangat tersedia, yang terbaik adalah mengisolasinya terhadap node database. Jika Anda memiliki anggaran terbatas atau menghemat penggunaan Anda, Anda dapat memilih untuk menginstal node HAProxy Anda, di mana node database Anda juga diinstal.

ClusterControl mengatur ini secara otomatis dan juga menyertakan layanan xinetd untuk pemeriksaan PostgreSQL. Ini dapat diverifikasi dengan netstat seperti di bawah ini,

[email protected]:~# netstat -tlv4np|grep haproxy

tcp        0      0 0.0.0.0:5433            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:5434            0.0.0.0:*               LISTEN      28441/haproxy

tcp        0      0 0.0.0.0:9600            0.0.0.0:*               LISTEN      28441/haproxy

Sedangkan port 5433 adalah read-write dan 5444 adalah read-only.

Untuk PostgreSQL periksa layanan xinetd yaitu postgreshk seperti yang terlihat di bawah ini,

[email protected]:~# cat /etc/xinetd.d/postgreschk

# default: on

# description: postgreschk

service postgreschk

{

        flags           = REUSE

        socket_type     = stream

        port            = 9201

        wait            = no

        user            = root

        server          = /usr/local/sbin/postgreschk

        log_on_failure  += USERID

        disable         = no

        #only_from       = 0.0.0.0/0

        only_from       = 0.0.0.0/0

        per_source      = UNLIMITED

}

Layanan xinetd juga bergantung pada /etc/services sehingga Anda mungkin dapat menemukan port yang ditunjuk untuk dipetakan.

[email protected]:~# grep postgreschk /etc/services

postgreschk        9201/tcp

Jika Anda perlu mengubah port postgreschk Anda ke port apa yang akan dipetakan, Anda harus mengubah file ini juga selain dari file konfigurasi layanan dan kemudian jangan lupa untuk me-restart xinetd daemon.

Layanan postgreschk berisi referensi ke file eksternal yang pada dasarnya memeriksa node apakah dapat ditulis, artinya itu adalah file utama atau master. Jika sebuah node dalam pemulihan, maka itu adalah replika atau node pemulihan.

[email protected]:~# cat /usr/local/sbin/postgreschk

#!/bin/bash

#

# This script checks if a PostgreSQL server is healthy running on localhost. It will

# return:

# "HTTP/1.x 200 OK\r" (if postgres is running smoothly)

# - OR -

# "HTTP/1.x 500 Internal Server Error\r" (else)

#

# The purpose of this script is make haproxy capable of monitoring PostgreSQL properly

#



export PGHOST='localhost'

export PGUSER='s9smysqlchk'

export PGPASSWORD='password'

export PGPORT='7653'

export PGDATABASE='postgres'

export PGCONNECT_TIMEOUT=10



FORCE_FAIL="/dev/shm/proxyoff"



SLAVE_CHECK="SELECT pg_is_in_recovery()"

WRITABLE_CHECK="SHOW transaction_read_only"



return_ok()

{

    echo -e "HTTP/1.1 200 OK\r\n"

    echo -e "Content-Type: text/html\r\n"

    if [ "$1x" == "masterx" ]; then

        echo -e "Content-Length: 56\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL master is running.</body></html>\r\n"

    elif [ "$1x" == "slavex" ]; then

        echo -e "Content-Length: 55\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL slave is running.</body></html>\r\n"

    else

        echo -e "Content-Length: 49\r\n"

        echo -e "\r\n"

        echo -e "<html><body>PostgreSQL is running.</body></html>\r\n"

    fi

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 0

}



return_fail()

{

    echo -e "HTTP/1.1 503 Service Unavailable\r\n"

    echo -e "Content-Type: text/html\r\n"

    echo -e "Content-Length: 48\r\n"

    echo -e "\r\n"

    echo -e "<html><body>PostgreSQL is *down*.</body></html>\r\n"

    echo -e "\r\n"



    unset PGUSER

    unset PGPASSWORD

    exit 1

}



if [ -f "$FORCE_FAIL" ]; then

    return_fail;

fi



# check if in recovery mode (that means it is a 'slave')

SLAVE=$(psql -qt -c "$SLAVE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $SLAVE | egrep -i "(t|true|on|1)" 2>/dev/null >/dev/null; then

    return_ok "slave"

fi



# check if writable (then we consider it as a 'master')

READONLY=$(psql -qt -c "$WRITABLE_CHECK" 2>/dev/null)

if [ $? -ne 0 ]; then

    return_fail;

elif echo $READONLY | egrep -i "(f|false|off|0)" 2>/dev/null >/dev/null; then

    return_ok "master"

fi



return_ok "none";

Kombinasi pengguna/sandi harus berupa PERAN yang valid di server PostgreSQL Anda. Karena kami menginstal melalui ClusterControl, ini ditangani secara otomatis.

Sekarang kita memiliki instalasi HAProxy yang lengkap, pengaturan ini memungkinkan kita untuk memiliki pemisahan baca-tulis di mana baca-tulis pergi ke node utama atau dapat ditulis, sedangkan hanya-baca untuk primer dan sekunder/ node pemulihan. Penyiapan ini tidak berarti performanya sudah bagus, tetapi masih disetel seperti yang dibahas sebelumnya dengan kombinasi HAProxy untuk penyeimbangan beban menambahkan lebih banyak peningkatan kinerja untuk aplikasi Anda dan klien basis data masing-masing.