Mengoptimalkan performa database dengan membandingkan snapshot performa

Untuk mengidentifikasi dan mengurangi masalah performa database AlloyDB untuk PostgreSQL, Anda dapat membandingkan snapshot metrik sistem antara dua titik waktu dengan membuat laporan snapshot performa secara manual. Metrik sistem yang diambil di setiap snapshot mencakup penggunaan CPU virtual (vCPU), penggunaan memori, I/O disk, jumlah transaksi, dan peristiwa tunggu.

Snapshot otomatis dan manual

AlloyDB mendukung snapshot berikut:

  • Snapshot otomatis: Secara default, AlloyDB otomatis mengambil snapshot sekali sehari dan menyimpan snapshot selama 7 hari. Snapshot otomatis membantu membuat laporan dengan granularitas workload harian. Anda dapat mengonfigurasi frekuensi dan retensi snapshot otomatis.

  • Snapshot manual: Anda dapat mengambil snapshot dan membuat laporan secara manual.

Anda dapat menggabungkan snapshot otomatis dan manual untuk membuat laporan performa. Misalnya, Anda dapat membuat laporan snapshot performa yang membandingkan snapshot yang dibuat secara manual dengan snapshot otomatis.

Dokumen ini menjelaskan cara membuat laporan snapshot performa secara manual.

Cara kerja laporan snapshot performa

Laporan snapshot performa adalah alat bawaan AlloyDB yang mengambil dan menganalisis data performa untuk membantu Anda mengidentifikasi penyebab masalah performa. Alat ini melengkapi fitur observabilitas AlloyDB lainnya seperti insight sistem, insight kueri, dan Metrics Explorer, yang menyediakan metrik real-time tentang instance Anda.

Laporan snapshot performa menampilkan metrik database antara dua stempel waktu dalam satu laporan. Anda dapat menggunakan informasi laporan snapshot performa untuk mengidentifikasi masalah performa dengan instance laporan snapshot performa Anda, seperti penurunan performa database selama waktu tertentu dalam sehari atau penurunan performa selama jangka waktu tertentu. Saat digunakan pada node kumpulan baca, laporan ini membantu mengidentifikasi apakah latensi replikasi disebabkan oleh batasan resource sistem, seperti CPU atau memori, atau konflik kueri tertentu, seperti pin buffer.

Dengan menggunakan laporan snapshot performa, Anda membandingkan metrik dengan dasar pengukuran performa untuk mendapatkan insight tentang metrik performa workload, yang dapat Anda gunakan untuk mengoptimalkan atau memecahkan masalah performa database. Dasar pengukuran adalah kumpulan snapshot database yang disesuaikan yang mengukur performa dan perilaku standar database untuk konfigurasi dan workload tertentu.

Untuk mengetahui informasi tentang peristiwa tunggu dalam laporan snapshot performa, lihat Referensi laporan snapshot performa database.

Peran yang diperlukan

Pastikan Anda memiliki peran alloydbsuperuser. Secara default, AlloyDB memberikan peran pg_monitor kepada alloydbsuperuser. Untuk mengetahui informasi selengkapnya, lihat Peran bawaan PostgreSQL.

Jika Anda lebih suka menggunakan peran lain yang ditentukan sendiri, jalankan GRANT pg_monitor TO my_user sebagai alloydbsuperuser terlebih dahulu. Untuk mengetahui informasi selengkapnya, lihat Memperbarui akun Identity and Access Management (IAM) dengan peran yang sesuai.

Membuat snapshot

Snapshot performa adalah alat yang efektif untuk memahami dan mengoptimalkan performa database Anda. Snapshot ini mengambil metrik sistem utama pada titik waktu tertentu, sehingga Anda dapat membandingkan performa database antara dua titik waktu. AlloyDB mendukung dua jenis snapshot:

  • Snapshot metrik sistem: snapshot ini mengambil metrik sistem utama seperti penggunaan vCPU, penggunaan memori, dan I/O disk.
  • Snapshot metrik sistem dan statistik eksekusi SQL: snapshot ini berisi semua metrik sistem dari snapshot standar, ditambah statistik eksekusi SQL mendetail dari ekstensi pg_stat_statements.

