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. # Menguji Amazon Aurora PostgreSQL menggunakan kueri injeksi kesalahan Anda dapat menguji toleransi kesalahan klaster DB Aurora PostgreSQL Anda menggunakan kueri injeksi kesalahan. Kueri injeksi kesalahan dikeluarkan sebagai perintah SQL ke instans Amazon Aurora. Kueri injeksi kesalahan memungkinkan Anda menyebabkan crash pada instans sehingga Anda dapat menguji failover dan pemulihan. Anda juga dapat menyimulasikan kegagalan Replika Aurora, kegagalan disk, dan kepadatan disk. Kueri injeksi kesalahan didukung oleh semua versi Aurora PostgreSQL yang tersedia, sebagai berikut. + Aurora PostgreSQL versi 12, 13, 14, dan lebih tinggi + Aurora PostgreSQL versi 11.7 dan lebih tinggi + Aurora PostgreSQL versi 10.11 dan lebih tinggi **Topics** + [Menguji crash instans](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Menguji kegagalan Replika Aurora](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Menguji kegagalan disk](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Menguji kepadatan disk](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Ketika kueri injeksi kesalahan menentukan suatu crash, kueri ini akan menyebabkan crash pada instans DB Aurora PostgreSQL. Kueri injeksi kesalahan lainnya menghasilkan simulasi peristiwa kegagalan, tetapi tidak menyebabkan peristiwa terjadi. Jika Anda mengirim kueri injeksi kesalahan, Anda juga menentukan durasi waktu untuk simulasi peristiwa kegagalan yang akan terjadi. Anda dapat mengirim kueri injeksi kesalahan ke salah satu instans Replika Aurora dengan menghubungkan ke titik akhir untuk Replika Aurora. Untuk informasi selengkapnya, lihat [Koneksi titik akhir Amazon Aurora](Aurora.Overview.Endpoints.md). ## Menguji crash instans Anda dapat memaksa crash instans Aurora PostgreSQL menggunakan fungsi kueri injeksi kesalahan `aurora_inject_crash()`. Untuk kueri injeksi kesalahan ini, failover tidak akan terjadi. Jika Anda ingin menguji failover, Anda dapat memilih tindakan instance **Failover** untuk cluster DB Anda di konsol RDS, atau menggunakan [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI perintah atau operasi [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS API. **Sintaksis** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Opsi Kueri injeksi kesalahan ini menggunakan salah satu dari jenis crash berikut. Jenis crash tidak peka huruf besar/kecil: *'instans'* Crash basis data yang kompatibel dengan PostgreSQL untuk instans Amazon Aurora disimulasikan. *'dispatcher'* Crash dispatcher pada instans primer untuk klaster DB Aurora disimulasikan. *Dispatcher* menulis pembaruan ke volume klaster untuk klaster DB Amazon Aurora. *'simpul'* Crash basis data yang kompatibel dengan PostgreSQL dan dispatcher untuk instans Amazon Aurora disimulasikan. ## Menguji kegagalan Replika Aurora Anda dapat menyimulasikan kegagalan Replika Aurora menggunakan fungsi kueri injeksi kesalahan `aurora_inject_replica_failure()`. Kegagalan Replika Aurora akan memblokir replikasi ke Replika Aurora atau semua Replika Aurora dalam klaster DB untuk interval waktu yang ditentukan. Ketika interval waktu selesai, Replika Aurora yang terdampak akan secara otomatis tersinkronisasi dengan instans primer. **Sintaksis** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Opsi Kueri injeksi kesalahan ini mengambil parameter berikut: *percentage\$1of\$1failure* Persentase replikasi yang akan diblokir selama peristiwa kegagalan. Nilai ini dapat berupa double antara 0 dan 100. Jika Anda menetapkan 0, tidak ada replikasi yang akan diblokir. Jika Anda menetapkan 100, semua replikasi diblokir. *time\$1interval* Durasi waktu simulasi kegagalan Replika Aurora. Interval dalam detik. Misalnya, jika nilainya adalah 20, simulasi berjalan selama 20 detik. Berhati-hatilah saat menentukan interval waktu untuk peristiwa kegagalan Replika Aurora Anda. Jika Anda menentukan interval yang terlalu panjang, dan instans penulis Anda menulis data dalam jumlah besar selama peristiwa kegagalan, maka klaster DB Aurora Anda mungkin menganggap bahwa Replika Aurora telah crash lalu menggantinya. *replica\$1name* Replika Aurora tempat simulasi kegagalan akan diinjeksikan. Tentukan nama Replika Aurora untuk menyimulasikan kegagalan satu Replika Aurora. Tentukan string kosong untuk menyimulasikan kegagalan untuk semua Replika Aurora dalam klaster DB. Untuk mengidentifikasi nama replika, lihat kolom `server_id` dari fungsi `aurora_replica_status()`. Sebagai contoh: ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Menguji kegagalan disk Anda dapat menyimulasikan kegagalan disk untuk klaster DB Aurora PostgreSQL menggunakan fungsi kueri injeksi kesalahan `aurora_inject_disk_failure()`. Selama simulasi kegagalan disk, klaster DB Aurora PostgreSQL menandai secara acak segmen disk sebagai mengalami kesalahan. Permintaan untuk segmen tersebut diblokir selama durasi simulasi. **Sintaksis** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Opsi Kueri injeksi kesalahan ini mengambil parameter berikut: *percentage\$1of\$1failure* Persentase disk yang akan ditandai sebagai mengalami kesalahan selama peristiwa kegagalan. Nilai ini dapat berupa double antara 0 dan 100. Jika Anda menentukan 0, tidak ada disk yang akan ditandai sebagai mengalami kesalahan. Jika Anda menentukan 100, seluruh disk akan ditandai sebagai mengalami kesalahan. *indeks* Blok data logis tertentu tempat peristiwa kegagalan akan disimulasikan. Jika Anda melampaui rentang blok logis atau data simpul penyimpanan yang tersedia, Anda akan menerima pesan kesalahan yang memberitahukan nilai indeks maksimum yang dapat Anda tentukan. Untuk menghindari kesalahan ini, lihat [Menampilkan status volume untuk klaster DB Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Mengindikasikan apakah kegagalan injeksi terjadi pada blok logis atau simpul penyimpanan. Menentukan benar berarti kegagalan injeksi terjadi pada blok logis. Menentukan salah berarti kegagalan injeksi terjadi pada simpul penyimpanan. *time\$1interval* Jumlah waktu untuk mensimulasikan kegagalan disk. Interval dalam detik. Misalnya, jika nilainya adalah 20, simulasi berjalan selama 20 detik. ## Menguji kepadatan disk Anda dapat mensimulasikan kemacetan disk untuk cluster Aurora PostgreSQL DB dengan menggunakan fungsi query injeksi kesalahan. `aurora_inject_disk_congestion()` Selama simulasi kepadatan disk, klaster DB Aurora PostgreSQL secara acak menandai segmen disk sebagai padat. Permintaan untuk segmen tersebut ditunda antara waktu penundaan minimum dan maksimum yang ditentukan untuk durasi simulasi. **Sintaksis** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Opsi Kueri injeksi kesalahan ini mengambil parameter berikut: *percentage\$1of\$1failure* Persentase disk yang akan ditandai sebagai padat selama peristiwa kegagalan. Ini adalah nilai double antara 0 dan 100. Jika Anda menetapkan 0, tidak ada disk yang ditandai sebagai padat. Jika Anda menetapkan 100, seluruh disk akan ditandai sebagai padat. *indeks* Blok logis data atau simpul penyimpanan tertentu yang akan digunakan dalam simulasi peristiwa kegagalan. Jika Anda melampaui rentang blok logis atau simpul penyimpanan data yang tersedia, Anda akan menerima pesan kesalahan yang memberitahukan nilai indeks maksimum yang dapat Anda tentukan. Untuk menghindari kesalahan ini, lihat [Menampilkan status volume untuk klaster DB Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Mengindikasikan apakah kegagalan injeksi terjadi pada blok logis atau simpul penyimpanan. Menentukan benar berarti kegagalan injeksi terjadi pada blok logis. Menentukan salah berarti kegagalan injeksi terjadi pada simpul penyimpanan. *time\$1interval* Jumlah waktu untuk mensimulasikan kemacetan disk. Interval dalam detik. Misalnya, jika nilainya adalah 20, simulasi berjalan selama 20 detik. *minimum, maximum* Penundaan kepadatan minimum dan maksimum, dalam milidetik. Nilai yang valid berkisar dari 0,0 hingga 100,0 milidetik. Segmen disk yang ditandai padat akan ditunda selama jangka waktu acak dalam rentang durasi minimum dan maksimum untuk simulasi. Nilai maksimum harus lebih besar dari nilai minimum. # Menampilkan status volume untuk klaster DB Aurora PostgreSQL Di Amazon Aurora, volume klaster DB terdiri dari kumpulan blok logis. Masing-masing blok ini merepresentasikan 10 gigabyte penyimpanan yang dialokasikan. Blok-blok ini disebut *grup perlindungan*. Data di setiap grup perlindungan direplikasi di enam perangkat penyimpanan fisik, yang disebut *simpul penyimpanan*. Node penyimpanan ini dialokasikan di tiga Availability Zones (AZs) di wilayah tempat cluster DB berada. Pada gilirannya, setiap simpul penyimpanan berisi satu atau beberapa blok logis data untuk volume klaster DB. Untuk informasi selengkapnya tentang grup perlindungan dan node penyimpanan, lihat [Memperkenalkan mesin penyimpanan Aurora di Blog](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) AWS Database. Untuk mempelajari selengkapnya tentang volume klaster Aurora secara umum, lihat [Penyimpanan Amazon Aurora](Aurora.Overview.StorageReliability.md). Gunakan fungsi `aurora_show_volume_status()` untuk menghasilkan variabel status server berikut: + `Disks` — Jumlah total blok logis data untuk volume klaster DB. + `Nodes` **—** Jumlah total simpul penyimpanan untuk volume klaster DB. Anda dapat menggunakan fungsi `aurora_show_volume_status()` untuk membantu menghindari kesalahan saat menggunakan fungsi injeksi kesalahan `aurora_inject_disk_failure()`. Fungsi injeksi kesalahan `aurora_inject_disk_failure()` menyimulasikan kegagalan seluruh simpul penyimpanan atau satu blok logis data dalam simpul penyimpanan. Dalam fungsi tersebut, tentukan nilai indeks blok logis spesifik data atau simpul penyimpanan. Namun, pernyataan tersebut akan menghasilkan kesalahan jika Anda menentukan nilai indeks yang lebih besar dari jumlah blok logis data atau simpul penyimpanan yang digunakan oleh volume klaster DB. Untuk informasi selengkapnya tentang kueri injeksi kesalahan, lihat [Menguji Amazon Aurora PostgreSQL menggunakan kueri injeksi kesalahan](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **catatan** Fungsi `aurora_show_volume_status()` tersedia untuk Aurora PostgreSQL versi 10.11. Untuk informasi selengkapnya tentang versi Aurora PostgreSQL, lihat [Versi rilis dan mesin Amazon Aurora PostgreSQL](AuroraPostgreSQL.Updates.20180305.md). **Sintaksis** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Contoh** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # Menentukan disk RAM untuk stats\$1temp\$1directory Anda dapat menggunakan parameter Aurora PostgreSQL, `rds.pg_stat_ramdisk_size`, untuk menentukan memori sistem yang dialokasikan ke disk RAM untuk menyimpan `stats_temp_directory` PostgreSQL. Parameter disk RAM hanya tersedia di Aurora PostgreSQL 14 dan versi lebih rendah. Di bawah beban kerja tertentu, pengaturan parameter ini dapat meningkatkan performa dan menurunkan kebutuhan IO. Untuk informasi selengkapnya tentang `stats_temp_directory`, lihat [Run-time Statistics](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) dalam dokumentasi PostgreSQL. Mulai PostgreSQL versi 15, komunitas PostgreSQL beralih menggunakan memori bersama dinamis. Jadi, `stats_temp_directory` tidak perlu diatur. Untuk mengaktifkan disk RAM untuk `stats_temp_directory` Anda, setel parameter `rds.pg_stat_ramdisk_size` ke nilai bukan nol di grup parameter klaster DB yang digunakan oleh klaster DB Anda. Parameter ini menunjukkan MB, jadi Anda harus menggunakan nilai bilangan bulat. Ekspresi, rumus, dan fungsi tidak valid untuk parameter `rds.pg_stat_ramdisk_size`. Pastikan untuk memulai ulang klaster DB agar perubahan diterapkan. Untuk informasi tentang mengatur parameter, lihat [](USER_WorkingWithParamGroups.md). Untuk informasi selengkapnya tentang memulai ulang klaster DB, lihat [Mem-boot ulang klaster DB Amazon Aurora atau instans DB Amazon Aurora](USER_RebootCluster.md). Sebagai contoh, AWS CLI perintah berikut menetapkan parameter disk RAM ke 256 MB. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Setelah Anda memulai ulang klaster DB, jalankan perintah berikut untuk melihat status `stats_temp_directory`: ``` postgres=> SHOW stats_temp_directory; ``` Perintah tersebut akan menghasilkan hal berikut: ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Mengelola file sementara dengan PostgreSQL Di PostgreSQL, kueri kompleks mungkin melakukan beberapa operasi pengurutan atau hash pada saat yang sama, dengan setiap operasi menggunakan memori instance untuk menyimpan hasil hingga nilai yang ditentukan dalam parameter. [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) Jika memori instans tidak cukup, file sementara akan dibuat untuk menyimpan hasil. Hasil ini ditulis ke disk untuk menyelesaikan eksekusi kueri. Kemudian, file-file ini secara otomatis dihapus setelah kueri selesai. Dalam Aurora PostgreSQL, file ini berbagi penyimpanan lokal dengan file log lainnya. Anda dapat memantau ruang penyimpanan lokal klaster PostgreSQL DB Aurora Anda dengan menonton metrik Amazon. CloudWatch `FreeLocalStorage` Untuk informasi selengkapnya, lihat [Memecahkan masalah penyimpanan lokal](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/). Sebaiknya gunakan Aurora Optimized instans cluster untuk beban kerja yang melibatkan beberapa kueri bersamaan yang meningkatkan penggunaan file sementara. Cluster ini menggunakan penyimpanan tingkat blok solid state drive (SSDNVMe) berbasis Non-Volatile Memory Express () lokal untuk menempatkan file sementara. Untuk informasi selengkapnya, lihat [Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md). Anda dapat menggunakan parameter dan fungsi berikut untuk mengelola file sementara dalam instans Anda. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – Parameter ini membatalkan kueri apa pun yang melebihi ukuran temp\$1files dalam KB. Batas ini mencegah kueri apa pun berjalan tanpa henti dan menghabiskan ruang disk dengan file sementara. Anda dapat memperkirakan nilai menggunakan hasil dari parameter `log_temp_files`. Sebagai praktik terbaik, periksa perilaku beban kerja dan tetapkan batas sesuai dengan estimasi. Contoh berikut menunjukkan bagaimana kueri dibatalkan saat melampaui batas. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – Parameter ini mengirimkan pesan ke postgresql.log ketika file sementara dari sebuah sesi dihapus. Parameter ini menghasilkan log setelah kueri berhasil diselesaikan. Oleh karena itu, ini mungkin tidak membantu dalam memecahkan masalah kueri yang aktif dan berjalan lama. Contoh berikut menunjukkan bahwa ketika kueri berhasil diselesaikan, entri dicatat dalam file postgresql.log, sedangkan file sementara dibersihkan. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – Fungsi yang tersedia dari RDS untuk PostgreSQL 13 dan versi yang lebih baru ini memberikan visibilitas terhadap penggunaan file sementara saat ini. Kueri yang sudah selesai tidak muncul di hasil fungsi. Dalam contoh berikut, Anda dapat melihat hasil dari fungsi ini. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` Nama file mencakup ID pemrosesan (PID) dari sesi yang menghasilkan file sementara. Kueri yang lebih maju, seperti pada contoh berikut, melakukan penjumlahan file sementara untuk setiap PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – Jika Anda mengaktifkan parameter pg\$1stat\$1statements, Anda dapat melihat rata-rata penggunaan file sementara per panggilan. Anda dapat mengidentifikasi query\$1id dari kueri dan menggunakannya untuk memeriksa penggunaan file sementara seperti yang ditunjukkan pada contoh berikut. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** – Di dasbor Wawasan Performa, Anda dapat melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes** dan **temp\$1files**. Kemudian, Anda dapat melihat rata-rata kedua metrik ini dan melihat sejauh mana kesesuaiannya dengan beban kerja kueri. Tampilan dalam Wawasan Performa tidak secara khusus menampilkan kueri yang menghasilkan file sementara. Namun, jika Anda menggabungkan Wawasan Performa dengan kueri yang ditampilkan untuk `pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri. Untuk informasi selengkapnya tentang cara menganalisis metrik dan kueri dengan Performance Insights, lihat. [Menganalisis metrik dengan dasbor Wawasan Performa](USER_PerfInsights.UsingDashboard.md) Untuk contoh melihat penggunaan file sementara dengan Performance Insights, lihat [Melihat penggunaan file sementara dengan Performance Insights](PostgreSQL.ManagingTempFiles.Example.md) # Melihat penggunaan file sementara dengan Performance Insights **Anda dapat menggunakan Performance Insights untuk melihat penggunaan file sementara dengan mengaktifkan metrik **temp\$1bytes dan temp\$1files**.** Tampilan di Performance Insights tidak menampilkan kueri spesifik yang menghasilkan file sementara, namun jika Anda menggabungkan Performance Insights dengan kueri yang ditampilkan`pg_ls_tmpdir`, Anda dapat memecahkan masalah, menganalisis, dan menentukan perubahan dalam beban kerja kueri. 1. Di dasbor Wawasan Performa, pilih **Kelola Metrik**. 1. Pilih **Metrik basis data**, lalu pilih metrik **temp\$1bytes** dan **temp\$1files** seperti yang ditunjukkan pada gambar berikut. ![\[Metrik ditampilkan dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. Di tab **SQL Teratas**, pilih ikon **Preferensi**. 1. Di jendela **Preferensi**, aktifkan statistik berikut agar muncul di tab **SQL Teratas** dan pilih **Lanjutkan**. + Temp writes/detik + Temp reads/detik + Tmp blk write/panggilan + Tmp blk read/panggilan 1. File sementara rusak saat digabungkan kueri yang ditampilkan untuk `pg_ls_tmpdir`, seperti yang ditunjukkan pada contoh berikut. ![\[Kueri yang menampilkan penggunaan file sementara.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Peristiwa `IO:BufFileRead` dan `IO:BufFileWrite` terjadi ketika kueri teratas di beban kerja Anda sering membuat file sementara. Anda dapat menggunakan Wawasan Performa untuk mengidentifikasi kueri teratas yang menunggu pada `IO:BufFileRead` dan `IO:BufFileWrite` dengan meninjau Sesi Aktif Rata-rata (AAS) di bagian Muatan Basis Data dan SQL Teratas. ![\[IO: BufFileRead dan IO: BufFileWrite dalam grafik.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Untuk informasi selengkapnya tentang cara menganalisis kueri teratas dan muatan berdasarkan peristiwa tunggu dengan Wawasan Performa, lihat [Ikhtisar SQL tab Top](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Anda harus mengidentifikasi dan menyetel kueri yang menyebabkan peningkatan penggunaan file sementara dan peristiwa tunggu terkait. Untuk informasi lebih lanjut tentang peristiwa tunggu dan remediasi ini, lihat [: BufFileRead dan IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **catatan** Parameter [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) mengontrol ketika operasi pengurutan kehabisan memori dan hasilnya ditulis ke dalam file sementara. Sebaiknya Anda tidak mengubah pengaturan parameter ini lebih tinggi dari nilai default karena akan memungkinkan setiap sesi basis data mengonsumsi lebih banyak memori. Selain itu, satu sesi yang melakukan penggabungan dan pengurutan kompleks dapat melakukan operasi paralel di mana setiap operasi mengonsumsi memori. Sebagai praktik terbaik, ketika Anda memiliki laporan besar dengan beberapa penggabungan dan pengurutan, atur parameter ini pada tingkat sesi dengan menggunakan perintah `SET work_mem`. Kemudian, perubahan hanya diterapkan pada sesi saat ini dan tidak mengubah nilai secara global.