Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Konsep penting dalam penyetelan RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts"></a>

Sebelum Anda menyetel basis data RDS for PostgreSQL, pastikan untuk mempelajari apa itu peristiwa tunggu dan mengapa peristiwa tersebut terjadi. Baca juga memori dasar dan arsitektur disk RDS for PostgreSQL. Anda dapat melihat diagram arsitektur yang berguna di wikibook [PostgreSQL](https://en.wikibooks.org/wiki/PostgreSQL/Architecture).

**Topics**
+ [Peristiwa tunggu RDS for PostgreSQL](PostgreSQL.Tuning.concepts.waits.md)
+ [Memori RDS for PostgreSQL](PostgreSQL.Tuning.concepts.memory.md)
+ [Proses RDS for PostgreSQL](PostgreSQL.Tuning.concepts.processes.md)

# Peristiwa tunggu RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts.waits"></a>

*Peristiwa tunggu* menunjukkan bahwa sesi sedang menunggu sumber daya. Misalnya, peristiwa tunggu `Client:ClientRead` terjadi ketika RDS for PostgreSQL menunggu untuk menerima data dari klien. Sesi biasanya menunggu sumber daya seperti berikut ini.
+ Akses thread tunggal ke buffer, misalnya, saat sesi mencoba memodifikasi buffer
+ Baris yang saat ini dikunci oleh sesi lain
+ Pembacaan file data
+ Penulisan file log

Misalnya, untuk memenuhi kueri, sesi mungkin melakukan pemindaian tabel lengkap. Jika data belum ada dalam memori, sesi menunggu disk I/O selesai. Ketika buffer dibaca ke dalam memori, sesi mungkin perlu menunggu karena sesi lain mengakses buffer yang sama. Basis data mencatat peristiwa tunggu dengan menggunakan peristiwa tunggu standar. Peristiwa tersebut dikelompokkan ke dalam kategori.

Dengan sendirinya, satu peristiwa tunggu tidak menunjukkan masalah performa. Misalnya, jika data yang diminta tidak ada dalam memori, data perlu dibaca dari disk. Jika satu sesi mengunci baris untuk pembaruan, sesi lain akan menunggu baris tersebut dibuka sehingga dapat memperbaruinya. Komit perlu menunggu penulisan ke file log selesai. Peristiwa tunggu merupakan bagian integral dari fungsi normal basis data. 

Di sisi lain, sejumlah besar peristiwa tunggu biasanya menunjukkan masalah performa. Dalam kasus seperti itu, Anda dapat menggunakan data peristiwa tunggu untuk menentukan tempat sesi menghabiskan waktu. Misalnya, jika laporan yang biasanya berjalan dalam hitungan menit sekarang berjalan selama berjam-jam, Anda dapat mengidentifikasi peristiwa tunggu yang berkontribusi paling besar terhadap total waktu tunggu. Jika Anda dapat menentukan penyebab peristiwa tunggu teratas, terkadang Anda dapat membuat perubahan yang meningkatkan performa. Misalnya, jika sesi Anda menunggu pada baris yang telah dikunci oleh sesi lain, Anda dapat mengakhiri sesi penguncian. 

# Memori RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts.memory"></a>

Memori RDS for PostgreSQL dibagi menjadi bersama dan lokal.

**Topics**
+ [Memori bersama dalam RDS for PostgreSQL](#PostgreSQL.Tuning.concepts.shared)
+ [Memori lokal dalam RDS for PostgreSQL](#PostgreSQL.Tuning.concepts.local)

## Memori bersama dalam RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts.shared"></a>

RDS for PostgreSQL mengalokasikan memori bersama saat instans dimulai. Memori bersama dibagi menjadi beberapa sub-area. Bagian berikut memberikan deskripsi yang paling penting.

**Topics**
+ [Buffer bersama](#PostgreSQL.Tuning.concepts.buffer-pool)
+ [Buffer log write ahead (WAL)](#PostgreSQL.Tuning.concepts.WAL)

### Buffer bersama
<a name="PostgreSQL.Tuning.concepts.buffer-pool"></a>

*Kumpulan buffer bersama* adalah area memori RDS for PostgreSQL yang menampung semua halaman yang sedang atau telah digunakan oleh koneksi aplikasi. *Halaman* adalah versi memori dari blok disk. Kumpulan buffer bersama menyimpan blok data yang dibaca dari disk. Kumpulan tersebut mengurangi kebutuhan untuk membaca ulang data dari disk, sehingga membuat basis data beroperasi lebih efisien.

Setiap tabel dan indeks disimpan sebagai array halaman dengan ukuran tetap. Setiap blok berisi beberapa tuple, yang sesuai dengan baris. Tuple dapat disimpan di halaman mana pun.

Kumpulan buffer bersama memiliki memori terbatas. Jika permintaan baru memerlukan halaman yang tidak ada dalam memori, dan memori sudah tidak ada lagi, RDS for PostgreSQL mengosongkan halaman yang jarang digunakan untuk mengakomodasi permintaan tersebut. Kebijakan pengosongan diimplementasikan oleh algoritma clock sweep.

Parameter `shared_buffers` menentukan berapa banyak memori server dikhususkan untuk menyimpan data dalam cache. Nilai default diatur ke `{DBInstanceClassMemory/32768}` byte, berdasarkan memori yang tersedia untuk instans DB.

### Buffer log write ahead (WAL)
<a name="PostgreSQL.Tuning.concepts.WAL"></a>

*Buffer log write-ahead (WAL)* menyimpan data transaksi yang kemudian ditulis RDS for PostgreSQL ke penyimpanan persisten. Menggunakan mekanisme WAL, RDS for PostgreSQL dapat melakukan hal berikut:
+ Memulihkan data setelah kegagalan
+ Kurangi disk I/O dengan menghindari sering menulis ke disk

Ketika klien mengubah data, RDS for PostgreSQL menulis perubahan ke buffer WAL. Ketika klien mengeluarkan `COMMIT`, proses penulis WAL menulis data transaksi ke file WAL.

`wal_level`Parameter menentukan berapa banyak informasi yang ditulis ke WAL, dengan nilai yang mungkin seperti`minimal`,`replica`, dan`logical`.

## Memori lokal dalam RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts.local"></a>

Setiap proses backend mengalokasikan memori lokal untuk pemrosesan kueri.

**Topics**
+ [Area memori kerja](#PostgreSQL.Tuning.concepts.local.work_mem)
+ [Area memori kerja pemeliharaan](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem)
+ [Area buffer sementara](#PostgreSQL.Tuning.concepts.temp)

### Area memori kerja
<a name="PostgreSQL.Tuning.concepts.local.work_mem"></a>

*Area memori kerja* menyimpan data sementara untuk kueri yang melakukan pengurutan dan hash. Misalnya, kueri dengan klausa `ORDER BY` melakukan pengurutan. Kueri menggunakan tabel hash dalam gabungan dan agregasi hash.

`work_mem`Parameter jumlah memori yang akan digunakan oleh operasi pengurutan internal dan tabel hash sebelum menulis ke file disk sementara, diukur dalam megabyte. Nilai default-nya adalah 4 MB. Beberapa sesi dapat berjalan secara bersamaan, dan setiap sesi dapat menjalankan operasi pemeliharaan secara paralel. Karena alasan ini, total memori kerja yang digunakan dapat menjadi kelipatan dari pengaturan `work_mem`. 

### Area memori kerja pemeliharaan
<a name="PostgreSQL.Tuning.concepts.local.maintenance_work_mem"></a>

*Area memori kerja pemeliharaan* menyimpan data untuk operasi pemeliharaan. Operasi ini termasuk memvakum, membuat indeks, dan menambahkan kunci asing.

`maintenance_work_mem`Parameter menentukan jumlah maksimum memori yang akan digunakan oleh operasi pemeliharaan, diukur dalam megabyte. Nilai default-nya adalah 64 MB. Sebuah sesi basis data hanya dapat menjalankan satu operasi pemeliharaan dalam satu waktu.

### Area buffer sementara
<a name="PostgreSQL.Tuning.concepts.temp"></a>

*Area buffer sementara* menyimpan tabel sementara untuk setiap sesi basis data.

Setiap sesi mengalokasikan buffer sementara sesuai kebutuhan hingga batas yang Anda tentukan. Saat sesi berakhir, server menghapus buffer.

`temp_buffers`Parameter menetapkan jumlah maksimum buffer sementara yang digunakan oleh setiap sesi, diukur dalam megabyte. Nilai defaultnya adalah 8 MB. Sebelum penggunaan pertama tabel sementara dalam sesi, Anda dapat mengubah nilai `temp_buffers`.

# Proses RDS for PostgreSQL
<a name="PostgreSQL.Tuning.concepts.processes"></a>

RDS for PostgreSQL menggunakan beberapa proses.

**Topics**
+ [Proses postmaster](#PostgreSQL.Tuning.concepts.postmaster)
+ [Proses backend](#PostgreSQL.Tuning.concepts.backend)
+ [Proses latar belakang](#PostgreSQL.Tuning.concepts.vacuum)

## Proses postmaster
<a name="PostgreSQL.Tuning.concepts.postmaster"></a>

*Proses postmaster* adalah proses pertama yang dimulai ketika Anda memulai RDS for PostgreSQL. Proses postmaster memiliki tanggung jawab utama berikut:
+ Membagi dan memantau proses latar belakang
+ Menerima permintaan autentikasi dari proses klien, dan mengautentikasi permintaan sebelum mengizinkan basis data untuk melayani permintaan

## Proses backend
<a name="PostgreSQL.Tuning.concepts.backend"></a>

Jika postmaster mengautentikasi permintaan klien, postmaster akan melakukan proses backend baru, juga disebut proses postgres. Satu proses klien terhubung ke persis satu proses backend. Proses klien dan proses backend berkomunikasi secara langsung tanpa intervensi oleh proses postmaster.

## Proses latar belakang
<a name="PostgreSQL.Tuning.concepts.vacuum"></a>

Proses postmaster membagi beberapa proses yang melakukan tugas backend yang berbeda. Beberapa hal yang lebih penting termasuk berikut ini:
+ Penulis WAL

  RDS for PostgreSQL menulis data dalam buffer WAL (log write ahead) ke file log. Prinsip log write ahead adalah bahwa basis data tidak dapat menulis perubahan pada file data sampai setelah basis data menulis catatan log yang menjelaskan perubahan tersebut ke disk. Mekanisme WAL mengurangi disk I/O, dan memungkinkan RDS for PostgreSQL untuk menggunakan log untuk memulihkan basis data setelah kegagalan.
+ Penulis latar belakang

  Proses ini secara berkala menulis halaman kotor (diubah) dari buffer memori ke file data. Sebuah halaman menjadi kotor ketika proses backend memodifikasinya dalam memori.
+ Daemon autovacuum

  Daemon terdiri dari hal-hal berikut:
  + Peluncur autovacuum
  + Proses pekerja autovacuum

  Saat autovacuum diaktifkan, autovacuum tersebut memeriksa tabel yang memiliki banyak tuple yang dimasukkan, diperbarui, atau dihapus. Daemon memiliki tanggung jawab sebagai berikut:
  + Memulihkan atau menggunakan kembali ruang disk yang ditempati oleh baris yang diperbarui atau dihapus
  + Memperbarui statistik yang digunakan oleh perencana
  + Melindungi dari kehilangan data lama karena wraparound ID transaksi

  Fitur autovacuum mengotomatiskan eksekusi `VACUUM` dan perintah `ANALYZE`. `VACUUM` memiliki varian berikut: standar dan penuh. Vakum standar berjalan secara paralel dengan operasi basis data lainnya. `VACUUM FULL` membutuhkan kunci eksklusif di tabel yang sedang dikerjakannya. Dengan demikian, tidak dapat berjalan secara paralel dengan operasi yang mengakses tabel yang sama. `VACUUM`menciptakan sejumlah besar I/O lalu lintas, yang dapat menyebabkan kinerja yang buruk untuk sesi aktif lainnya.