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