Amazon Redshift WLM 메모리 할당을 사용하고 관리하려면 어떻게 해야 합니까?
대기열에 대한 동시성 및 Amazon Redshift 워크로드 관리(WLM) 할당을 확인하려고 합니다. WLM 할당은 어떻게 작동하며 언제 사용해야 합니까?
간략한 설명
Amazon Redshift 워크로드 관리(WLM)를 사용하면 여러 쿼리 대기열을 관리하고 정의할 수 있습니다. 워크로드 관리는 런타임에 쿼리에 대한 메모리 할당과 함께 쿼리를 적절한 대기열로 라우팅합니다. 일부 쿼리는 더 많은 클러스터 리소스를 소비하여 다른 쿼리의 성능에 영향을 줄 수 있습니다.
다음 방법 중 하나로 리소스를 효과적으로 관리하도록 워크로드 관리를 구성할 수 있습니다.
- 자동 WLM: Amazon Redshift에서 대기열의 동시성 레벨 및 전송된 각 쿼리에 대한 메모리 할당을 관리할 수 있습니다. 전송된 쿼리를 통해 사용자는 각 쿼리 대기열에 대한 워크로드 또는 사용자의 쿼리 우선 순위를 정의할 수 있습니다.
- 수동 WLM: 대기열에 대한 동시성 레벨 및 메모리 할당을 보다 세부적으로 제어할 수 있습니다. 따라서 리소스 소비가 더 많은 쿼리가 리소스 할당량이 더 많은 대기열에서 실행될 수 있습니다.
참고: 지표 기반 성능 경계를 정의하려면 워크로드 관리 구성과 함께 쿼리 모니터링 규칙(QMR)을 사용합니다.
대기열에 대한 동시성 레벨 및 WLM 할당을 확인하려면 다음 단계를 수행하세요.
-
Amazon Redshift 클러스터의 현재 WLM 구성을 확인합니다.
-
쿼리 대기열의 배포 및 동시성 레벨을 지정하여 테스트 워크로드 관리 구성을 생성합니다.
-
(선택 사항) 수동 WLM을 사용하는 경우 슬롯 수 사이에 메모리가 분배되는 방식을 결정합니다.
해결 방법
WLM 구성 및 메모리 사용량 확인
STV_WLM_SERVICE_CLASS_CONFIG 테이블을 사용하여 Amazon Redshift 클러스터의 현재 WLM 구성을 확인하십시오.
[ { "query_concurrency": 2, "memory_percent_to_use": 30, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group1" ], "user_group_wild_card": 0, "rules": [ { "rule_name": "BlockstoDiskSpill", "predicate": [ { "metric_name": "query_temp_blocks_to_disk", "operator": ">", "value": 50 } ], "action": "abort" } ] }, { "query_concurrency": 5, "memory_percent_to_use": 40, "query_group": [], "query_group_wild_card": 0, "user_group": [ "user_group2" ], "user_group_wild_card": 0 }, { "query_concurrency": 5, "memory_percent_to_use": 10, "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "rules": [ { "rule_name": "abort_query", "predicate": [ { "metric_name": "scan_row_count", "operator": ">", "value": 1000 } ], "action": "abort" } ] }, { "query_group": [], "query_group_wild_card": 0, "user_group": [], "user_group_wild_card": 0, "auto_wlm": false }, { "short_query_queue": false } ]
참고: 이 예에서 WLM 구성은 JSON 형식이며 쿼리 모니터링 규칙(Queue1)을 사용합니다.
WLM 구성에서 "memory_percent_to_use"는 서비스 클래스에 할당된 실제 작업 메모리 양을 나타냅니다.
Amazon Redshift는 클러스터의 공유 리소스 풀에서 메모리를 할당합니다. 따라서 Queue1의 메모리 할당량은 30%이며 두 개의 동일한 슬롯으로 더 나뉩니다. 각 슬롯은 현재 메모리 할당에서 동일하게 15%를 점유합니다. 한편 Queue2의 메모리 할당량은 40%이며 5개의 동일한 슬롯으로 더 나뉩니다. 각 슬롯은 메모리 할당에서 동일하게 8%를 점유합니다. 기본 대기열은 대기열 동시성 레벨이 5인 메모리 할당의 10%를 사용합니다.
다음 쿼리를 사용하여 Amazon Redshift WLM의 서비스 클래스 구성을 확인하십시오.
select rtrim(name) as name, num_query_tasks as slots, query_working_mem as mem, max_execution_time as max_time, user_group_wild_card as user_wildcard, query_group_wild_card as query_wildcard from stv_wlm_service_class_config where service_class > 4;
출력 예는 다음과 같습니다.
name | slots | mem | max_time | user_wildcard | query_wildcard ----------------------------------------------------+-------+-----+----------+---------------+---------------- Service class for super user | 1 | 297 | 0 | false | false Queue 1 | 2 | 522 | 0 | false | false Queue 2 | 5 | 278 | 0 | false | false Default queue | 5 | 69 | 0 | false | false Service class for vacuum/analyze | 0 | 0 | 0 | false | false
Queue 1의 슬롯 수는 2이고 각 슬롯(또는 노드)에 할당된 메모리는 522MB입니다. 메모리 할당은 서비스 클래스에 할당된 각 노드에 대한 슬롯당 현재 작업 중인 메모리의 실제 양(MB)을 나타냅니다.
참고: 모든 쿼리 슬롯을 사용하는 경우 할당되지 않은 메모리는 Amazon Redshift에서 관리합니다. 처리를 위해 대기열이 추가 메모리를 요청하는 경우 할당되지 않은 메모리를 일시적으로 대기열에 제공할 수 있습니다. 예를 들어 네 개의 대기열을 구성하는 경우 20%, 30%, 15%, 15%와 같이 메모리를 할당할 수 있습니다. 나머지 20%는 할당되지 않고 서비스에 의해 관리됩니다. 할당되지 않은 메모리 관리에 대한 자세한 내용은 사용할 WLM 메모리 비율을 참조하세요.
상위 레벨 조정 파라미터 식별
다음은 쿼리에 대한 쿼리 실행 계획의 예입니다.
- SVL_QUERY_METRICS_SUMMARY 테이블을 사용하여 세부 실행을 확인하고 "query_queue_time" 열을 사용하여 대기열에 추가되는 쿼리를 확인하십시오. "query_queue_time" 열은 쿼리가 WLM 슬롯이 실행될 때까지 대기열에서 대기하고 있음을 나타냅니다.
- 쿼리가 메모리에서 실행된 경우에도 쿼리에 대한 메모리 소비를 확인하려면 SVL_QUERY_SUMMARY 테이블을 사용하세요.
dev=# select userid, query, service_class, query_cpu_time, query_blocks_read, query_execution_time, query_cpu_usage_percent, query_temp_blocks_to_disk, query_queue_time from SVL_QUERY_METRICS_SUMMARY where query=29608; userid | query | service_class | query_cpu_time | query_blocks_read | query_execution_time | query_cpu_usage_percent | query_temp_blocks_to_disk | query_queue_time --------+-------+---------------+----------------+-------------------+----------------------+-------------------------+---------------------------+------------------ 100 | 29608 | 8 | 18 | 942 | 64 | 10.05 | | (1 row) ev=# select query, step, rows, workmem, label, is_diskbased from svl_query_summary where query = 29608 order by workmem desc; query | step | rows | workmem | label | is_diskbased -------+------+----------+----------+-----------------------------------------+-------------- 29608 | 3 | 49999 | 54263808 | hash tbl=714 | f 29608 | 2 | 49999 | 0 | project | f 29608 | 0 | 49999 | 0 | scan tbl=255079 name=part | f 29608 | 1 | 49999 | 0 | project | f 29608 | 6 | 1561938 | 0 | return | f 29608 | 4 | 1561938 | 0 | project | f 29608 | 5 | 1561938 | 0 | project | f 29608 | 2 | 29995220 | 0 | project | f 29608 | 1 | 1561938 | 0 | return | f 29608 | 1 | 29995220 | 0 | project | f 29608 | 0 | 1561938 | 0 | scan tbl=4893 name=Internal Worktable | f 29608 | 3 | 1561938 | 0 | hjoin tbl=714 | f 29608 | 0 | 29995220 | 0 | scan tbl=255087 name=lineorder | f (13 rows)
SVL_QUERY_SUMMARY 테이블을 사용하여 쿼리의 각 단계에서 리소스 할당에 대한 세부 정보 보기를 얻을 수 있습니다. 리소스 사용량을 보려면 is_diskbased 및 workmem 열을 확인합니다. 자세한 내용은 쿼리 요약 분석을 참조하십시오.
WLM 동적 구성 속성으로 업데이트
WLM 동적 구성 속성을 사용하여 변화하는 워크로드에 맞게 조정할 수도 있습니다. 클러스터를 재부팅하지 않고도 데이터베이스에 동적 속성을 적용할 수 있습니다. 그러나 WLM 정적 구성 속성은 변경 내용을 적용하려면 클러스터를 재부팅해야 합니다.
다음은 두 개의 대기열로 구성된 클러스터의 예입니다.
Queue Concurrency % Memory to Use 1 5 60% 2 5 40%
클러스터에 200GB의 사용 가능한 메모리가 있는 경우 각 대기열 슬롯에 대한 현재 메모리 할당은 다음과 같습니다.
Queue 1: (200 GB * 60% ) / 5 slots = 24 GB Queue 2: (200 GB * 40% ) / 5 slots = 16 GB
WLM 구성 속성을 동적으로 업데이트하려면 다음과 같이 설정을 수정하십시오.
Queue Concurrency % Memory to Use 1 3 75% 2 4 25%
결과적으로 변경된 워크로드를 수용하도록 메모리 할당이 업데이트되었습니다.
Queue 1: (200 GB * 75% ) / 3 slots = 50 GB Queue 2: (200 GB * 25% ) / 4 slots = 12.5 GB
참고: 동적 구성 업데이트 중에 WLM 대기열에 실행 중인 쿼리가 있는 경우 Amazon Redshift는 쿼리가 완료될 때까지 기다립니다. 쿼리가 완료되면 Amazon Redshift는 업데이트된 설정으로 클러스터를 업데이트합니다.
동적 WLM 구성 속성으로의 전환이 진행되는 동안 STV_WLM_SERVICE_CLASS_CONFIG 테이블을 사용합니다. num_query_tasks(동시성) 및 query_working_mem(동적 메모리 백분율) 열이 대상 값에서 같아지면 전환이 완료됩니다.
쿼리에 할당된 메모리 부족 식별
SVL_QUERY_SUMMARY의 쿼리 실행 계획에서 is_diskbased 값이 "true"인 경우 쿼리에 더 많은 메모리를 할당하는 것이 좋습니다. 사용되는 쿼리 슬롯 수를 늘려 더 많은 메모리를 할당할 수 있습니다. 자세한 내용은 1단계: wlm_query_slot_count를 사용하여 동시성 레벨 재정의를 참조하세요.
참고: 먼저 디스크 유출을 유발하는 단계를 식별하는 것이 좋습니다. 그런 다음, 대기열에 더 많은 메모리를 할당하여 문제를 해결할 수 있는지 확인하세요. 또는 쿼리를 최적화할 수 있습니다.
관련 콘텐츠
- AWS 공식업데이트됨 3년 전
- AWS 공식업데이트됨 2년 전
- AWS 공식업데이트됨 4달 전
- AWS 공식업데이트됨 일 년 전
