Dokumen ini menjelaskan cara membuat laporan snapshot performa secara manual, yang memungkinkan Anda membandingkan snapshot metrik sistem antara dua titik waktu. Anda dapat menggunakan laporan snapshot performa untuk mengidentifikasi dan mengurangi masalah performa database AlloyDB untuk PostgreSQL. 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 perincian workload harian. Anda tidak dapat mengubah retensi snapshot otomatis, tetapi Anda dapat mengonfigurasi frekuensi.
Snapshot manual: Anda dapat mengambil snapshot secara manual dan membuat laporan.
Anda dapat mencampur dan mencocokkan snapshot otomatis dan manual untuk membuat laporan performa. Misalnya, Anda dapat membuat laporan ringkasan performa yang membandingkan snapshot yang dibuat secara manual dengan snapshot otomatis.
Dokumen ini menjelaskan cara membuat laporan snapshot performa secara manual.
Cara kerja laporan ringkasan performa
Laporan ringkasan performa adalah alat bawaan AlloyDB yang merekam dan menganalisis data performa untuk membantu Anda mengidentifikasi penyebab masalah performa. Alat ini melengkapi fitur pengamatan AlloyDB lainnya seperti insight sistem, insight kueri, dan Penjelajah Metrik, yang memberikan metrik real-time tentang instance Anda.
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 selama waktu tertentu dalam sehari atau penurunan performa selama jangka waktu tertentu.
Dengan menggunakan laporan ringkasan performa, Anda membandingkan metrik dengan tolok ukur performa untuk mendapatkan insight tentang metrik performa beban kerja, 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 beban kerja 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 standar PostgreSQL.
Jika Anda lebih suka menggunakan peran lain yang ditentukan sendiri, jalankan
GRANT pg_monitor TO my_user sebagai alloydbsuperuser terlebih dahulu. Untuk informasi selengkapnya, lihat Memperbarui akun Identity and Access Management (IAM) dengan peran yang sesuai.
Membuat snapshot
Ringkasan performa adalah alat canggih untuk memahami dan mengoptimalkan performa database Anda. Laporan ini mencatat metrik sistem utama pada titik waktu tertentu, sehingga Anda dapat membandingkan performa database Anda antara dua titik waktu. AlloyDB mendukung dua jenis snapshot:
- Snapshot metrik sistem: snapshot ini merekam 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.
Dengan demikian, Anda memiliki fleksibilitas untuk memilih tingkat detail yang diperlukan untuk analisis.
Membuat snapshot metrik sistem
Buat snapshot di awal dan akhir beban kerja yang Anda minati. Interval waktu antara dua snapshot harus cukup lama untuk merekam sampel beban kerja yang representatif.
Ikuti langkah-langkah berikut untuk mengoptimalkan performa database AlloyDB:
- Buat snapshot dasar pengukuran saat database Anda tidak ada aktivitas atau saat mengalami beban rata-rata.
- Hubungkan klien
psqlke instance AlloyDB. 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), yaitu1dalam contoh ini. Anda memerlukan ID ini untuk membuat laporan snapshot performa nanti.snap_iddi lingkungan Anda sendiri kemungkinan berbeda.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.
Setelah mendapatkan metrik dari laporan snapshot performa yang dihasilkan, Anda dapat mengambil serangkaian 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 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
- 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 ringkasan performa
Untuk membuat laporan yang mencatat perbedaan antara dua snapshot, misalnya, snapshot 1 dan 2, 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.
Contoh laporan
Berikut adalah contoh singkat laporan ringkasan performa yang dibuat:
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
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 tersebut.
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 baseline performa
Untuk menandai semua snapshot dengan ID antara 1 dan 3, misalnya, sebagai tolok ukur performa sistem, jalankan SELECT perfsnap.make_baseline(1, 3).
Menghapus dasar performa
Untuk menghapus semua tolok ukur dengan ID antara 1 dan 3, misalnya, jalankan
SELECT perfsnap.clear_baseline(1, 3).
Mengubah frekuensi snapshot otomatis
Untuk menyesuaikan frekuensi snapshot otomatis, tetapkan tanda perfsnap.interval,
yang menetapkan interval snapshot otomatis dalam detik. Untuk mengetahui informasi selengkapnya, lihat
Mengonfigurasi flag database.
Sebaiknya tetapkan nilai tanda minimal lebih besar dari beberapa menit untuk mendapatkan informasi yang bermakna.
Untuk menghindari pemborosan resource, jika Anda tidak lagi memerlukan frekuensi yang disesuaikan, reset flag ke nilai default (yaitu detik per hari).
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 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 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 penantian, 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 penggunaan CPU lebih dari 80%, sebaiknya Anda melakukan penskalaan ke ukuran berikutnya yang tersedia. |
| Memori Host | Detail penggunaan memori host. | Jika memori kosong kurang dari 15%, sebaiknya tingkatkan skala ke ukuran berikutnya yang tersedia. | |
| Profil Pemuatan | Mencantumkan penghitung yang membantu mengukur workload Anda yang dihasilkan oleh Write-Ahead Logging (WAL), 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 penyiapan cache data yang lebih besar. | |
| Perincian Waktu Respons dan Kelas Tunggu | Perincian waktu yang dihabiskan oleh proses Postgres selama menjalankan workload. | Fokuskan penyesuaian Anda untuk mempersingkat waktu tunggu I/O jika proses 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, pertimbangkan untuk mendiagnosis aplikasi Anda. |
| Informasi DML dan DQL Per Database | Penghitung untuk operasi kueri. | Kategorikan beban kerja Anda sebagai beban baca berat atau beban tulis berat. | |
| Informasi Konflik Database | Penghitung untuk masalah umum aplikasi dan database. | Temukan masalah di 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 pembersihan. | Secara default, AlloyDB melakukan pembersihan adaptif. Anda dapat mengganti beberapa setelan robot penyedot debu agar sesuai dengan beban kerja 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 XID yang dibekukan terlalu lama, atau jika persentase transaksi yang digunakan mendekati 90%, pertimbangkan untuk melakukan vacuum. Jika celah vakum gabungan berkurang, ini menunjukkan bahwa vakum akan diterapkan oleh Postgres untuk mencegah wraparound. | |
| Detail Penantian Proses Database | Informasi Proses Latar Belakang & Backend yang Mendetail | Detail semua penantian oleh backend & proses 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 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 μ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 tanda database terkait (GUC) 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. |
| Statistik Eksekusi SQL | Informasi Per Kueri (50 Teratas) Menurut Total Waktu Berlalu | Mencantumkan 50 kueri teratas yang telah menghabiskan waktu paling lama selama dua snapshot, serta jumlah total eksekusinya, yang dikelompokkan menurut 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 menggunakan sebagian besar waktu sistem. |
| Informasi Per Kueri (50 Teratas) Menurut IO Baca | Mencantumkan 50 kueri teratas yang menghabiskan waktu IO Baca paling banyak selama dua snapshot, serta jumlah eksekusi, hit buffer, baca blk, baik secara total maupun rata-rata.ReadIO = blk_read_time + temp_blk_read_time yang terakumulasi selama dua snapshotBuffer Hits = shared_blks_hit + local_blks_hit yang terakumulasi selama dua snapshotBuffer Reads = shared_blks_read + local_blks_read yang terakumulasi selama dua snapshotKolom ini dilacak oleh AlloyDB Cloud secara default sejak 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 mencegah pembengkakan ruang penyimpanan akibat 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 menghapus snapshot yang tidak diperlukan sebelum mengambil snapshot baru.
AlloyDB secara berkala membersihkan snapshot manual yang sudah lebih dari 90 hari.