Cara kerja laporan ringkasan performa
Laporan ringkasan performa adalah alat AlloyDB Omni bawaan 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 snapshot performa untuk mengidentifikasi masalah performa pada instance laporan snapshot performa, seperti penurunan performa database pada waktu tertentu dalam sehari atau penurunan performa selama jangka waktu tertentu.
Dengan menggunakan laporan snapshot performa, Anda dapat 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 set 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 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 perfsnap API, 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.
- Menghubungkan klien
psqlke instance AlloyDB. Jalankan
SELECT perfsnap.snap(). Outputnya akan terlihat mirip seperti berikut:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Melihat daftar snapshot
- Hubungkan 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 perlu langsung mengikuti snapshot pertama. Namun, pastikan Anda mengambil snapshot kedua dalam diferensial setelah snapshot pertama.
Laporan ringkasan performa yang dihasilkan akan terlihat mirip dengan contoh singkat berikut:
Contoh laporan ringkasan 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
----------------------------------------------------
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 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
Misalnya, untuk menghapus semua dasar pengukuran dengan ID antara 1 dan 3, 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 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 mungkin 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 tingkatkan skala 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 untuk mempersingkat waktu tunggu I/O jika proses sebagian besar berada 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, pertimbangkan untuk mendiagnosis 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 database telah berkembang 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 Vakum | Detail I/O dan penghitung untuk operasi vakum. | Secara default, AlloyDB melakukan pembersihan adaptif. Anda dapat mengganti beberapa setelan vacuum agar sesuai dengan workload Anda. Misalnya, kurangi operasi vacuum jika terlalu banyak I/O yang digunakan 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 selisih vacuum agregat menurun, ini menunjukkan bahwa vacuum akan diterapkan oleh Postgres untuk mencegah wraparound. | |
| Detail Penantian 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. | Misalnya, untuk mengurangi waktu tunggu di WALWrite, 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 ini berisi histogram peristiwa tunggu untuk proses backend & latar belakang, yang dibagi menjadi 32 bucket, dari 1 mikrodetik 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 lain-lain | Statistik Write Ahead Log (WAL) | Ringkasan statistik WAL. | Jika Anda mengalami waktu sinkronisasi yang terlalu lama, sesuaikan tanda (GUC) database terkait untuk meningkatkan kualitas beban kerja 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 sesuai atau tidak direkomendasikan. |
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 berusia lebih dari 90 hari.