Hal ini memberi Anda fleksibilitas untuk memilih tingkat detail yang Anda butuhkan untuk analisis.

Membuat snapshot metrik sistem

Buat snapshot di awal dan akhir workload yang Anda minati. Interval waktu antara kedua snapshot harus cukup panjang untuk mengambil sampel workload yang representatif.

Ikuti langkah-langkah berikut untuk mengoptimalkan performa database AlloyDB:

  1. Buat snapshot dasar pengukuran saat database Anda tidak ada aktivitas atau saat database mengalami beban rata-rata.
  2. Hubungkan klien psql ke instance AlloyDB. Untuk node kumpulan baca, Anda harus terhubung langsung ke alamat IP-nya. Untuk mengetahui informasi selengkapnya, lihat mengambil daftar alamat IP node Kumpulan Baca.

  3. Jalankan SELECT perfsnap.snap(). Outputnya akan terlihat mirip seperti berikut:

    postgres=# select perfsnap.snap();
 snap
------
    1
(1 row)

    Output perintah ini menampilkan ID snapshot (snap_id), yang merupakan 1 dalam contoh ini. Anda memerlukan ID ini untuk membuat laporan snapshot performa nanti. snap_id di lingkungan Anda sendiri kemungkinan berbeda.

  4. Bandingkan laporan yang Anda buat dengan kedua kumpulan snapshot dan identifikasi perubahan yang mungkin meningkatkan performa. Untuk mengetahui informasi selengkapnya tentang rekomendasi performa, lihat Rekomendasi pengoptimalan performa database.

Setelah mendapatkan metrik dari laporan snapshot performa yang dihasilkan, Anda dapat mengambil kumpulan snapshot lain dan mengulangi prosesnya.

Membuat snapshot yang berisi statistik eksekusi SQL

Secara default, AlloyDB menggunakan ekstensi pg_stat_statements untuk melacak pernyataan SQL. Untuk menyertakan statistik eksekusi SQL mendetail dalam laporan performa, Anda harus membuat ekstensi pg_stat_statements di database postgres terlebih dahulu. Perhatikan bahwa pengambilan statistik ini diaktifkan oleh flag pg_stat_statements.track, bukan oleh pembuatan ekstensi itu sendiri.

Untuk membuat snapshot yang juga berisi statistik eksekusi SQL, ikuti langkah-langkah berikut:

  1. Buat ekstensi pg_stat_statements di database postgres.

    postgres=# CREATE EXTENSION pg_stat_statements;
  2. Sekarang, saat Anda mengambil snapshot, snapshot tersebut akan otomatis menyertakan statistik SQL dari pg_stat_statements. 
      postgres=# select perfsnap.snap();
    snap
  ------
      2
  (1 row)

Melihat daftar snapshot

  1. Hubungkan klien psql ke instance AlloyDB. Untuk node kumpulan baca, Anda harus terhubung langsung ke alamat IP-nya menggunakan psql. Untuk mengetahui informasi selengkapnya, lihat mengambil daftar alamat IP node Kumpulan Baca.
  2. Jalankan SELECT * FROM perfsnap.g$snapshots. Outputnya akan terlihat mirip seperti berikut: 
    postgres=# select * from perfsnap.g$snapshots;
 snap_id |           snap_time           | instance_id  |               node_id           | snap_description  | snap_type | is_baseline
