Dokumen ini menjelaskan cara mengidentifikasi dan mengurangi masalah performa database AlloyDB Omni menggunakan laporan yang membandingkan snapshot metrik sistem antara dua titik waktu yang berbeda. Metrik sistem yang diambil dalam setiap snapshot mencakup penggunaan CPU virtual (vCPU), penggunaan memori, I/O disk, jumlah transaksi, dan peristiwa tunggu.
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 ringkasan performa untuk mengidentifikasi masalah performa pada instance laporan ringkasan performa, seperti menurunnya performa database selama waktu tertentu dalam sehari atau menurunnya performa selama jangka waktu tertentu.
Dengan menggunakan laporan ringkasan performa, Anda membandingkan metrik dengan dasar pengukuran performa untuk mendapatkan insight tentang metrik performa beban kerja, yang dapat Anda gunakan untuk mengoptimalkan atau memecahkan masalah performa database. Baseline adalah kumpulan ringkasan database yang disesuaikan dan mengukur performa dan perilaku standar database untuk konfigurasi dan beban kerja tertentu.
Untuk 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 ke
alloydbsuperuser. Untuk informasi selengkapnya, lihat
Peran standar PostgreSQL.
Jika Anda lebih suka menggunakan peran lain yang Anda tentukan sendiri, jalankan
GRANT pg_monitor TO my_user sebagai alloydbsuperuser terlebih dahulu.
Menginstal laporan ringkasan 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 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 beban kerja yang Anda minati. Interval waktu antara dua snapshot memungkinkan waktu yang cukup bagi beban kerja untuk berkembang sehingga sistem dapat mengumpulkan metrik yang mencerminkan beban kerja. Setelah mendapatkan metrik dari laporan ringkasan performa yang dihasilkan, Anda dapat mengambil kumpulan snapshot lain dan mengulangi prosesnya.
- Hubungkan klien
psqlke instance AlloyDB. Jalankan
SELECT perfsnap.snap(). Outputnya terlihat mirip dengan yang berikut ini:postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
Melihat daftar snapshot
- [Menghubungkan klien
psqlke instance AlloyDB Omni. Jalankan
SELECT * FROM perfsnap.g$snapshots. Output-nya terlihat mirip dengan hal 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 ringkasan
Untuk membuat laporan yang menangkap perbedaan antara snapshot 1 dan 2, misalnya, jalankan SELECT perfsnap.report(1,2).
Snapshot kedua dalam operasi diferensial tidak perlu segera 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
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 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 SELECT perfsnap.delete(n). 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).
Dasar pengukuran performa yang jelas
Untuk menghapus semua dasar pengukuran dengan ID antara 1 dan 3, misalnya, jalankan
SELECT perfsnap.clear_baseline(1, 3).
Mengoptimalkan performa database menggunakan hasil laporan ringkasan
Ikuti langkah-langkah berikut untuk mengoptimalkan performa database AlloyDB:
- Buat snapshot dasar pengukuran saat database tidak ada aktivitas atau saat database mengalami beban rata-rata.
- Mulai workload atau kueri yang performanya ingin Anda tingkatkan.
- Saat beban kerja atau kueri mencapai penggunaan resource puncak, buat kumpulan snapshot lainnya. 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 ringkasan performa dan peningkatan yang direkomendasikan untuk setiap bagian laporan. Untuk 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 | Memberikan 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 | Host CPU | Detail pemakaian CPU host. | Jika penggunaan CPU lebih dari 80%, sebaiknya Anda beralih ke sistem dengan lebih banyak vCPU. |
| Memori Host | Detail penggunaan memori host. | Jika memori kosong kurang dari 15%, sebaiknya Anda menskalakan ke ukuran berikutnya yang tersedia. | |
| Profil Muat | Mencantumkan penghitung yang membantu mencirikan beban kerja Anda dalam hal Log Write-Ahead (WAL) yang dihasilkan, persyaratan I/O, dan pengelolaan koneksi. | Jika pembacaan fisik lebih tinggi daripada pembacaan logis, pertimbangkan untuk menskalakan ke ukuran berikutnya yang tersedia untuk mendukung penyimpanan dalam cache data yang lebih besar. | |
| Perincian Waktu Respons dan Kelas Tunggu | Perincian waktu yang dihabiskan proses Postgres selama workload berjalan. | Fokuskan penyesuaian Anda untuk mempersingkat waktu tunggu I/O jika prosesnya sebagian besar dalam status tunggu, misalnya. | |
| Informasi beban kerja database | Informasi Beban Kerja Per Database | Metrik utama untuk setiap database, termasuk commit, rollback, rasio hit, dan informasi tentang tabel sementara dan operasi pengurutan. | Jika rollback tinggi, sebaiknya diagnostik aplikasi Anda. |
| Informasi DML dan DQL per Database | Penghitung untuk operasi kueri. | Tentukan apakah workload Anda bersifat read-heavy atau write-heavy. | |
| Informasi Konflik Database | Penghitung untuk masalah aplikasi dan database umum. | Temukan masalah di aplikasi Anda jika ada deadlock. | |
| 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 dalam aplikasi Anda jika pertumbuhan database terlalu besar. | |
| Informasi Penyedot Debu | Informasi Penyedot Debu | Detail I/O dan penghitung untuk operasi penyedot debu. | Secara default, AlloyDB melakukan pembersihan adaptif. Anda dapat mengganti beberapa setelan penyedot debu agar sesuai dengan beban kerja Anda. Misalnya, kurangi operasi pembersihan jika terlalu banyak I/O yang dihabiskan untuk permintaan ini. |
| Informasi Pembersihan Per Database | Menampilkan informasi berikut:
|
Jika usia kolom XID Beku terlalu lama, atau jika persentase transaksi yang digunakan mendekati 90%, pertimbangkan untuk melakukan pembersihan. Jika gap vacuum gabungan menurun, ini menunjukkan bahwa vacuum akan diterapkan oleh Postgres untuk mencegah wraparound. | |
| Detail Tunggu Proses Database | Informasi Proses Latar Belakang & Backend yang Mendetail |
Detail semua penantian berdasarkan 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 Latar Belakang & Backend yang Mendetail | Hal 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 md 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 lainnya | Statistik Write Ahead Log (WAL) | Ringkasan statistik WAL. | Jika Anda mengalami terlalu banyak waktu sinkronisasi, sesuaikan flag database (GUC) terkait untuk meningkatkan 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 diharapkan atau tidak direkomendasikan. |
Batasan
Untuk menghindari pemborosan ruang, Anda dapat membuat maksimum 2.500 snapshot secara manual di satu instance. Space bloat memastikan bahwa snapshot tidak menempati terlalu banyak ruang penyimpanan di database Anda.
Jika jumlah snapshot melebihi batas snapshot, AlloyDB Omni akan menghapus semua snapshot manual yang sudah lebih dari 90 hari. Agar tetap dalam batas snapshot, Anda harus membersihkan snapshot yang tidak diperlukan sebelum mengambil snapshot baru.
AlloyDB Omni secara berkala membersihkan snapshot manual yang sudah lebih dari 90 hari.