Cara kerja laporan ringkasan performa
Laporan ringkasan performa adalah alat bawaan AlloyDB Omni yang merekam dan menganalisis data performa untuk membantu Anda mengidentifikasi penyebab masalah performa.
Laporan ringkasan performa menampilkan metrik database antara dua stempel waktu dalam satu laporan. Anda dapat menggunakan informasi laporan ringkasan performa untuk mengidentifikasi masalah performa pada instance laporan ringkasan performa, seperti penurunan performa database pada waktu tertentu dalam sehari atau penurunan performa selama jangka waktu tertentu.
Dengan laporan ringkasan performa, Anda membandingkan metrik dengan dasar performa untuk mendapatkan insight tentang metrik performa beban kerja, yang dapat Anda gunakan untuk mengoptimalkan atau memecahkan masalah performa database. Dasar pengukuran adalah set snapshot database yang disesuaikan yang mengukur performa dan perilaku standar database untuk konfigurasi dan workload tertentu.
Secara default, snapshot performa di AlloyDB Omni disimpan dalam memori dan dihapus jika instance dimulai ulang.
Peran yang diperlukan
Pastikan Anda memiliki peran pg_monitor.
Peran ini diberikan kepada pengguna super, yang kemudian dapat memberikan pg_monitor kepada pengguna lain.
Misalnya, postgres adalah pengguna super 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.
Laporan ringkasan performa penginstalan
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 ringkasan performa.
Untuk menggunakan API perfsnap, hubungkan ke database 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 mengumpulkan 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 yang mendetail dalam laporan performa, Anda harus membuat ekstensi pg_stat_statements di database postgres terlebih dahulu. Perhatikan bahwa pengambilan statistik ini diaktifkan oleh tanda 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
- Menghubungkan klien
psqlke instance AlloyDB. Jalankan
SELECT * FROM perfsnap.g$snapshots. Outputnya akan terlihat mirip dengan berikut ini: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 mencatat perbedaan antara snapshot 1 dan 2, misalnya, jalankan SELECT perfsnap.report(1,2).
Snapshot kedua dalam operasi diferensial tidak harus langsung mengikuti snapshot pertama. Namun, pastikan Anda mengambil snapshot kedua dalam diferensial setelah snapshot pertama.
Laporan ringkasan performa yang dihasilkan terlihat mirip dengan contoh ringkas berikut:
Contoh laporan ringkasan 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 pengukuran yang ada, Anda harus menghapus dasar pengukuran tersebut .
Untuk menghapus snapshot, jalankan SELECT perfsnap.delete(n). Setelah menghapus snapshot, Anda tidak dapat memulihkannya.
Menandai snapshot sebagai dasar pengukuran performa
Misalnya, untuk menandai semua snapshot dengan ID antara 1 dan 3 sebagai dasar pengukuran performa sistem, jalankan SELECT perfsnap.make_baseline(1, 3).
Dasar pengukuran performa yang jelas
Untuk menghapus semua tolok ukur 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 set snapshot lain. Sebaiknya gunakan interval yang sama untuk kedua laporan.
- Bandingkan laporan yang Anda buat dengan kedua set 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 ringkasan 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 cuplikan | Detail Snapshot | Menyediakan host, versi rilis yang kompatibel dengan PostgreSQL, dan waktu saat mesin aktif dan berjalan. | T/A |
| ID Snapshot | Mencantumkan ID dan point-in-time snapshot yang digunakan untuk membuat laporan ini. | T/A | |
| Insight Sistem | CPU Host | Detail pemakaian CPU host. | Jika pemakaian CPU lebih besar dari 80%, sebaiknya pindah ke sistem dengan vCPU yang lebih banyak. |
| 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 meningkatkan skala ke ukuran berikutnya yang tersedia untuk mendukung penyimpanan data dalam cache yang lebih besar. | |
| Perincian Waktu Respons dan Kelas Tunggu | Perincian waktu yang dihabiskan proses Postgres selama eksekusi workload. | Misalnya, fokuskan penyesuaian Anda pada mempersingkat waktu tunggu I/O jika prosesnya sebagian besar dalam status tunggu. | |
| Informasi workload database | Informasi Workload per Database | Metrik utama untuk setiap database, termasuk commit, rollback, rasio hit, serta informasi tentang tabel sementara dan operasi pengurutan. | Jika rollback tinggi, sebaiknya diagnosis aplikasi Anda. |
| Informasi DML dan DQL per Database | Penghitung untuk operasi kueri. | Menentukan apakah workload Anda bersifat read-heavy atau write-heavy. | |
| Informasi Konflik Database | Penghitung untuk masalah umum aplikasi dan database. | Temukan masalah dalam aplikasi Anda jika terjadi kebuntuan. | |
| Informasi Penentuan Ukuran Database |
Menunjukkan seberapa besar pertumbuhan database selama interval antara dua snapshot. Kolom ini juga menunjukkan apakah database memiliki batas koneksi yang ditetapkan. | Temukan masalah dalam aplikasi Anda jika pertumbuhan database terlalu besar. | |
| Informasi Vakum | Informasi Penyedot Debu | Detail I/O dan penghitung untuk operasi vacuum. | Secara default, AlloyDB melakukan pembersihan adaptif. Anda dapat mengganti beberapa setelan vakum agar sesuai dengan beban kerja Anda. Misalnya, kurangi operasi vakum jika terlalu banyak I/O yang digunakan untuk permintaan ini. |
| Informasi Vacuum per Database | Menampilkan informasi berikut:
|
Jika usia kolom XID yang dibekukan terlalu lama, atau jika persentase transaksi yang digunakan mendekati 90%, pertimbangkan untuk melakukan vacuum. Jika selisih vacuum agregat menurun, ini menunjukkan bahwa vacuum akan diterapkan oleh Postgres untuk mencegah wraparound. | |
| Detail Tunggu Proses Database | Informasi Mendetail tentang Backend & Proses Latar Belakang |
Detail semua tunggu menurut 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 yang Mendetail | Metrik ini disertakan dalam laporan ringkasan performa secara default. Daftar berisi histogram peristiwa tunggu untuk proses backend & latar belakang, yang dibagi menjadi 32 bucket, dari 1 μs hingga lebih dari 16 detik. | Temukan peristiwa tunggu dan tentukan apakah ada terlalu banyak peristiwa tunggu pada bucket waktu tunggu yang lebih besar. Mungkin ada masalah dengan terlalu banyak peristiwa tunggu atau dengan setiap waktu tunggu yang digunakan. | |
| Statistik lain-lain | Statistik Write Ahead Log (WAL) | Ringkasan statistik WAL. | Jika Anda mengalami waktu sinkronisasi yang terlalu lama, 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. |
| Statistik Eksekusi SQL | Informasi Per Kueri (50 Teratas) Berdasarkan Total Waktu Berlalu | Mencantumkan 50 kueri teratas yang menghabiskan waktu paling lama selama dua snapshot, serta total jumlah eksekusinya, yang dikelompokkan 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) Menurut IO Baca | Mencantumkan 50 kueri teratas yang telah menghabiskan sebagian besar waktu IO Baca selama dua snapshot, serta jumlah eksekusi, hit buffer, pembacaan blk, baik secara total maupun rata-rata.ReadIO = blk_read_time + temp_blk_read_time diakumulasikan selama dua snapshotBuffer Hits = shared_blks_hit + local_blks_hit diakumulasikan selama dua snapshotBuffer Reads = shared_blks_read + local_blks_read diakumulasikan selama dua snapshotKolom ini dilacak oleh AlloyDB Cloud secara default karena track_io_timing ditetapkan. |
Gunakan bagian ini untuk mengidentifikasi kueri yang intensif I/O, terutama jika kueri tersebut perlu sering membaca dari disk. | |
| Informasi Per Kueri (50 Teratas) Menurut Standar Deviasi Waktu yang Berlalu | Mencantumkan 50 kueri teratas yang memiliki simpangan baku waktu berlalu tertinggi, 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 standar deviasi tinggi, berarti 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 di satu instance. Space bloat memastikan snapshot tidak menggunakan terlalu banyak ruang penyimpanan di database Anda.
Jika jumlah snapshot melebihi batas snapshot, AlloyDB Omni akan menghapus semua snapshot manual yang lebih lama dari 90 hari. Agar tetap berada dalam batas snapshot, Anda harus menghapus snapshot yang tidak diperlukan sebelum mengambil snapshot baru.
AlloyDB Omni secara berkala membersihkan snapshot manual yang sudah lebih dari 90 hari.