---------+-------------------------------+--------------+---------------------------------+-------------------+-----------+-------------
       1 | 2023-11-13 22:13:43.159237+00 | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Manual snapshot   | Manual    | f
       2 | 2023-11-13 22:53:40.49565+00  | perf-primary | sab3-perf-primary-cab835ef-4cm8 | Automatic snapshot| Automatic | f
       3 | 2023-11-13 22:56:42.57094+00  | perf-replica | sab3-perf-replica-b9250422-tz4n | Automatic snapshot| Automatic | f
       4 | 2023-11-13 22:56:42.59476+00  | perf-replica | sab3-perf-replica-b9250422-63q3 | Automatic snapshot| Automatic | f
       5 | 2023-11-13 23:11:55.23157+00  | perf-replica | sab3-perf-replica-b9250422-tz4n | Manual snapshot   | Manual    | f
(5 rows)

Membuat laporan snapshot performa

Untuk membuat laporan yang mengambil perbedaan antara dua snapshot, misalnya, snapshot 1 dan 2, jalankan: 
SELECT perfsnap.report(1,2)

Snapshot kedua dalam operasi diferensial tidak harus segera mengikuti snapshot pertama. Namun, pastikan Anda mengambil snapshot kedua dalam diferensial setelah snapshot pertama.

Laporan snapshot performa yang dibuat akan terlihat mirip dengan contoh singkat berikut.

Contoh laporan

Berikut adalah contoh singkat laporan snapshot performa yang dibuat:

Contoh laporan snapshot performa

$ psql -d postgres -U alloydbsuperuser
postgres=> select perfsnap.report(22, 23);

