Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Kinerja dan penskalaan untuk Amazon Aurora PostgreSQL
Bagian berikut membahas pengelolaan performa dan penskalaan untuk klaster DB Amazon Aurora PostgreSQL. Bagian tersebut juga berisi informasi tentang tugas pemeliharaan lainnya.
**Topics**
+ [Penskalaan instans DB Aurora PostgreSQL](#AuroraPostgreSQL.Managing.Performance.InstanceScaling)
+ [Koneksi maksimum ke instans DB Aurora PostgreSQL](#AuroraPostgreSQL.Managing.MaxConnections)
+ [Batas penyimpanan sementara untuk Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage)
+ [Halaman besar untuk Aurora PostgreSQL](#AuroraPostgreSQL.Managing.HugePages)
+ [Menguji Amazon Aurora PostgreSQL menggunakan kueri injeksi kesalahan](AuroraPostgreSQL.Managing.FaultInjectionQueries.md)
+ [Menampilkan status volume untuk klaster DB Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md)
+ [Menentukan disk RAM untuk stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md)
+ [Mengelola file sementara dengan PostgreSQL](PostgreSQL.ManagingTempFiles.md)
## Penskalaan instans DB Aurora PostgreSQL
Anda dapat menskalakan instans DB Aurora PostgreSQL dengan dua cara, penskalaan instans dan penskalaan baca. Untuk informasi selengkapnya tentang penskalaan baca, lihat [Penskalaan baca](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling).
Anda dapat menskalakan klaster DB Aurora PostgreSQL Anda dengan mengubah kelas instans DB untuk setiap instans DB dalam klaster DB. Aurora PostgreSQL mendukung beberapa kelas instans DB yang dioptimalkan untuk Aurora. Jangan gunakan kelas instans db.t2 atau db.t3 untuk klaster Aurora yang lebih besar dengan ukuran lebih dari 40 terabyte (TB).
**catatan**
Kami menyarankan penggunaan kelas instans DB T hanya untuk server pengembangan dan pengujian, atau server non-produksi lainnya. Untuk detail selengkapnya tentang kelas instans T, lihat [Jenis kelas instans DB](Concepts.DBInstanceClass.Types.md).
Penskalaan tidak terjadi secara instan. Diperlukan waktu 15 menit atau lebih untuk menyelesaikan perubahan ke kelas instans DB yang berbeda. Jika Anda menggunakan pendekatan ini untuk mengubah kelas instans DB, Anda perlu menerapkan perubahan selama periode pemeliharaan terjadwal berikutnya (bukan segera) agar tidak memengaruhi pengguna.
Sebagai alternatif untuk mengubah kelas instans DB secara langsung, Anda dapat meminimalkan waktu henti dengan menggunakan fitur ketersediaan tinggi Amazon Aurora. Pertama, tambahkan Replika Aurora ke klaster Anda. Saat membuat replika, pilih ukuran kelas instans DB yang ingin Anda gunakan untuk klaster Anda. Ketika Replika Aurora disinkronkan dengan klaster, maka Anda akan melakukan failover ke Replika yang baru ditambahkan. Untuk mempelajari selengkapnya, lihat [Replika Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) dan [Failover cepat dengan Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md).
Untuk spesifikasi terperinci tentang kelas instans DB yang didukung oleh Aurora PostgreSQL, lihat [Mesin DB yang didukung untuk kelas instans DB](Concepts.DBInstanceClass.SupportAurora.md).
## Koneksi maksimum ke instans DB Aurora PostgreSQL
klaster DB Aurora PostgreSQL mengalokasikan sumber daya berdasarkan kelas instans DB dan memori yang tersedia. Setiap koneksi ke klaster DB mengonsumsi sejumlah tambahan sumber daya ini, seperti memori dan CPU. Memori yang dikonsumsi per koneksi bervariasi berdasarkan jenis kueri, jumlah, dan apakah tabel sementara digunakan. Bahkan koneksi idle menghabiskan memori dan CPU. Hal ini karena ketika kueri dijalankan pada koneksi, lebih banyak memori dialokasikan untuk setiap kueri dan tidak dirilis sepenuhnya, bahkan ketika pemrosesan berhenti. Oleh karena itu, kami menyarankan agar Anda memastikan aplikasi Anda tidak mempertahankan koneksi idle: setiap koneksi idle akan memboroskan sumber daya dan memengaruhi performa secara negatif. Untuk informasi selengkapnya, lihat [Sumber daya yang dikonsumsi oleh koneksi PostgreSQL idle](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/).
Jumlah maksimum koneksi yang diizinkan oleh instans DB Aurora PostgreSQL akan ditentukan berdasarkan nilai parameter `max_connections` yang ditentukan dalam grup parameter untuk instans DB tersebut. Pengaturan ideal untuk `max_connections` parameter adalah yang mendukung semua koneksi klien yang dibutuhkan aplikasi Anda, tanpa kelebihan koneksi yang tidak digunakan, ditambah setidaknya 3 koneksi lagi untuk mendukung AWS otomatisasi. Sebelum mengubah pengaturan parameter `max_connections`, sebaiknya pertimbangkan hal berikut:
+ Jika nilai `max_connections` terlalu rendah, instans DB Aurora PostgreSQL mungkin tidak memiliki koneksi yang cukup saat klien mencoba terhubung. Jika hal ini terjadi, coba hubungkan menggunakan pesan "raise error" `psql` seperti berikut ini:
```
psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
```
+ Jika nilai `max_connections` melebihi jumlah koneksi yang benar-benar dibutuhkan, koneksi yang tidak terpakai dapat menyebabkan performa menurun.
Nilai default `max_connections` berasal dari fungsi `LEAST` Aurora PostgreSQL berikut:
`LEAST({DBInstanceClassMemory/9531392},5000)`.
Jika Anda ingin mengubah nilai `max_connections`, Anda perlu membuat grup parameter klaster DB kustom dan mengubah nilainya di sana. Setelah menerapkan grup parameter DB kustom Anda ke klaster Anda, pastikan untuk mem-boot ulang instans primer agar nilai baru mulai berlaku. Untuk informasi selengkapnya, lihat [Parameter Amazon Aurora PostgreSQL](AuroraPostgreSQL.Reference.ParameterGroups.md) dan [Membuat grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
**Tip**
Jika aplikasi Anda sering membuka dan menutup koneksi, atau membiarkan sejumlah besar koneksi yang lama aktif tetap terbuka, kami menyarankan agar Anda menggunakan Proksi Amazon RDS. Proksi RDS adalah proksi basis data yang sepenuhnya terkelola dengan ketersediaan tinggi yang menggunakan pooling koneksi untuk berbagi koneksi basis data dengan aman dan efisien. Untuk mempelajari tentang Proksi RDS, lihat [Proksi Amazon RDS untuk Aurora](rds-proxy.md).
Untuk detail tentang cara instans Aurora Serverless v2 menangani parameter ini, lihat [Koneksi maksimum untuk Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections).
## Batas penyimpanan sementara untuk Aurora PostgreSQL
Aurora PostgreSQL menyimpan tabel dan indeks dalam subsistem penyimpanan Aurora. Aurora PostgreSQL menggunakan penyimpanan sementara terpisah untuk file sementara non-persisten. Hal ini termasuk file yang digunakan untuk tujuan seperti mengurutkan set data besar selama pemrosesan kueri atau untuk operasi pembuatan indeks. Untuk informasi selengkapnya, lihat artikel [Bagaimana cara memecahkan masalah penyimpanan lokal di instans yang kompatibel dengan Aurora PostgreSQL?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue).
Volume penyimpanan lokal ini didukung oleh Amazon Elastic Block Store dan dapat diperluas dengan menggunakan kelas instans DB yang lebih besar. Untuk informasi selengkapnya tentang penyimpanan, lihat [Penyimpanan Amazon Aurora](Aurora.Overview.StorageReliability.md). Anda juga dapat meningkatkan penyimpanan lokal untuk objek sementara dengan menggunakan jenis instans yang diaktifkan dan objek sementara yang NVMe diaktifkan oleh Aurora Optimized Reading. Untuk informasi selengkapnya, lihat [Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md).
**catatan**
Anda mungkin melihat peristiwa `storage-optimization` saat menskalakan instans DB, misalnya, dari db.r5.2xlarge ke db.r5.4xlarge.
Tabel berikut menunjukkan jumlah maksimum penyimpanan sementara yang tersedia untuk setiap kelas instans DB Aurora PostgreSQL. Untuk informasi selengkapnya tentang dukungan kelas instans DB untuk Aurora, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md).
| Kelas instans DB | Penyimpanan sementara maksimum yang tersedia (GiB) |
| --- | --- |
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r8g.48xlarge | 3072 |
| db.r8g.24xlarge | 1536 |
| db.r8g.16xlarge | 998 |
| db.r8g.12xlarge | 749 |
| db.r8g.8xlarge | 499 |
| db.r8g.4xlarge | 250 |
| db.r8g.2xlarge | 125 |
| db.r8g.xlarge | 63 |
| db.r8g.large | 31 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r7i.48xlarge | 3072 |
| db.r7i.24xlarge | 1500 |
| db.r7i.16xlarge | 1008 |
| db.r7i.12xlarge | 748 |
| db.r7i.8xlarge | 504 |
| db.r7i.4xlarge | 249 |
| db.r7i.2xlarge | 124 |
| db.r7i.xlarge | 62 |
| db.r7i.large | 31 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16.5 |
| db.t4g.medium | 8.13 |
| db.t3.large | 16 |
| db.t3.medium | 7.5 |
**catatan**
NVMe jenis instance yang diaktifkan dapat meningkatkan ruang sementara yang tersedia hingga NVMe ukuran total. Untuk informasi selengkapnya, lihat [Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md).
Anda dapat memantau penyimpanan sementara yang tersedia untuk instans DB dengan `FreeLocalStorage` CloudWatch metrik, -> dijelaskan dalam[CloudWatch Metrik Amazon untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). (Hal ini tidak berlaku untuk Aurora Serverless v2.)
Untuk beberapa beban kerja, Anda dapat mengurangi jumlah penyimpanan sementara dengan mengalokasikan lebih banyak memori ke proses yang melakukan operasi. Untuk meningkatkan ketersediaan memori bagi operasi, tingkatkan nilai parameter PostgreSQL [work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) atau [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM).
## Halaman besar untuk Aurora PostgreSQL
*Halaman besar* adalah fitur manajemen memori yang mengurangi overhead saat instans DB menangani potongan besar memori yang berdekatan, seperti yang digunakan oleh buffer bersama. Fitur PostgreSQL ini didukung oleh semua versi Aurora PostgreSQL yang tersedia saat ini.
Parameter `Huge_pages` diaktifkan secara default untuk semua kelas instans DB selain kelas instans t3.medium, db.t3.large, db.t4g.medium, db.t4g.large. Anda tidak dapat mengubah nilai parameter `huge_pages` atau menonaktifkan fitur ini di kelas instans Aurora PostgreSQL yang didukung.
Pada instance Aurora PostgreSQL DB yang tidak mendukung fitur memori halaman besar, penggunaan memori proses tertentu mungkin meningkat tanpa perubahan beban kerja yang sesuai.
Sistem mengalokasikan segmen memori bersama seperti cache buffer selama startup server. Ketika halaman memori besar tidak tersedia, sistem tidak membebankan alokasi ini ke proses postmaster. Sebaliknya, itu termasuk memori dalam proses yang pertama kali mengakses setiap halaman 4KB di segmen memori bersama.
**catatan**
Koneksi aktif berbagi memori yang dialokasikan sesuai kebutuhan, terlepas dari bagaimana penggunaan memori bersama dilacak di seluruh proses.