Pada kinerja pglogical

Beberapa hari yang lalu kami merilis pglogical, solusi replikasi logis sumber terbuka sepenuhnya untuk PostgreSQL, yang diharapkan akan dimasukkan ke dalam pohon PostgreSQL dalam waktu yang tidak terlalu lama. Saya tidak akan membahas semua hal yang dimungkinkan oleh replikasi logis – pengumuman rilis pglogical menyajikan gambaran yang cukup baik, dan Simon juga menjelaskan secara singkat keuntungan dari replikasi logis di posting lain beberapa hari yang lalu.

Sebaliknya saya ingin berbicara tentang satu aspek tertentu yang disebutkan dalam pengumuman – perbandingan kinerja dengan solusi yang ada. Halaman pglogical menyebutkan

Tolok ukur

Posting ini menjelaskan detail tolok ukur yang kami lakukan untuk menemukan throughput "berkelanjutan" maksimum (transaksi per detik) yang dapat ditangani oleh masing-masing solusi tanpa tertinggal. Untuk melakukan itu, saya telah menjalankan sejumlah tes pgbench pada sepasang instans AWS i2.4xlarge dengan jumlah klien yang bervariasi, dan mengukur throughput pada master dan berapa lama waktu yang dibutuhkan siaga untuk mengejar (jika tertinggal) . Hasilnya kemudian digunakan untuk menghitung perkiraan throughput maksimum pada node siaga.

Sebagai contoh, katakanlah kami telah menjalankan pgbench dengan 16 klien selama 30 menit, dan kami telah mengukur 10.000 tps pada master, tetapi standbynya tertinggal dan membutuhkan waktu 15 menit untuk mengejar ketinggalan. Maka estimasi throughput berkelanjutan maksimum adalah

tps =(transaksi dieksekusi) / (total runtime sampai standby tercapai)

yaitu

tps =(30 60 10.000) / (45 * 60) =18.000.000 / 2.700 =6.666

Jadi dalam hal itu throughput berkelanjutan maksimum pada standby adalah 6.666 tps, yaitu hanya ~66% dari tingkat transaksi yang diukur pada master.

Sistem

Tolok ukur dilakukan pada sepasang instans AWS i2.4xlarge, dikonfigurasi dalam grup penempatan yang sama (jadi dengan koneksi jaringan ~2Gbit di antara keduanya), dan drive SSD 4x yang dikonfigurasi dalam RAID-0 (jadi I/O tidak mungkin menjadi masalah di sini). Instans memiliki ~122GB RAM, sehingga kumpulan data (pgbench dengan skala 5000) cocok dengan RAM. Semua pengujian dilakukan pada PostgreSQL 9.5.0 dengan konfigurasi yang sama persis:

checkpoint_timeout = 15min
effective_io_concurrency = 32
maintenance_work_mem = 1GB
max_wal_size = 8GB
min_wal_size = 2GB
shared_buffers = 16GB

Untuk semua sistem replikasi, versi terbaru yang tersedia digunakan, khususnya

• slony1 2.2.4
• skytools 3.2

dan replikasi sederhana telah diatur seperti yang dijelaskan dalam tutorial (keduanya menggunakan contoh pgbench yang digunakan untuk benchmark).

Hasil

Hasil yang disajikan selanjutnya juga mencakup replikasi streaming (mode asinkron) untuk memberi Anda gambaran yang lebih baik tentang overhead yang terkait dengan replikasi logis. Tarif transaksi bukanlah angka "mentah" yang diukur oleh pgbench, tetapi tarif "berkelanjutan" yang dihitung menggunakan rumus yang disajikan di awal posting ini.