report
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 PGSNAP DB Report for:

 Snapshot details
 --------------------------------------
 Host                   i841-sr-primary-2a34f46e-06bc
 Release                14.12
 Startup Time           2024-10-08 03:23:15+00

              Snap Id    Snap Time
 ------------ ---------- ------------------------
 Begin Snap:          22 24.10.2024 04:33:56 (UTC) Automatic snapshot
   End Snap:          23 25.10.2024 04:38:56 (UTC) Automatic snapshot
    Elapsed:                      1 day 00:04:59.979321

 Database Cache sizes
 ~~~~~~~~~~~~~
            Shared Buffers:       31 GB        Block Size:         8192
      Effective Cache Size:       25 GB       WAL Buffers:        16384

 Host CPU
 ~~~~~~~~~~
       %User   %Nice %System   %Idle    %WIO    %IRQ   %SIRQ  %Steal  %Guest
     ------- ------- ------- ------- ------- ------- ------- ------- -------
        1.07    0.22    0.91   97.40    0.09    0.00    0.31    0.00    0.00

 Host Memory
 ~~~~~~~~~~~~
              Total Memory:       63 GB
          Available Memory:       11 GB
               Free Memory:      726 MB
            Buffers Memory:     3706 MB

 Load profile (in bytes)
 ~~~~~~~~~~~~~~~~~~~~~~~            Per Second         Per Transaction
                                    ------------       ---------------
                     Redo size:         63083.64               4489.93
                 Logical reads:          1961.21                139.59
                 ...

 Response Time Profile (in s)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 CPU time:               5399 (   0.39%)
 Wait time:           1386906 (  99.61%)
 Total time:           1392306

 Backend Processes Wait Class Breakdown (in s)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 IO                   119.300 (  98.91%)
 LWLock                 1.305 (   1.08%)
 IPC                     .010 (   0.01%)
 Lock                    .000 (   0.00%)

 Backend Processes Wait Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Event                                          Class         Waits      Time (us)      Avg (us)
 -------------------------------------- ------------- ------------- -------------- -------------
 CPU                                                                    1995948632
 WALInsert                                     LWLock             1           6656          6656

 Vacuum Information
 ~~~~~~~~~~~~~~~~~~~
             Num Analyze operations:             1976
              Num Vacuum operations:             3435

 Per Database Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 Name                      Commits       Rollbacks     BlkRds        Blkhits       TempFiles     TempBytes
 ------------------------- ------------- ------------- ------------- ------------- ------------- -------------
 bench                             27939             0             0       7823038             0       0 bytes
 postgres                          39792             0             7      11089243             0       0 bytes

 Per Database DML & DQL Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Name                      Tuples returned  Tuples fetched   Tuples inserted  Tuples updated   Tuples deleted   Index splits     Index Only heap fetches   HOT updates
 ------------------------- ---------------- ---------------- ---------------- ---------------- ---------------- ---------------- ------------------------- ----------------
 bench                             16119481          4843262                0                0                0                0                        16                0
 postgres                          25415473          6327188                0               10                0                0                         0                8

 Per Database Conflict Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Name                      Lock Timeout  Old Snapshot  Buffer Pins   Deadlock
 ------------------------- ------------- ------------- ------------- -------------
 bench                                 0             0             0             0
 postgres                              0             0             0             0

 Per Database Vacuum Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Name                      Frozen XID    % Consumed    Aggregate Vacuum Gap
 ------------------------- ------------- ------------- --------------------
 bench                         179460916         9.00%         20539084
 postgres                      179339239         9.00%         20660761

 Per Database Sizing Information
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                    Conn.
 Name                 Collation     Limit   Tablespace           DB Size    Growth
 -------------------- ------------- ------- -------------------- ---------- ----------
 bench                C.UTF-8            -1 pg_default                80 GB    0 bytes
 postgres             C.UTF-8            -1 pg_default               135 MB    0 bytes

 Backend Wait Event Histogram
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Event                                          Class       Waits    <= 1us    <= 2us    <= 4us    <= 8us   <= 16us   <= 32us   <= 64us  <= 128us  <= 256us  <= 512us
 -------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
 WALInsert                                  LWLock             1         0         0         0         0         0         0         0         0         0         0

 Background Wait Event Histogram
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Event                                          Class       Waits    <= 1us    <= 2us    <= 4us    <= 8us   <= 16us   <= 32us   <= 64us  <= 128us  <= 256us  <= 512us
 -------------------------------------- ------------- ----------- --------- --------- --------- --------- --------- --------- --------- --------- --------- --------
 WALInsert                                  LWLock           542       107       174        39       113        93         8         1         1         0         1

 Write Ahead Log (WAL) Statistics
 --------------------------------
 Records       Full Page Images   Bytes        Buffers Full   Write         Sync          Write Time    Sync Time
 -----------   ----------------   -----------  ------------   -----------   -----------   -----------   -----------
     2936305                100     805989345             0             0             0             0             0

 Summary Stats (across all databases)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Name                             Value
 -------------------------------- ----------------------------------
 Buffers evicted                  0
 Commits                          1216693
 ...

 Parameter Settings
 ~~~~~~~~~~~~~~~~~~~
 Parameter                         Value
 --------------------------------- --------------------------------------------------------------
 DateStyle                            ISO, MDY
 TimeZone                             UTC
 autovacuum                           on
 work_mem                             4096

 Columnar Engine available size  Columnar Engine configured size
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                       14959MB                         19293MB

 Columnar Engine Statistics
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 name                                                       count
 ---------------------------------------------------------- ------------
 CU Populations/Refreshes                                          13197
 CU Auto Refreshes                                                 10975
 ...
 Columnar Engine Ultra-fast Cache Statistics
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Ultra-fast Cache Size (MB):                        19200
 Ultra-fast Cache Used Size (MB):                       0
 Ultra-fast Cache Block Size (MB):                     80

 SQL Report
 ~~~~~~~~~~
 NOTE: Query might be empty if query ID does not have a match in pg_stat_statements at report time. This is expected if the query is not run recently.
 Per Query Information (Top 50) By Total Elapsed Time
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Query Text                                                                                                 UserID         DBID          DBName          QueryID            Total Elapsed Time(ms)    Execution Count       Avg Elapsed Time(ms)
 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6)        36272        36274            tpcc      -5467151541922966497           276400877.8014            36928106                    7.4848
 prepare payment (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, INTEGER, NUMERIC, VARCHAR) AS select p        36272        36274            tpcc       3864683359055073968           127719636.4656            36928456                    3.4586
                                        prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2)        36272        36274            tpcc       2323704420019807054            48540963.0880             3694128                   13.1400
                                    prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3)        36272        36274            tpcc      -8637448842172635004            35361366.9271             3692785                    9.5758
 ...

 Per Query Information (Top 50) By Read IO
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Query Text                                                                                                 UserID         DBID          DBName          QueryID            Total ReadIO Time(ms)        Execution Count    Avg ReadIO Time(ms)    Total buffer hits         Avg buffer hits    Total blk reads         Avg blk reads
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 prepare ostat (INTEGER, INTEGER, INTEGER, INTEGER, VARCHAR) AS select * from ostat($1,$2,$3,$4,$5) a        36272        36274            tpcc      -1640504351418263816              498072.4004             3693895                    0.1348            80360201         21.75486877672484              105858 0.028657555236410347
                                        prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2)        36272        36274            tpcc       2323704420019807054                  12.5438             3694128                    0.0000          4477308168        1212.0067761593534             1219908 0.33022894712906536
     prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6)        36272        36274            tpcc      -5467151541922966497                   0.8039            36928106                    0.0000         10337394097         279.9329620912592             6245570 0.16912781825312134
              SELECT name, default_version, installed_version FROM pg_catalog.pg_available_extensions           10            5        postgres       6619165036968781114                   0.0000                 361                    0.0000                 361                         1                   0                   0
 ...

 Per Query Information (Top 50) By Standard Deviation of Elapsed Time
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Query Text                                                                                                 UserID         DBID          DBName          QueryID            Begin STDDEV Elapsed Time(ms)  End STDDEV Elapsed Time(ms)
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                                                           SELECT COUNT($1) FROM perfsnap.g$snapshots           10            5        postgres      -8741741796612173369                      17.8084                      18.1239
                                        prepare delivery (INTEGER, INTEGER) AS select delivery($1,$2)        36272        36274            tpcc       2323704420019807054                      15.0626                      19.8495
     prepare neword (INTEGER, INTEGER, INTEGER, INTEGER, INTEGER) as select neword($1,$2,$3,$4,$5,$6)        36272        36274            tpcc      -5467151541922966497                      13.9820                      17.0074
                                    prepare slev (INTEGER, INTEGER, INTEGER) AS select slev($1,$2,$3)        36272        36274            tpcc      -8637448842172635004                       8.4333                       9.6205

 ----------------------------------------------------
 Created by G_STATS v1.0.100
 ----------------------------------------------------
