Performance Snapshot Report 작동 방식
Performance Snapshot Report는 성능 문제 원인을 식별하는 데 도움이 되도록 성능 데이터를 캡처하고 분석하는 기본 제공 AlloyDB Omni 도구입니다.
Performance Snapshot Report는 보고서 하나에 두 타임스탬프 간의 데이터베이스 측정항목을 표시합니다. Performance Snapshot Report 정보를 사용하여 하루 중 특정 시간에 데이터베이스 성능 저하 또는 특정 기간 동안 성능 저하와 같은 Performance Snapshot Report 인스턴스의 성능 문제를 파악할 수 있습니다.
Performance Snapshot Report를 사용하여 측정항목을 성능 기준과 비교하여 워크로드 성능 측정항목에 대한 유용한 정보를 얻을 수 있으며 이 정보를 사용하여 데이터베이스 성능을 최적화하거나 문제를 해결할 수 있습니다. 기준은 특정 구성과 워크로드에 대한 데이터베이스의 표준 성능과 동작을 측정하는 맞춤설정된 데이터베이스 스냅샷 집합입니다.
Performance Snapshot Report의 대기 이벤트에 대한 자세한 내용은 데이터베이스 Performance Snapshot Report 참조를 확인하세요.
필요한 역할
pg_monitor 역할이 있는지 확인합니다.
이 역할은 수퍼유저에게 부여되며 슈퍼유저는 다른 사용자에게 pg_monitor를 부여할 수 있습니다.
예를 들어 postgres은 기본적으로 수퍼유저입니다. GRANT pg_monitor TO my_user를 postgres로 실행하면 my_user에서 이 문서에 설명된 성능 스냅샷 도구를 사용할 수 있습니다.
Performance Snapshot Report 설치
perfsnap은 사용자가 스냅샷을 캡처하거나 보고서를 생성할 수 있는 SQL 함수가 포함된 스키마 이름입니다. 이 스키마는 AlloyDB Omni g_stats 확장 프로그램의 일부입니다. 슈퍼유저 역할을 사용하여 Performance Snapshot Report를 설치합니다.
perfsnap API를 사용하려면 사용자가 확장 프로그램을 설치하려는 데이터베이스에 연결하고 다음 명령어를 사용하여 g_stats 확장 프로그램을 만듭니다.
CREATE EXTENSION IF NOT EXISTS g_stats;
시스템 측정항목 스냅샷 만들기
관심 있는 워크로드의 시작과 끝에 스냅샷을 만듭니다. 두 스냅샷 사이의 시간 간격은 워크로드가 충분히 진행될 수 있을 만큼 길어야 하며, 그래야 시스템이 워크로드를 반영하는 측정항목을 누적할 수 있습니다. 결과 Performance Snapshot Report에서 측정항목을 가져온 후 다른 스냅샷 세트를 가져와 프로세스를 반복할 수 있습니다.
psql클라이언트를 AlloyDB 인스턴스에 연결합니다.SELECT perfsnap.snap()를 실행합니다. 결과는 다음과 유사합니다.postgres=# select perfsnap.snap(); snap ------ 1 (1 row)
스냅샷 목록 보기
psql클라이언트를 AlloyDB 인스턴스에 연결합니다.SELECT * FROM perfsnap.g$snapshots를 실행합니다. 출력은 다음과 유사합니다.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)
스냅샷 보고서 생성
예를 들어 스냅샷 1과 2 간의 차이를 캡처하는 보고서를 생성하려면 SELECT perfsnap.report(1,2)를 실행합니다.
차등 작업에서 두 번째 스냅샷을 첫 번째 스냅샷 직후에 생성할 필요는 없습니다. 하지만 첫 번째 스냅샷 이후 차등에서 두 번째 스냅샷을 캡처해야 합니다.
생성된 Performance Snapshot Report는 다음 요약 예시와 유사합니다.
Performance Snapshot Report 예시
$ 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)
보고서 필드 및 성능 최적화 권장사항에 대한 자세한 내용은 데이터베이스 성능 최적화 권장사항을 참조하세요. Performance Snapshot Report의 대기 이벤트에 대한 자세한 내용은 데이터베이스 Performance Snapshot Report 참조를 확인하세요.
스냅샷 삭제
기존 기준에 포함된 스냅샷을 삭제하려면 먼저 기준을 삭제해야 합니다.
스냅샷을 삭제하려면 SELECT perfsnap.delete(n)를 실행합니다. 스냅샷을 삭제한 후에는 복구할 수 없습니다.
스냅샷을 성능 기준으로 표시
예를 들어 ID가 1~3인 모든 스냅샷을 시스템 성능 기준선으로 표시하려면 SELECT perfsnap.make_baseline(1, 3)을 실행합니다.
성능 기준 삭제
ID가 1~3인 모든 기준을 삭제하려면 SELECT perfsnap.clear_baseline(1, 3)을 실행합니다.
스냅샷 보고서 결과를 사용하여 데이터베이스 성능 최적화
다음 단계를 수행하여 AlloyDB 데이터베이스 성능을 최적화합니다.
- 데이터베이스가 유휴 상태이거나 평균 부하가 발생할 때 기준 스냅샷을 만듭니다.
- 성능을 향상시키려는 워크로드나 쿼리를 시작합니다.
- 워크로드나 쿼리가 최대 리소스 사용량에 도달하면 또 다른 스냅샷 집합을 만듭니다. 두 보고서 모두에 같은 간격을 사용하는 것이 좋습니다.
- 두 스냅샷 집합으로 만든 보고서를 비교하고 성능을 향상시킬 수 있는 변경사항을 식별합니다. 성능 권장사항에 대한 자세한 내용은 데이터베이스 성능 최적화 권장사항을 참조하세요.
데이터베이스 성능 최적화 권장사항
다음 표에는 Performance Snapshot Report 섹션과 각 보고서 섹션에 권장되는 개선사항이 나와 있습니다. Performance Snapshot Report 섹션과 대기 이벤트에 대한 자세한 내용은 데이터베이스 Performance Snapshot Report 참조를 확인하세요.
| 섹션 | 보고서 필드 | 보고서 필드 설명 | 최적화 추천 |
|---|---|---|---|
| 스냅샷 세부정보 | 스냅샷 세부정보 | 호스트, PostgreSQL 호환 출시 버전, 머신 실행 시간을 제공합니다. | 해당 사항 없음 |
| 스냅샷 ID | 이 보고서를 만드는 데 사용된 스냅샷의 ID와 시점을 나열합니다. | 해당 사항 없음 | |
| 시스템 통계 | 호스트 CPU | 호스트 CPU 사용률 세부정보입니다. | CPU 사용률이 80%를 초과하는 경우 vCPU가 더 많은 시스템으로 이동하는 것이 좋습니다. |
| 호스트 메모리 | 호스트 메모리 사용률 세부정보입니다. | 여유 메모리가 15% 미만이면 사용 가능한 다음 크기로 수직 확장하는 것이 좋습니다. | |
| 프로필 로드 | 생성된 미리 쓰기 로깅(WAL), I/O 요구사항, 연결 관리 측면에서 워크로드 특성을 파악하는 데 도움이 되는 카운터를 나열합니다. | 물리적 읽기가 논리적 읽기보다 높으면 데이터의 더 큰 캐싱이 지원되도록 다음 사용 가능한 크기로 수직 확장하는 것이 좋습니다. | |
| 응답 시간 및 대기 클래스 분류 | 워크로드 실행 중에 Postgres 프로세스에서 소요한 시간을 항목별로 나눠 보여줍니다. | 예를 들어 프로세스 대부분이 대기 상태인 경우 I/O 대기 시간을 줄이는 데 집중하여 조정합니다. | |
| 데이터베이스 워크로드 정보 | 데이터베이스별 워크로드 정보 | 커밋, 롤백, 적중률, 임시 테이블 및 정렬 작업에 대한 정보를 포함한 각 데이터베이스의 주요 측정항목입니다. | 롤백이 많은 경우 앱을 진단하는 것이 좋습니다. |
| 데이터베이스별 DML 및 DQL 정보 | 쿼리 작업 카운터입니다. | 워크로드를 읽기 중심 또는 쓰기 중심으로 분류합니다. | |
| 데이터베이스 충돌 정보 | 일반적인 애플리케이션 및 데이터베이스 문제 카운터입니다. | 교착 상태가 있으면 애플리케이션에서 문제를 찾습니다. | |
| 데이터베이스 크기 조정 정보 |
두 스냅샷 사이의 간격 동안 데이터베이스가 얼마나 커졌는지 보여줍니다. 이 필드에는 데이터베이스에 연결 제한이 설정되어 있는지 여부도 표시됩니다. | 데이터베이스 증가가 너무 큰 경우 애플리케이션에서 문제를 찾습니다. | |
| 배큠 정보 | 배큠 정보 | 배큠 작업의 I/O 및 카운터 세부정보입니다. | 기본적으로 AlloyDB는 적응형 배큠 작업을 실행합니다. 워크로드에 맞게 일부 배큠 설정을 재정의할 수 있습니다. 예를 들어 이러한 요청에 너무 많은 I/O가 사용되는 경우 배큠 작업을 줄입니다. |
| 데이터베이스별 배큠 정보 | 다음 정보를 표시합니다.
|
고정된 XID 필드의 기간이 너무 오래되었거나 사용된 트랜잭션 비율이 90%에 가까운 경우에는 배큠 작업을 사용하는 것이 좋습니다. 집계 배큠 간격이 감소하면 래핑이 방지되도록 Postgres에서 배큠을 강제로 적용함을 나타냅니다. | |
| 데이터베이스 프로세스 대기 세부정보 | 자세한 백엔드 및 백그라운드 프로세스 정보 |
보고 간격에 발생한 백엔드 및 백그라운드 프로세스에 의한 모든 대기의 세부정보입니다. 정보에는 누적 대기 시간, CPU 시간, 대기 유형별 평균 시간이 포함됩니다. | 예를 들어 WALWrite의 대기 시간을 줄이려면 데이터베이스에서 사용할 수 있는 wal_buffers 수를 늘립니다. |
| 상세 백엔드 및 백그라운드 대기 이벤트 히스토그램 | 이는 기본적으로 Performance Snapshot Report에 포함됩니다. 목록에는 백엔드 및 백그라운드 프로세스의 대기 이벤트 히스토그램이 포함되어 있으며, 이 히스토그램은 1μs부터 16초 이상까지 32개의 버킷으로 나뉩니다. | 대기 이벤트를 찾아 대기 시간이 긴 버킷에 대기 이벤트가 너무 많은지 확인합니다. 대기 이벤트가 너무 많거나 각 대기에서 소비된 시간에 문제가 있을 수 있습니다. | |
| 기타 통계 | 미리 쓰기 로그(WAL) 통계 | 미리 쓰기 로깅 통계 요약입니다. | 동기화 시간이 너무 길면 워크로드가 향상되도록 관련 데이터베이스 플래그(GUC)를 조정합니다. GUC는 서버 구성을 처리하는 PostgreSQL 하위 시스템입니다. |
| 요약 통계(모든 데이터베이스) | 스냅샷 간격 중에 발생하는 모든 데이터베이스 작업의 요약입니다. | 해당 사항 없음 | |
| 매개변수 설정 | 매개변수 설정 | 최종 스냅샷 시간의 주요 Postgres 구성 파라미터입니다. | GUC 파라미터 설정(Postgres 데이터베이스 플래그)을 확인하여 값이 예상되지 않거나 권장되지 않는 값인지 확인합니다. |
제한사항
공간 팽창이 방지되도록 인스턴스 하나에서 스냅샷을 최대 2,500개까지 수동으로 만들 수 있습니다. 공간 팽창을 사용하면 스냅샷이 데이터베이스에서 너무 많은 저장공간을 차지하지 않습니다.
스냅샷 수가 스냅샷 한도를 초과하면 AlloyDB Omni에서 90일이 지난 모든 수동 스냅샷을 삭제합니다. 스냅샷 한도를 초과하지 않으려면 새 스냅샷을 만들기 전에 불필요한 스냅샷을 정리해야 합니다.
AlloyDB Omni는 90일이 지난 수동 스냅샷을 주기적으로 정리합니다.