Blog ini memulai multi-seri yang mendokumentasikan perjalanan saya dalam membuat tolok ukur PostgreSQL di cloud.
Bagian pertama mencakup ikhtisar alat tolok ukur, dan memulai kesenangan dengan Amazon Aurora PostgreSQL.
Memilih Penyedia Layanan Cloud PostgreSQL
Beberapa waktu yang lalu saya menemukan prosedur benchmark AWS untuk Aurora, dan berpikir akan sangat keren jika saya dapat mengikuti tes itu dan menjalankannya di penyedia hosting cloud lainnya. Untuk Amazon, dari tiga penyedia komputasi utilitas paling terkenal — AWS, Google, dan Microsoft — AWS adalah satu-satunya kontributor utama untuk pengembangan PostgreSQL, dan yang pertama menawarkan layanan PostgreSQL terkelola (sejak November 2013).
Meskipun layanan PostgreSQL terkelola juga tersedia dari sejumlah besar Penyedia Hosting PostgreSQL, saya ingin fokus pada tiga penyedia komputasi awan tersebut karena lingkungan mereka adalah tempat banyak organisasi yang mencari keuntungan komputasi awan memilih untuk menjalankan aplikasi mereka, asalkan mereka memiliki pengetahuan yang diperlukan dalam mengelola PostgreSQL. Saya sangat yakin bahwa dalam lanskap TI saat ini, organisasi yang bekerja dengan beban kerja kritis di cloud akan sangat diuntungkan dari layanan penyedia layanan PostgreSQL khusus, yang dapat membantu mereka menavigasi dunia GUCS yang kompleks dan berbagai presentasi SlideShare.
Memilih Alat Tolok Ukur yang Tepat
Pembandingan PostgreSQL cukup sering muncul di milis kinerja, dan seperti yang ditekankan berkali-kali pengujian tidak dimaksudkan untuk memvalidasi konfigurasi untuk aplikasi kehidupan nyata. Namun, memilih alat dan parameter benchmark yang tepat adalah penting untuk mengumpulkan hasil yang berarti. Saya berharap setiap penyedia cloud menyediakan prosedur untuk membandingkan layanan mereka, terutama ketika pengalaman cloud pertama mungkin tidak dimulai dengan langkah yang benar. Kabar baiknya adalah bahwa dua dari tiga pemain dalam tes ini, telah memasukkan tolok ukur dalam dokumentasi mereka. Panduan Prosedur Tolok Ukur AWS untuk Aurora mudah ditemukan, tersedia langsung di halaman Sumber Daya Amazon Aurora. Google tidak memberikan panduan khusus untuk PostgreSQL, namun, dokumentasi Compute Engine berisi panduan pengujian beban untuk SQL Server berdasarkan HammerDB.
Berikut rangkuman alat benchmark berdasarkan referensinya yang layak untuk dilihat:
- Tolok Ukur AWS yang disebutkan di atas didasarkan pada pgbench dan sysbench.
- HammerDB, juga disebutkan sebelumnya, dibahas dalam posting terbaru di daftar pgsql-hacker.
- Tes TPC-C berdasarkan oltpbench seperti yang disinggung dalam diskusi pgsql-hacker lainnya.
- benchmarksql adalah tes TPC-C lain yang digunakan untuk memvalidasi perubahan pada pemisahan halaman B-Tree.
- pg_ycsb adalah anak baru di kota ini, berkembang di pgbench dan sudah digunakan oleh beberapa peretas PostgreSQL.
- pgbench-tools seperti namanya, didasarkan pada pgbench dan meskipun tidak menerima pembaruan apa pun sejak 2016, ini adalah produk Greg Smith, penulis buku PostgreSQL High Performance.
- tolok ukur join order adalah tolok ukur yang akan menguji pengoptimal kueri.
- pgreplay yang saya temukan saat membaca blog Command Prompt sedekat mungkin dengan benchmark skenario kehidupan nyata.
Hal lain yang perlu diperhatikan adalah bahwa PostgreSQL belum cocok untuk standar benchmark TPC-H, dan seperti disebutkan di atas semua alat (kecuali pgreplay) harus dijalankan dalam mode TPC-C (default pgbench untuk itu).
Untuk tujuan blog ini, menurut saya Prosedur Tolok Ukur AWS untuk Aurora adalah awal yang baik karena menetapkan standar untuk penyedia cloud dan didasarkan pada alat yang banyak digunakan.
Juga, saya menggunakan versi PostgreSQL terbaru yang tersedia saat itu. Saat memilih penyedia cloud, penting untuk mempertimbangkan frekuensi peningkatan, terutama ketika fitur penting yang diperkenalkan oleh versi baru dapat memengaruhi kinerja (yang berlaku untuk versi 10 dan 11 versus 9). Pada tulisan ini kami memiliki:
- Amazon Aurora PostgreSQL 10.6
- Amazon RDS untuk PostgreSQL 10.6
- Google Cloud SQL untuk PostgreSQL 9.6
- Microsoft Azure PostgreSQL 10.5
...dan pemenangnya di sini adalah AWS dengan menawarkan versi terbaru (walaupun bukan yang terbaru, yang hingga tulisan ini dibuat adalah 11.2).
Menyiapkan Lingkungan Tolok Ukur
Saya memutuskan untuk membatasi pengujian saya pada beban kerja rata-rata karena beberapa alasan:Pertama, sumber daya cloud yang tersedia tidak sama di seluruh penyedia. Dalam panduan, spesifikasi AWS untuk instans database adalah 64 vCPU / 488 GiB RAM / 25 Gigabit Network, sedangkan RAM maksimum Google untuk ukuran instans apa pun (pilihan harus disetel ke "kustom" di Google Calculator) adalah 208 GiB, dan Microsoft Business Critical Gen5 pada 32 vCPU hanya hadir dengan 163 GiB). Kedua, inisialisasi pgbench membawa ukuran database ke 160GiB yang dalam kasus sebuah instance dengan 488 GiB RAM kemungkinan akan disimpan dalam memori.
Juga, saya membiarkan konfigurasi PostgreSQL tidak tersentuh. Alasan untuk tetap berpegang pada default penyedia cloud adalah bahwa, di luar kotak, ketika ditekankan oleh tolok ukur standar, layanan terkelola diharapkan berkinerja cukup baik. Ingatlah bahwa komunitas PostgreSQL menjalankan tes pgbench sebagai bagian dari proses manajemen rilis. Selain itu, panduan AWS tidak menyebutkan perubahan apa pun pada konfigurasi default PostgreSQL.
Seperti yang dijelaskan dalam panduan, AWS menerapkan dua tambalan ke pgbench. Karena patch untuk jumlah klien tidak diterapkan dengan benar pada PostgreSQL versi 10.6 dan saya tidak ingin menginvestasikan waktu untuk memperbaikinya, jumlah klien dibatasi hingga maksimum 1.000.
Panduan ini menetapkan persyaratan bagi instans klien untuk mengaktifkan jaringan yang disempurnakan — untuk jenis instans ini yang merupakan default:
[[email protected] ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0a:cd:ee:40:2b:e6 brd ff:ff:ff:ff:ff:ff
inet 172.31.19.190/20 brd 172.31.31.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::8cd:eeff:fe40:2be6/64 scope link
valid_lft forever preferred_lft forever
[[email protected] ~]$ ethtool -i eth0
driver: ena
version: 2.0.2g
firmware-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no
>>> aws (master *%) ~ $ aws ec2 describe-instances --instance-ids i-0ee51642334c1ec57 --query "Reservations[].Instances[].EnaSupport"
[
true
]Menjalankan Tolok Ukur di Amazon Aurora PostgreSQL
Selama menjalankan yang sebenarnya, saya memutuskan untuk membuat satu penyimpangan lagi dari panduan:alih-alih menjalankan tes selama 1 jam, tetapkan batas waktu menjadi 10 menit, yang secara umum diterima sebagai nilai yang baik.
Jalankan #1
Spesifikasi
- Pengujian ini menggunakan spesifikasi AWS untuk ukuran instans klien dan database.
- Mesin klien:Memori Sesuai Permintaan Dioptimalkan EC2 instans:
- vCPU:32 (16 Core x 2 Thread/Core)
- RAM:244 GiB
- Penyimpanan:EBS Dioptimalkan
- Jaringan:10 Gigabit
- Kluster DB:db.r4.16xlarge
- vCPU:64
- ECU (kapasitas CPU):195 x [1.0-1.2 GHz] 2007 Opteron / Xeon
- RAM:488 GiB
- Penyimpanan:EBS Dioptimalkan (Kapasitas khusus untuk I/O)
- Jaringan:Bandwidth Maks 14.000 Mbps pada jaringan 25 Gps
- Mesin klien:Memori Sesuai Permintaan Dioptimalkan EC2 instans:
- Pengaturan basis data menyertakan satu replika.
- Penyimpanan basis data tidak dienkripsi.
Melakukan Pengujian dan Hasil
- Ikuti petunjuk dalam panduan untuk menginstal pgbench dan sysbench.
- Edit ~/.bashrc untuk menyetel variabel lingkungan untuk koneksi database dan jalur yang diperlukan ke perpustakaan PostgreSQL:
export PGHOST=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com export PGUSER=postgres export PGPASSWORD=postgres export PGDATABASE=postgres export PATH=$PATH:/usr/local/pgsql/bin export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib - Inisialisasi database:
[[email protected] ~]# pgbench -i --fillfactor=90 --scale=10000 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 1000000000 tuples (0%) done (elapsed 0.05 s, remaining 457.23 s) 200000 of 1000000000 tuples (0%) done (elapsed 0.13 s, remaining 631.70 s) 300000 of 1000000000 tuples (0%) done (elapsed 0.21 s, remaining 688.29 s) ... 999500000 of 1000000000 tuples (99%) done (elapsed 811.41 s, remaining 0.41 s) 999600000 of 1000000000 tuples (99%) done (elapsed 811.50 s, remaining 0.32 s) 999700000 of 1000000000 tuples (99%) done (elapsed 811.58 s, remaining 0.24 s) 999800000 of 1000000000 tuples (99%) done (elapsed 811.65 s, remaining 0.16 s) 999900000 of 1000000000 tuples (99%) done (elapsed 811.73 s, remaining 0.08 s) 1000000000 of 1000000000 tuples (100%) done (elapsed 811.80 s, remaining 0.00 s) vacuum... set primary keys... done. - Verifikasi ukuran database:
postgres=> \l+ postgres List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges | Size | Tablespace | Description ----------+----------+----------+-------------+-------------+-------------------+--------+------------+-------------------------------------------- postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | 160 GB | pg_default | default administrative connection database (1 row) - Gunakan kueri berikut untuk memverifikasi bahwa interval waktu antara pos pemeriksaan diatur sehingga pos pemeriksaan akan dipaksakan selama 10 menit berjalan:
Hasil:SELECT total_checkpoints, seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints FROM ( SELECT EXTRACT( EPOCH FROM ( now() - pg_postmaster_start_time() ) ) AS seconds_since_start, (checkpoints_timed+checkpoints_req) AS total_checkpoints FROM pg_stat_bgwriter) AS sub;postgres=> \e total_checkpoints | minutes_between_checkpoints -------------------+----------------------------- 50 | 0.977392292333333 (1 row) - Jalankan beban kerja Baca/Tulis:
Keluaran[[email protected] ~]# pgbench --protocol=prepared -P 60 --time=600 --client=1000 --jobs=2048starting vacuum...end. progress: 60.0 s, 35670.3 tps, lat 27.243 ms stddev 10.915 progress: 120.0 s, 36569.5 tps, lat 27.352 ms stddev 11.859 progress: 180.0 s, 35845.2 tps, lat 27.896 ms stddev 12.785 progress: 240.0 s, 36613.7 tps, lat 27.310 ms stddev 11.804 progress: 300.0 s, 37323.4 tps, lat 26.793 ms stddev 11.376 progress: 360.0 s, 36828.8 tps, lat 27.155 ms stddev 11.318 progress: 420.0 s, 36670.7 tps, lat 27.268 ms stddev 12.083 progress: 480.0 s, 37176.1 tps, lat 26.899 ms stddev 10.981 progress: 540.0 s, 37210.8 tps, lat 26.875 ms stddev 11.341 progress: 600.0 s, 37415.4 tps, lat 26.727 ms stddev 11.521 transaction type: <builtin: TPC-B (sort of)> scaling factor: 10000 query mode: prepared number of clients: 1000 number of threads: 1000 duration: 600 s number of transactions actually processed: 22040445 latency average = 27.149 ms latency stddev = 11.617 ms tps = 36710.828624 (including connections establishing) tps = 36811.054851 (excluding connections establishing) - Siapkan pengujian sysbench:
Output:sysbench --test=/usr/local/share/sysbench/oltp.lua \ --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \ --pgsql-db=postgres \ --pgsql-user=postgres \ --pgsql-password=postgres \ --pgsql-port=5432 \ --oltp-tables-count=250\ --oltp-table-size=450000 \ preparesysbench 0.5: multi-threaded system evaluation benchmark Creating table 'sbtest1'... Inserting 450000 records into 'sbtest1' Creating secondary indexes on 'sbtest1'... Creating table 'sbtest2'... ... Creating table 'sbtest250'... Inserting 450000 records into 'sbtest250' Creating secondary indexes on 'sbtest250'... - Jalankan pengujian sysbench:
Output:sysbench --test=/usr/local/share/sysbench/oltp.lua \ --pgsql-host=aurora.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com \ --pgsql-db=postgres \ --pgsql-user=postgres \ --pgsql-password=postgres \ --pgsql-port=5432 \ --oltp-tables-count=250 \ --oltp-table-size=450000 \ --max-requests=0 \ --forced-shutdown \ --report-interval=60 \ --oltp_simple_ranges=0 \ --oltp-distinct-ranges=0 \ --oltp-sum-ranges=0 \ --oltp-order-ranges=0 \ --oltp-point-selects=0 \ --rand-type=uniform \ --max-time=600 \ --num-threads=1000 \ runsysbench 0.5: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Report intermediate results every 60 second(s) Random number generator seed is 0 and will be ignored Forcing shutdown in 630 seconds Initializing worker threads... Threads started! [ 60s] threads: 1000, tps: 20443.09, reads: 0.00, writes: 81834.16, response time: 68.24ms (95%), errors: 0.62, reconnects: 0.00 [ 120s] threads: 1000, tps: 20580.68, reads: 0.00, writes: 82324.33, response time: 70.75ms (95%), errors: 0.73, reconnects: 0.00 [ 180s] threads: 1000, tps: 20531.85, reads: 0.00, writes: 82127.21, response time: 70.63ms (95%), errors: 0.73, reconnects: 0.00 [ 240s] threads: 1000, tps: 20212.67, reads: 0.00, writes: 80861.67, response time: 71.99ms (95%), errors: 0.43, reconnects: 0.00 [ 300s] threads: 1000, tps: 19383.90, reads: 0.00, writes: 77537.87, response time: 75.64ms (95%), errors: 0.75, reconnects: 0.00 [ 360s] threads: 1000, tps: 19797.20, reads: 0.00, writes: 79190.78, response time: 75.27ms (95%), errors: 0.68, reconnects: 0.00 [ 420s] threads: 1000, tps: 20304.43, reads: 0.00, writes: 81212.87, response time: 73.82ms (95%), errors: 0.70, reconnects: 0.00 [ 480s] threads: 1000, tps: 20933.80, reads: 0.00, writes: 83737.16, response time: 74.71ms (95%), errors: 0.68, reconnects: 0.00 [ 540s] threads: 1000, tps: 20663.05, reads: 0.00, writes: 82626.42, response time: 73.56ms (95%), errors: 0.75, reconnects: 0.00 [ 600s] threads: 1000, tps: 20746.02, reads: 0.00, writes: 83015.81, response time: 73.58ms (95%), errors: 0.78, reconnects: 0.00 OLTP test statistics: queries performed: read: 0 write: 48868458 other: 24434022 total: 73302480 transactions: 12216804 (20359.59 per sec.) read/write requests: 48868458 (81440.43 per sec.) other operations: 24434022 (40719.87 per sec.) ignored errors: 414 (0.69 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 600.0516s total number of events: 12216804 total time taken by event execution: 599964.4735s response time: min: 6.27ms avg: 49.11ms max: 350.24ms approx. 95 percentile: 72.90ms Threads fairness: events (avg/stddev): 12216.8040/31.27 execution time (avg/stddev): 599.9645/0.01
Metrik yang Dikumpulkan
Metrik Cloudwatch 
Metrik Wawasan KinerjaUnduh Whitepaper Hari Ini Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola dan menskalakan PostgreSQLUnduh Whitepaper Jalankan #2
Spesifikasi
- Pengujian ini menggunakan spesifikasi AWS untuk klien dan ukuran instans yang lebih kecil untuk database:
- Mesin klien:Memori Sesuai Permintaan Dioptimalkan EC2 instans:
- vCPU:32 (16 Core x 2 Thread/Core)
- RAM:244 GiB
- Penyimpanan:EBS Dioptimalkan
- Jaringan:10 Gigabit
- Kluster DB:db.r4.2xlarge:
- vCPU:8
- RAM:61GiB
- Penyimpanan:EBS Dioptimalkan
- Jaringan:1.750 Mbps Max Bandwidth pada koneksi hingga 10 Gbps
- Mesin klien:Memori Sesuai Permintaan Dioptimalkan EC2 instans:
- Basis data tidak menyertakan replika.
- Penyimpanan basis data tidak dienkripsi.
Melakukan Pengujian dan Hasil
Langkah-langkahnya identik dengan Jalankan #1 jadi saya hanya menampilkan hasilnya:
-
pgbench Beban kerja Baca/Tulis:
... 745700000 of 1000000000 tuples (74%) done (elapsed 794.93 s, remaining 271.09 s) 745800000 of 1000000000 tuples (74%) done (elapsed 795.00 s, remaining 270.97 s) 745900000 of 1000000000 tuples (74%) done (elapsed 795.09 s, remaining 270.86 s) 746000000 of 1000000000 tuples (74%) done (elapsed 795.17 s, remaining 270.74 s) 746100000 of 1000000000 tuples (74%) done (elapsed 795.24 s, remaining 270.62 s) 746200000 of 1000000000 tuples (74%) done (elapsed 795.33 s, remaining 270.51 s) ... 999800000 of 1000000000 tuples (99%) done (elapsed 1067.11 s, remaining 0.21 s) 999900000 of 1000000000 tuples (99%) done (elapsed 1067.19 s, remaining 0.11 s) 1000000000 of 1000000000 tuples (100%) done (elapsed 1067.28 s, remaining 0.00 s) vacuum... set primary keys... total time: 4386.44 s (insert 1067.33 s, commit 0.46 s, vacuum 2088.25 s, index 1230.41 s) done.starting vacuum...end. progress: 60.0 s, 3361.3 tps, lat 286.143 ms stddev 80.417 progress: 120.0 s, 3466.8 tps, lat 288.386 ms stddev 76.373 progress: 180.0 s, 3683.1 tps, lat 271.840 ms stddev 75.712 progress: 240.0 s, 3444.3 tps, lat 289.909 ms stddev 69.564 progress: 300.0 s, 3475.8 tps, lat 287.736 ms stddev 73.712 progress: 360.0 s, 3449.5 tps, lat 289.832 ms stddev 71.878 progress: 420.0 s, 3518.1 tps, lat 284.432 ms stddev 74.276 progress: 480.0 s, 3430.7 tps, lat 291.359 ms stddev 73.264 progress: 540.0 s, 3515.7 tps, lat 284.522 ms stddev 73.206 progress: 600.0 s, 3482.9 tps, lat 287.037 ms stddev 71.649 transaction type: <builtin: TPC-B (sort of)> scaling factor: 10000 query mode: prepared number of clients: 1000 number of threads: 1000 duration: 600 s number of transactions actually processed: 2090702 latency average = 286.030 ms latency stddev = 74.245 ms tps = 3481.731730 (including connections establishing) tps = 3494.157830 (excluding connections establishing) -
tes sysbench:
sysbench 0.5: multi-threaded system evaluation benchmark Running the test with following options: Number of threads: 1000 Report intermediate results every 60 second(s) Random number generator seed is 0 and will be ignored Forcing shutdown in 630 seconds Initializing worker threads... Threads started! [ 60s] threads: 1000, tps: 4809.05, reads: 0.00, writes: 19301.02, response time: 288.03ms (95%), errors: 0.05, reconnects: 0.00 [ 120s] threads: 1000, tps: 5264.15, reads: 0.00, writes: 21005.40, response time: 255.23ms (95%), errors: 0.08, reconnects: 0.00 [ 180s] threads: 1000, tps: 5178.27, reads: 0.00, writes: 20713.07, response time: 260.40ms (95%), errors: 0.03, reconnects: 0.00 [ 240s] threads: 1000, tps: 5145.95, reads: 0.00, writes: 20610.08, response time: 255.76ms (95%), errors: 0.05, reconnects: 0.00 [ 300s] threads: 1000, tps: 5127.92, reads: 0.00, writes: 20507.98, response time: 264.24ms (95%), errors: 0.05, reconnects: 0.00 [ 360s] threads: 1000, tps: 5063.83, reads: 0.00, writes: 20278.10, response time: 268.55ms (95%), errors: 0.05, reconnects: 0.00 [ 420s] threads: 1000, tps: 5057.51, reads: 0.00, writes: 20237.28, response time: 269.19ms (95%), errors: 0.10, reconnects: 0.00 [ 480s] threads: 1000, tps: 5036.32, reads: 0.00, writes: 20139.29, response time: 279.62ms (95%), errors: 0.10, reconnects: 0.00 [ 540s] threads: 1000, tps: 5115.25, reads: 0.00, writes: 20459.05, response time: 264.64ms (95%), errors: 0.08, reconnects: 0.00 [ 600s] threads: 1000, tps: 5124.89, reads: 0.00, writes: 20510.07, response time: 265.43ms (95%), errors: 0.10, reconnects: 0.00 OLTP test statistics: queries performed: read: 0 write: 12225686 other: 6112822 total: 18338508 transactions: 3056390 (5093.75 per sec.) read/write requests: 12225686 (20375.20 per sec.) other operations: 6112822 (10187.57 per sec.) ignored errors: 42 (0.07 per sec.) reconnects: 0 (0.00 per sec.) General statistics: total time: 600.0277s total number of events: 3056390 total time taken by event execution: 600005.2104s response time: min: 9.57ms avg: 196.31ms max: 608.70ms approx. 95 percentile: 268.71ms Threads fairness: events (avg/stddev): 3056.3900/67.44 execution time (avg/stddev): 600.0052/0.01
Metrik yang Dikumpulkan
Metrik Cloudwatch 
Wawasan Kinerja - Metrik Penghitung 
Wawasan Kinerja - Pemuatan Basis Data berdasarkan Waktu Tunggu Pemikiran Terakhir
- Pengguna dibatasi untuk menggunakan ukuran instans yang telah ditentukan sebelumnya. Kelemahannya, jika tolok ukur menunjukkan bahwa instans dapat memperoleh manfaat dari memori tambahan, tidak mungkin untuk "menambahkan lebih banyak RAM". Menambahkan lebih banyak memori berarti meningkatkan ukuran instans yang disertai dengan biaya lebih tinggi (biaya berlipat ganda untuk setiap ukuran instans).
- Mesin penyimpanan Amazon Aurora jauh berbeda dari RDS, dan dibangun di atas perangkat keras SAN. Metrik throughput I/O per instans menunjukkan bahwa pengujian tidak mendekati maksimum untuk volume EBS SSD IOPS yang disediakan sebesar 1.750 MiB/dtk.
- Penyetelan lebih lanjut dapat dilakukan dengan meninjau AWS PostgreSQL Events yang disertakan dalam grafik Performance Insights.
Seri berikutnya
Nantikan bagian selanjutnya:Amazon RDS untuk PostgreSQL 10.6.