(xxx rows)

Untuk mengetahui informasi tentang kolom laporan dan rekomendasi pengoptimalan performa, lihat Rekomendasi pengoptimalan performa database. Untuk mengetahui informasi selengkapnya tentang peristiwa tunggu dalam laporan snapshot performa, lihat Referensi laporan snapshot performa database.

Menghapus snapshot

Sebelum dapat menghapus snapshot yang merupakan bagian dari dasar pengukuran yang ada, Anda harus menghapus dasar pengukuran.

Untuk menghapus snapshot, jalankan perintah berikut:

SELECT perfsnap.delete(SNAP_ID);

Ganti SNAP_ID dengan ID snapshot yang ingin Anda hapus.

Setelah menghapus snapshot, Anda tidak dapat memulihkannya.

Menandai snapshot sebagai dasar pengukuran performa

Untuk menandai semua snapshot dengan ID antara 1 dan 3, misalnya, sebagai dasar pengukuran performa sistem, jalankan
SELECT perfsnap.make_baseline(1, 3).

Menghapus dasar pengukuran performa

Untuk menghapus semua dasar pengukuran dengan ID antara 1 dan 3, misalnya, jalankan SELECT perfsnap.clear_baseline(1, 3).

Mengubah frekuensi snapshot otomatis

Snapshot otomatis diambil untuk instance utama dan node baca sekali sehari secara default.

