Tujuan benchmarking database tidak hanya untuk memeriksa kemampuan database, tetapi juga perilaku database tertentu terhadap aplikasi Anda. Perangkat keras yang berbeda memberikan hasil yang berbeda berdasarkan rencana pembandingan yang Anda tetapkan. Sangat penting untuk mengisolasi server (yang sebenarnya sedang di-benchmark) dari elemen lain seperti server yang mendorong beban, atau server yang digunakan untuk mengumpulkan dan menyimpan metrik kinerja. Sebagai bagian dari latihan benchmarking, Anda harus mendapatkan karakteristik aplikasi seperti a) Apakah aplikasi tersebut intensif membaca atau menulis? atau b) apa yang dimaksud dengan pembagian baca/tulis (mis. 80:20)? atau c) Seberapa besar dataset?, apakah data dan struktur mewakili database produksi yang sebenarnya, dll.
PostgreSQL adalah database open source tercanggih di dunia. Jika ada pelanggan RDBMS perusahaan yang ingin memigrasikan database mereka ke opensource, maka PostgreSQL akan menjadi opsi pertama untuk dievaluasi.
Postingan ini mencakup hal-hal berikut:
- Cara membuat tolok ukur PostgreSQL
- Apa faktor kinerja utama di PostgreSQL
- Pengungkit apa yang dapat Anda tarik untuk meningkatkan kinerja
- Apa jebakan performa yang harus dihindari
- Apa kesalahan umum yang dilakukan orang?
- Bagaimana Anda mengetahui kinerja sistem Anda? Alat apa yang dapat Anda gunakan?
Cara Membandingkan PostgreSQL
Alat standar untuk membandingkan PostgreSQL adalah pgbench. Secara default, tes pgbench didasarkan pada TPC-B. Ini melibatkan 5 perintah SELECT, INSERT, dan UPDATE per transaksi. Namun, tergantung pada perilaku aplikasi Anda, Anda dapat menulis file skrip Anda sendiri. Mari kita lihat default dan beberapa hasil pengujian berorientasi skrip. Kami akan menggunakan PostgreSQL versi terbaru untuk pengujian ini, yaitu PostgreSQL 10 pada saat penulisan. Anda dapat menginstalnya menggunakan ClusterControl, atau menggunakan petunjuk di sini:https://www.openscg.com/bigsql/package-manager/.
Spesifikasi mesin
Versi:RHEL 6 - 64 bit
Memori :4GB
Prosesor:4
Penyimpanan:50G
Versi PostgreSQL:10.0
Ukuran Basis Data:15G
Sebelum Anda menjalankan benchmarking dengan alat pgbench, Anda perlu menginisialisasinya di bawah perintah:
-bash-4.1$ ./pgbench -i -p 5432 -d postgres
NOTICE: table "pgbench_history" does not exist, skipping
NOTICE: table "pgbench_tellers" does not exist, skipping
NOTICE: table "pgbench_accounts" does not exist, skipping
NOTICE: table "pgbench_branches" does not exist, skipping
creating tables…
100000 of 100000 tuples (100%) done (elapsed 0.18 s, remaining 0.00 s)
Vacuum…
set primary keys…
done.Seperti yang ditunjukkan dalam pesan NOTICE, ini membuat tabel pgbench_history, pgbench_tellers, pgbench_accounts, dan pgbench_branches untuk menjalankan transaksi untuk benchmarking.
Berikut adalah tes sederhana dengan 10 klien:
-bash-4.1$ ./pgbench -c 10
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 10
number of transactions actually processed: 100/100
latency average = 13.516 ms
tps = 739.865020 (including connections establishing)
tps = 760.775629 (excluding connections establishing)Seperti yang Anda lihat, itu berjalan dengan 10 klien dan 10 transaksi per klien. Ini memberi Anda 739 transaksi/dtk. Ini memberi Anda 739 transaksi/dtk. Jika Anda ingin menjalankannya untuk jangka waktu tertentu, Anda dapat menggunakan opsi "-T". Secara umum, lari 15 menit atau 30 menit sudah cukup.
Sampai sekarang, kami berbicara tentang cara menjalankan pgbench, tetapi bukan tentang apa yang seharusnya menjadi opsi. Sebelum memulai pembandingan, Anda harus mendapatkan detail yang tepat dari tim aplikasi di:
- Jenis beban kerja apa?
- Berapa banyak sesi bersamaan?
- Berapa rata-rata kumpulan hasil kueri?
- Berapa tps(transaksi per detik) yang diharapkan?
Berikut adalah contoh untuk beban kerja hanya-baca. Anda dapat menggunakan opsi "-S" untuk hanya menggunakan SELECT yang termasuk dalam read-only. Perhatikan bahwa -n adalah untuk melewatkan penyedotan debu di atas meja.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15741
latency average = 1916.650 ms
tps = 52.174363 (including connections establishing)
tps = 52.174913 (excluding connections establishing)
-bash-4.1$Latensi di sini adalah rata-rata waktu transaksi yang telah berlalu dari setiap pernyataan yang dieksekusi oleh setiap klien. Ini memberikan 52 tps dengan perangkat keras yang diberikan. Karena benchmark ini untuk lingkungan read-only, mari kita coba mengubah parameter shared_buffers dan effective_cache_size di file postgresql.conf dan periksa jumlah tps. Mereka berada pada nilai default dalam pengujian di atas, coba tingkatkan nilainya, dan periksa hasilnya.
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n
transaction type: <builtin: select only>
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 15215
latency average = 1984.255 ms
tps = 68.396758 (including connections establishing)
tps = 68.397322 (excluding connections establishing)Mengubah parameter meningkatkan kinerja sebesar 30%.
pgbench biasanya menjalankan transaksi pada tabelnya sendiri. Jika Anda memiliki beban kerja 50% baca dan 50% tulis (atau lingkungan 60:40), Anda dapat membuat file skrip dengan serangkaian pernyataan untuk mencapai beban kerja yang diharapkan.
-bash-4.1$ cat /tmp/bench.sql
INSERT INTO test_bench VALUES(1,'test');
INSERT INTO test_bench VALUES(1,'test');
SELECT * FROM test_bench WHERE id=1;
SELECT * FROM test_bench WHERE id=2;
-bash-4.1$ ./pgbench -c 100 -T 300 -S -n -f /tmp/bench.sql
transaction type: multiple scripts
scaling factor: 1000
query mode: simple
number of clients: 100
number of threads: 1
duration: 300 s
number of transactions actually processed: 25436
latency average = 1183.093 ms
tps = 84.524217 (including connections establishing)
tps = 84.525206 (excluding connections establishing)
SQL script 1: <builtin: select only>
- weight: 1 (targets 50.0% of total)
- 12707 transactions (50.0% of total, tps = 42.225555)
- latency average = 914.240 ms
- latency stddev = 558.013 ms
SQL script 2: /tmp/bench.sql
- weight: 1 (targets 50.0% of total)
- 12729 transactions (50.0% of total, tps = 42.298662)
- latency average = 1446.721 ms
- latency stddev = 765.933 msApa Faktor Kinerja utama di PostgreSQL
Jika kita mempertimbangkan lingkungan produksi nyata, itu dikonsolidasikan dengan komponen yang berbeda di tingkat aplikasi, perangkat keras seperti CPU dan memori, dan sistem operasi yang mendasarinya. Kami menginstal PostgreSQL di atas sistem operasi untuk berkomunikasi dengan komponen lain dari lingkungan produksi. Setiap lingkungan berbeda dan kinerja keseluruhan akan menurun jika tidak dikonfigurasi dengan benar. Di PostgreSQL, beberapa query berjalan lebih cepat dan beberapa lambat, namun itu tergantung pada konfigurasi yang telah ditetapkan. Tujuan dari optimasi kinerja database adalah untuk memaksimalkan throughput database dan meminimalkan koneksi untuk mencapai throughput sebesar mungkin. Berikut adalah beberapa faktor kinerja utama yang memengaruhi database:
- Beban Kerja
- Sumber daya
- Pengoptimalan
- Pertentangan
Beban kerja terdiri dari pekerjaan batch, kueri dinamis untuk transaksi online, kueri analitik data yang digunakan untuk menghasilkan laporan. Beban kerja mungkin berbeda selama periode hari, minggu atau bulan, dan tergantung pada aplikasi. Optimalisasi setiap database adalah unik. Ini bisa berupa konfigurasi tingkat basis data atau optimasi tingkat kueri. Kami akan membahas lebih lanjut tentang pengoptimalan di bagian selanjutnya dari posting. Pertikaian adalah kondisi di mana dua atau lebih komponen beban kerja mencoba menggunakan satu sumber daya dengan cara yang bertentangan. Saat pertengkaran meningkat, throughput menurun.
Apa itu Kiat dan Praktik Terbaik
Berikut adalah beberapa tips dan praktik terbaik yang dapat Anda ikuti untuk menghindari masalah performa:
- Anda dapat mempertimbangkan untuk menjalankan aktivitas pemeliharaan seperti VACUUM dan ANALYZE setelah modifikasi besar dalam database Anda. Ini membantu perencana untuk membuat rencana terbaik untuk mengeksekusi kueri.
- Cari kebutuhan untuk mengindeks tabel. Itu membuat kueri berjalan lebih cepat, daripada harus melakukan pemindaian tabel penuh.
- Untuk membuat traversal indeks lebih cepat, Anda dapat menggunakan perintah CREATE TABLE AS atau CLUSTER untuk mengelompokkan baris dengan nilai kunci yang serupa.
- Saat Anda melihat masalah kinerja, gunakan perintah EXPLAIN untuk melihat rencana tentang bagaimana pengoptimal memutuskan untuk mengeksekusi kueri Anda.
- Anda dapat mencoba mengubah paket dengan memengaruhi pengoptimal dengan memodifikasi operator kueri. Misalnya, jika Anda melihat pemindaian berurutan untuk kueri Anda, Anda dapat menonaktifkan pemindaian seq menggunakan "SET ENABLE_SEQSCAN TO OFF". Tidak ada jaminan bahwa pengoptimal tidak akan memilih operator tersebut jika Anda menonaktifkannya. Pengoptimal hanya menganggap operator jauh lebih mahal. Detail lebih lanjut ada di sini:https://www.postgresql.org/docs/current/static/runtime-config-query.html
- Anda juga dapat mencoba mengubah parameter biaya seperti CPU_OPERATOR_COST, CPU_INDEX_TUPLE_COST, CPU_TUPLE_COST, RANDOM_PAGE_COST, dan EFFECTIVE_CACHE_SIZE untuk memengaruhi pengoptimal. Detail lebih lanjut ada di sini:https://www.postgresql.org/docs/current/static/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
- Selalu filter data di server daripada di aplikasi klien. Ini akan meminimalkan lalu lintas jaringan dan memberikan kinerja yang lebih baik.
- Untuk melakukan operasi umum, selalu disarankan untuk menggunakan prosedur sisi server (pemicu dan fungsi). Pemicu atau fungsi sisi server diuraikan, direncanakan, dan dioptimalkan saat pertama kali digunakan, tidak setiap saat.
Apa Kesalahan Umum yang Dilakukan Orang
Salah satu kesalahan umum yang dilakukan orang adalah menjalankan database server dan database dengan parameter default. Konfigurasi default PostgreSQL diuji di beberapa lingkungan, namun tidak setiap aplikasi akan menemukan nilai tersebut optimal. Jadi, Anda perlu memahami perilaku aplikasi Anda dan berdasarkan itu, atur parameter konfigurasi Anda. Anda dapat menggunakan alat pgTune untuk mendapatkan nilai parameter Anda berdasarkan perangkat keras yang Anda gunakan. Anda dapat melihat di:http://pgtune.leopard.in.ua/. Namun, perlu diingat bahwa Anda harus menguji aplikasi Anda dengan perubahan yang Anda buat, untuk melihat apakah ada penurunan kinerja dengan perubahan tersebut.
Hal lain yang perlu dipertimbangkan adalah mengindeks database. Indeks membantu mengambil data lebih cepat, namun lebih banyak indeks membuat masalah saat memuat data. Jadi selalu periksa apakah ada indeks yang tidak digunakan dalam database, dan singkirkan indeks tersebut untuk mengurangi pemeliharaan indeks tersebut dan meningkatkan pemuatan data.
