Konsep penting untuk penyetelan Aurora PostgreSQL

Sebelum Anda menyetel basis data Aurora PostgreSQL, pastikan untuk mempelajari apa itu peristiwa tunggu dan mengapa itu terjadi. Juga tinjau memori dasar dan arsitektur disk Aurora PostgreSQL. Untuk diagram arsitektur yang bermanfaat, lihat wikibook PostgreSQL.

Peristiwa tunggu Aurora PostgreSQL

Peristiwa tunggu menunjukkan sumber daya yang sedang menunggu sesi. Misalnya, peristiwa tunggu Client:ClientRead terjadi ketika Aurora PostgreSQL menunggu untuk menerima data dari klien. Sumber daya khas yang ditunggu sesi meliputi yang berikut:

• Akses single-threaded ke buffer, misalnya, saat sesi mencoba mengubah 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 kejadian tunggu dengan menggunakan peristiwa tunggu yang telah ditentukan sebelumnya. Peristiwa tersebut dikelompokkan ke dalam kategori.

Peristiwa tunggu tidak dengan sendirinya menunjukkan masalah kinerja. Misalnya, jika data yang diminta tidak ada dalam memori, membaca data dari disk diperlukan. Jika satu sesi mengunci baris untuk pembaruan, sesi lain menunggu baris dibuka sehingga dapat memperbaruinya. Commit perlu menunggu penulisan ke file log selesai. Peristiwa tunggu merupakan bagian integral dari fungsi normal basis data.

Sejumlah besar peristiwa tunggu biasanya menunjukkan masalah kinerja. 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 kinerja. Misalnya, jika sesi Anda menunggu pada baris yang telah dikunci oleh sesi lain, Anda dapat mengakhiri sesi penguncian.

Memori Aurora PostgreSQL

Memori Aurora PostgreSQL dibagi menjadi bersama dan lokal.

Topik

• Memori bersama di Aurora PostgreSQL
• Memori lokal di Aurora PostgreSQL

Memori bersama di Aurora PostgreSQL

Aurora PostgreSQL mengalokasikan memori bersama saat instans dimulai. Memori bersama dibagi menjadi beberapa subarea. Setelah itu, Anda dapat menemukan deskripsi yang paling penting.

Topik

• Buffer bersama
• Buffer log write ahead (WAL)

Buffer bersama

Kolam buffer bersama adalah area memori Aurora PostgreSQL yang menampung semua halaman yang sedang atau telah digunakan oleh koneksi aplikasi. Halaman adalah versi memori dari blok disk. Kolam buffer bersama menyimpan blok data yang dibaca dari disk. Kumpulan tersebut mengurangi kebutuhan untuk membaca ulang data dari disk, 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.

Kolam buffer bersama memiliki memori terbatas. Jika permintaan baru memerlukan halaman yang tidak ada dalam memori, dan tidak ada lagi memori, Aurora 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 mendedikasikan untuk caching data.

Buffer log write ahead (WAL)

Buffer log write-ahead (WAL) menyimpan data transaksi yang kemudian ditulis Aurora PostgreSQL ke penyimpanan persisten. Menggunakan mekanisme WAL, Aurora PostgreSQL dapat melakukan hal berikut:

• Memulihkan data setelah kegagalan

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

Ketika klien mengubah data, Aurora 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 di Aurora PostgreSQL

Setiap proses backend mengalokasikan memori lokal untuk pemrosesan kueri.

Topik

• Area memori kerja
• Area memori kerja pemeliharaan
• Area buffer sementara

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 Aurora PostgreSQL

Aurora PostgreSQL menggunakan beberapa proses.

Topik

• Proses postmaster
• Proses backend
• Proses latar belakang

Proses postmaster

Proses postmaster adalah proses pertama yang dimulai ketika Anda memulai Aurora 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

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