Untuk menyesuaikan frekuensi snapshot otomatis, tetapkan flag perfsnap.interval, yang menetapkan interval snapshot otomatis dalam detik. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

Sebaiknya tetapkan nilai flag ke setidaknya beberapa menit untuk mengambil informasi yang bermakna.

Untuk mengoptimalkan penggunaan resource, jika Anda tidak lagi memerlukan frekuensi yang disesuaikan, reset flag ke nilai default, yaitu 86400 detik per hari.

Mengubah retensi snapshot otomatis

Untuk menyesuaikan periode retensi snapshot otomatis, tetapkan flag perfsnap.retention, yang menetapkan durasi penyimpanan snapshot otomatis. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi flag database.

Periode retensi default adalah 7 days.

Mengoptimalkan performa database menggunakan hasil laporan snapshot

Ikuti langkah-langkah berikut untuk mengoptimalkan performa database AlloyDB:

  1. Buat snapshot dasar pengukuran saat database Anda tidak ada aktivitas atau saat database mengalami beban rata-rata.
  2. Mulai workload atau kueri yang performanya ingin Anda tingkatkan.
  3. Saat workload atau kueri mencapai penggunaan resource puncak, buat kumpulan snapshot lain. Sebaiknya gunakan interval yang sama untuk kedua laporan.
  4. Bandingkan laporan yang Anda buat dengan kedua kumpulan snapshot dan identifikasi perubahan yang mungkin meningkatkan performa. Untuk mengetahui informasi selengkapnya tentang rekomendasi performa, lihat Rekomendasi pengoptimalan performa database.

Rekomendasi pengoptimalan performa database

Tabel berikut mencantumkan bagian laporan snapshot performa dan peningkatan yang direkomendasikan untuk setiap bagian laporan. Untuk mengetahui informasi selengkapnya tentang bagian laporan snapshot performa dan peristiwa tunggu, lihat Referensi laporan snapshot performa database.

