Konsep penting dalam penyetelan RDS for PostgreSQL - Layanan Basis Data Relasional Amazon
Peristiwa tunggu RDS for PostgreSQLMemori RDS for PostgreSQLProses RDS for PostgreSQL

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

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.

Peristiwa tunggu RDS for PostgreSQL

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 akan menunggu I/O disk 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 baris yang telah dikunci oleh sesi lain, Anda dapat mengakhiri sesi penguncian ini.

Memori RDS for PostgreSQL

Memori RDS for PostgreSQL dibagi menjadi bersama dan lokal.

Memori bersama dalam RDS for PostgreSQL

RDS for PostgreSQL mengalokasikan memori bersama saat instans dimulai. Memori bersama dibagi menjadi beberapa subarea. Anda dapat menemukan deskripsi untuk yang paling penting berikut ini.

Buffer bersama

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 susunan 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.

Buffer log write ahead (WAL)

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

  • Mengurangi disk I/O dengan menghindari penulisan ke disk yang sering

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.

Parameter wal_level menentukan berapa banyak informasi yang ditulis ke WAL.

Memori lokal dalam RDS for PostgreSQL

Setiap proses backend mengalokasikan memori lokal untuk pemrosesan kueri.

Area memori kerja

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.

Parameter work_mem jumlah memori yang akan digunakan oleh operasi pengurutan internal dan tabel hash sebelum menulis ke file disk sementara. 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

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

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

Area buffer sementara

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.

Parameter temp_buffers mengatur jumlah maksimum buffer sementara yang digunakan oleh setiap sesi. Sebelum penggunaan pertama tabel sementara dalam sesi, Anda dapat mengubah nilai temp_buffers.

Proses RDS for PostgreSQL

RDS for PostgreSQL menggunakan beberapa proses.

Proses postmaster

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 mereka sebelum mengizinkan basis data untuk melayani permintaan

Proses backend

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

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 membuat sejumlah besar lalu lintas I/O, yang dapat menyebabkan kinerja buruk untuk sesi aktif lainnya.