Cara kerja laporan snapshot performa
Laporan snapshot performa adalah alat bawaan AlloyDB Omni yang mengambil dan menganalisis data performa untuk membantu Anda mengidentifikasi penyebab masalah performa.
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, seperti penurunan performa database selama waktu tertentu dalam sehari atau penurunan performa selama jangka waktu tertentu.
Dengan laporan snapshot performa, Anda membandingkan metrik dengan dasar performa untuk mendapatkan insight tentang metrik performa workload, yang dapat Anda gunakan untuk mengoptimalkan atau memecahkan masalah performa database. Dasar 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 pg_monitor.
Peran ini diberikan kepada superuser, yang kemudian dapat memberikan pg_monitor kepada pengguna lain.
Misalnya, postgres adalah superuser secara default. Anda dapat menjalankan
GRANT pg_monitor TO my_user sebagai postgres untuk mengizinkan my_user menggunakan alat snapshot performa seperti yang dijelaskan dalam dokumen ini.
Menginstal laporan snapshot performa
perfsnap adalah nama skema yang berisi fungsi SQL yang memungkinkan pengguna mengambil snapshot atau membuat laporan. Skema ini adalah bagian dari ekstensi g_stats AlloyDB Omni. Gunakan peran superuser untuk menginstal laporan snapshot performa.
Untuk menggunakan perfsnap API, hubungkan ke database mana pun tempat pengguna ingin menginstal ekstensi, dan buat ekstensi g_stats dengan perintah berikut:
CREATE EXTENSION IF NOT EXISTS g_stats;
Membuat snapshot metrik sistem
Buat snapshot di awal dan akhir workload yang Anda minati. Interval waktu antara dua snapshot memberikan waktu yang cukup bagi workload untuk berkembang sehingga sistem dapat mengakumulasi metrik yang mencerminkan workload. Setelah mendapatkan metrik dari laporan snapshot performa yang dihasilkan, Anda dapat mengambil kumpulan snapshot lain dan mengulangi prosesnya.
- Hubungkan klien
psqlke instance AlloyDB. Jalankan
SELECT perfsnap.snap(). Outputnya akan terlihat mirip seperti berikut:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Membuat snapshot yang berisi statistik eksekusi SQL
Secara default, AlloyDB Omni 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:
Buat ekstensi
pg_stat_statementsdi databasepostgres.postgres=# CREATE EXTENSION pg_stat_statements;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
- Hubungkan klien
psqlke instance AlloyDB. 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 | sr-primary | | Manual snapshot | Manual | f 2 | 2023-11-13 22:53:40.49565+00 | sr-primary | | Automatic snapshot | Automatic | f (2 rows)
Membuat laporan snapshot
Untuk membuat laporan yang menangkap perbedaan antara snapshot 1
dan 2, misalnya, 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 snapshot performa
psql -d postgres -U alloydbsuperuser
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
----------------------------------------------------
Created by G_STATS v1.0.100
----------------------------------------------------
(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 yang ada, Anda harus menghapus dasar .
Untuk menghapus snapshot, jalankan SELECT perfsnap.delete(n). Setelah menghapus snapshot, Anda tidak dapat memulihkannya.
Menandai snapshot sebagai dasar performa
Untuk menandai semua snapshot dengan ID antara 1 dan 3, misalnya, sebagai dasar performa sistem, jalankan SELECT perfsnap.make_baseline(1, 3).
Menghapus dasar performa
Untuk menghapus semua dasar dengan ID antara 1 dan 3, misalnya, jalankan SELECT perfsnap.clear_baseline(1, 3).
Mengoptimalkan performa database menggunakan hasil laporan snapshot
Ikuti langkah-langkah berikut untuk mengoptimalkan performa database AlloyDB:
- Buat snapshot dasar saat database Anda tidak ada aktivitas atau saat database mengalami beban rata-rata.
- Mulai workload atau kueri yang performanya ingin Anda tingkatkan.
- Saat workload atau kueri mencapai penggunaan resource puncak, buat kumpulan snapshot lain. Sebaiknya gunakan interval yang sama untuk kedua laporan.
- Bandingkan laporan yang Anda buat dengan kedua kumpulan snapshot dan identifikasi perubahan yang dapat 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 pindah ke sistem dengan lebih banyak vCPU. |
| Memori Host | Detail penggunaan memori host. | Jika memori kosong kurang dari 15%, sebaiknya lakukan penskalaan ke ukuran berikutnya yang tersedia. | |
| Muat Profil | Mencantumkan penghitung yang membantu mengkarakterisasi workload Anda dalam hal Write-Ahead Logging (WAL) yang dihasilkan, 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 caching data yang lebih besar. | |
| Waktu Respons dan Perincian Kelas Tunggu | Perincian 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. | Kualifikasikan workload Anda sebagai read-heavy atau write-heavy. | |
| Informasi Konflik Database | Penghitung untuk masalah aplikasi dan database umum. | Temukan masalah di aplikasi Anda jika terjadi kebuntuan. | |
| 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:
|
Jika usia kolom Frozen XID 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 Latar Belakang & Backend Mendetail |
Detail semua waktu tunggu oleh proses latar belakang &backend dalam interval laporan. Informasi mencakup waktu tunggu kumulatif, waktu CPU, dan waktu rata-rata per jenis tunggu. | Untuk mengurangi waktu tunggu WALWrite, misalnya, tingkatkan jumlah wal_buffers yang tersedia untuk database. |
| Histogram Peristiwa Tunggu Latar Belakang &Backend Mendetail | Histogram ini disertakan dalam laporan snapshot performa secara default. Daftar ini berisi histogram peristiwa tunggu untuk proses latar belakang &backend, 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 nilai tidak diharapkan atau tidak direkomendasikan. |
| Statistik eksekusi SQL | Informasi Per Kueri (50 Teratas) Berdasarkan Total Waktu Berlalu | Mencantumkan 50 kueri teratas yang menghabiskan waktu berlalu paling banyak 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 paling banyak selama dua snapshot, serta jumlah eksekusi, hit buffer, pembacaan blk, baik total maupun rata-rata.ReadIO = blk_read_time + temp_blk_read_time terakumulasi selama dua snapshotBuffer Hits = shared_blks_hit + local_blks_hit terakumulasi selama dua snapshotBuffer Reads = shared_blks_read + local_blks_read terakumulasi selama dua snapshotKolom ini dilacak oleh AlloyDB Cloud secara default karena track_io_timing ditetapkan. |
Gunakan bagian ini untuk mengidentifikasi kueri intensif I/O, terutama jika kueri tersebut sering perlu membaca dari disk. | |
| Informasi Per Kueri (50 Teratas) Berdasarkan Simpangan Baku Waktu Berlalu | Mencantumkan 50 kueri teratas yang memiliki simpangan baku waktu berlalu tertinggi, yang mencantumkan simpangan baku yang dihitung pada waktu snapshot awal dan akhir. Di sini, nilai mereferensikan 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 menghindari pembengkakan ruang, Anda dapat membuat maksimum 2.500 snapshot secara manual pada satu instance. Pembengkakan ruang memastikan bahwa snapshot tidak menggunakan terlalu banyak ruang penyimpanan di database Anda.
Jika jumlah snapshot melebihi batas snapshot, AlloyDB Omni akan menghapus semua snapshot manual yang berusia lebih dari 90 hari. Agar tetap berada dalam batas snapshot, Anda harus membersihkan snapshot yang tidak diperlukan sebelum mengambil snapshot baru.
AlloyDB Omni secara berkala membersihkan snapshot manual yang berusia lebih dari 90 hari.
Langkah berikutnya
- Pelajari tentang peristiwa tunggu dalam laporan snapshot performa.