Bagian Kolom laporan Deskripsi kolom laporan Rekomendasi pengoptimalan
Detail snapshot Detail Snapshot Menyediakan host, versi rilis yang kompatibel dengan PostgreSQL, dan waktu saat mesin aktif dan berjalan. T/A
ID Snapshot Mencantumkan ID dan titik waktu snapshot yang digunakan untuk membuat laporan ini. T/A
Insight Sistem CPU Host Detail penggunaan CPU host. Jika penggunaan CPU lebih besar dari 80%, sebaiknya lakukan penskalaan ke ukuran berikutnya yang tersedia. Untuk instance kumpulan baca, pastikan ukuran node sama dengan atau lebih besar dari instance utama. Node baca yang lebih kecil mungkin tidak dapat mengikuti kecepatan pembuatan WAL utama selama workload tulis yang berat.
Memori Host Detail penggunaan memori host. Jika memori kosong kurang dari 15%, sebaiknya lakukan penskalaan ke ukuran berikutnya yang tersedia. Untuk instance kumpulan baca, pastikan ukuran node sama dengan atau lebih besar dari instance utama. Node baca yang lebih kecil mungkin tidak dapat mengikuti kecepatan pembuatan WAL utama selama workload tulis yang berat.
Muat Profil Mencantumkan penghitung yang membantu memenuhi syarat workload Write-Ahead Logging (WAL) yang dibuat, persyaratan I/O, dan pengelolaan koneksi. Jika pembacaan fisik lebih tinggi daripada pembacaan logis, pertimbangkan untuk melakukan penskalaan ke ukuran berikutnya yang tersedia untuk mendukung penyimpanan data dalam cache yang lebih besar.
Waktu Respons dan Rincian Class Tunggu Rincian waktu yang dihabiskan proses Postgres selama menjalankan workload. Fokuskan penyesuaian Anda untuk mempersingkat waktu tunggu I/O jika proses sebagian besar dalam status tunggu, misalnya.
Informasi workload database Informasi Workload Per Database Metrik utama untuk setiap database, termasuk commit, rollback, rasio hit, dan informasi tentang tabel sementara dan operasi pengurutan. Jika rollback tinggi, pertimbangkan untuk mendiagnosis aplikasi Anda.
Informasi DML dan DQL Per Database Penghitung untuk operasi kueri. Memenuhi syarat workload Anda sebagai baca-berat atau tulis-berat.
Informasi Konflik Database Penghitung untuk masalah aplikasi dan database umum. Temukan masalah di aplikasi Anda jika terjadi deadlock. Jika konflik Pin Buffer tinggi pada instance kumpulan baca, pertimbangkan untuk mengurangi nilai max_standby_streaming_delay agar replay dapat dilanjutkan, atau pindahkan kueri yang berjalan lama ke kumpulan baca lain untuk menghindari penahanan pin dalam durasi yang diperpanjang.
Informasi Ukuran Database Menunjukkan seberapa besar database telah berkembang selama interval antara dua snapshot. Kolom ini juga menunjukkan apakah database memiliki batas koneksi yang ditetapkan. Temukan masalah di aplikasi Anda jika pertumbuhan database terlalu besar.
Informasi Vacuum Informasi Vacuum Detail I/O dan penghitung untuk operasi vacuum. Secara default, AlloyDB melakukan vacuuming adaptif. Anda dapat mengganti beberapa setelan vacuum agar sesuai dengan workload Anda. Misalnya, kurangi operasi vacuum jika terlalu banyak I/O yang dihabiskan untuk permintaan ini.
Informasi Vacuum Per Database Menampilkan informasi berikut:
  • Usia saat ini dari datfrozenxid (XID yang tidak dibekukan tertua) dari setiap database, atau jumlah transaksi dari datfrozenxid ke XID transaksi saat ini.
  • ID transaksi yang tidak dibekukan yang digunakan dari semua ID transaksi.
  • Hasil dari autovacuum_freeze_max_age - age(pg_database.datfrozenxid), yang menunjukkan perkiraan kesenjangan usia (dalam transaksi) pada waktu snapshot kedua, saat autovacuum dipicu untuk mencegah wraparound pada tingkat gabungan database.
 Jika usia kolom XID yang Dibekukan terlalu lama, atau jika persentase transaksi yang digunakan mendekati 90%, pertimbangkan untuk melakukan vacuuming. Jika kesenjangan vacuum gabungan menurun, hal ini menunjukkan bahwa vacuum akan diterapkan oleh Postgres untuk mencegah wraparound.
Detail Tunggu Proses Database Informasi Proses Backend &Latar Belakang Mendetail Detail semua waktu tunggu oleh proses backend &latar belakang dalam interval laporan. Informasi mencakup waktu tunggu kumulatif, waktu CPU, dan waktu rata-rata per jenis tunggu. Untuk mengurangi waktu tunggu di WALWrite, misalnya, tingkatkan jumlah wal_buffers yang tersedia untuk database.
Histogram Peristiwa Tunggu Backend &Latar Belakang Mendetail Histogram ini disertakan dalam laporan snapshot performa secara default. Daftar ini berisi histogram peristiwa tunggu untuk proses backend &latar belakang, yang dibagi menjadi 32 bucket, dari 1 us hingga lebih dari 16 detik. Temukan peristiwa tunggu dan tentukan apakah ada terlalu banyak peristiwa tunggu di bucket waktu tunggu yang lebih besar. Mungkin ada masalah dengan terlalu banyak peristiwa tunggu atau dengan setiap waktu tunggu yang digunakan.
Statistik serbaneka Statistik Write Ahead Log (WAL) Ringkasan statistik WAL. Jika Anda mengalami terlalu banyak waktu sinkronisasi, sesuaikan flag database (GUC) terkait untuk meningkatkan workload Anda. GUC adalah subsistem PostgreSQL yang menangani konfigurasi server.
Statistik Ringkasan (di semua database) Ringkasan semua operasi database yang terjadi selama interval snapshot. T/A
Setelan Parameter Setelan Parameter Parameter konfigurasi Postgres utama pada waktu snapshot akhir. Periksa setelan parameter GUC (flag database Postgres) untuk menentukan apakah nilainya tidak diharapkan atau tidak direkomendasikan. Untuk instance kumpulan baca mengalami latensi replikasi tinggi, pertimbangkan untuk menyesuaikan hal berikut:
  • max_standby_streaming_delay: sesuaikan parameter ini untuk menyeimbangkan frekuensi pembatalan kueri dengan latensi replikasi.
  • alloydb.promote_cancel_to_terminate: pastikan parameter ini on untuk menghentikan paksa backend yang tidak responsif terhadap pembatalan dan pemulihan pemblokiran.
  • google_storage.log_replay_throttle_read_transactions: gunakan parameter ini untuk memprioritaskan replikasi catch-up daripada latensi kueri baca saat latensi melebihi nilai minimum.
Statistik Eksekusi SQL Informasi Per Kueri (50 Teratas) Berdasarkan Total Waktu yang Berlalu Mencantumkan 50 kueri teratas yang menghabiskan waktu terbanyak selama dua snapshot, serta jumlah eksekusi totalnya, yang dipecah berdasarkan pengguna dan database tempat kueri dikeluarkan.
Elapsed time = Difference of total_exec_time in pg_stat_statements at the two snapshot time		 Gunakan bagian ini untuk mengidentifikasi kueri terberat yang menghabiskan sebagian besar waktu sistem.
Informasi Per Kueri (50 Teratas) Berdasarkan IO Baca Mencantumkan 50 kueri teratas yang menghabiskan waktu IO Baca terbanyak selama dua snapshot, serta jumlah eksekusi, hit buffer, pembacaan blk, baik secara total maupun rata-rata.
ReadIO = blk_read_time + temp_blk_read_time yang diakumulasikan selama dua snapshot
Buffer Hits = shared_blks_hit + local_blks_hit yang diakumulasikan selama dua snapshot
Buffer Reads = shared_blks_read + local_blks_read yang diakumulasikan selama dua snapshot
Kolom ini dilacak oleh AlloyDB secara default karena track_io_timing ditetapkan.		 Gunakan bagian ini untuk mengidentifikasi kueri yang intensif I/O, terutama jika kueri tersebut sering perlu membaca dari disk.
Informasi Per Kueri (50 Teratas) Berdasarkan Simpangan Baku Waktu yang Berlalu Mencantumkan 50 kueri teratas yang memiliki simpangan baku waktu yang berlalu tertinggi, yang mencantumkan simpangan baku yang dihitung pada waktu snapshot awal dan akhir.
Di sini, nilai tersebut merujuk stddev_exec_time dari pg_stat_statements		 Untuk kueri dengan simpangan baku yang tinggi, artinya waktu eksekusi kueri sangat bervariasi, dan mungkin sudah waktunya untuk melihat I/O.

Batasan

  • Untuk mencegah bloat ruang dari konsumsi penyimpanan yang berlebihan, Anda dapat membuat maksimum 2.500 snapshot secara manual pada satu instance.

  • Jika jumlah snapshot melebihi batas snapshot, AlloyDB akan menghapus semua snapshot manual yang lebih lama dari 90 hari. Agar tetap berada dalam batas snapshot, Anda harus membersihkan snapshot yang tidak diperlukan sebelum mengambil snapshot baru.

  • AlloyDB secara berkala membersihkan snapshot manual yang lebih lama dari 90 hari.

Langkah berikutnya