Amazon Redshift 인스턴스의 디스크 사용량이 높거나 가득 찼습니다. Amazon Redshift에서 디스크 사용량이 높아지는 문제를 해결하려면 어떻게 해야 합니까?

높은 디스크 사용량은 여러 요인에 의해 발생할 수 있으며, 원인을 식별하기 위해 Amazon Redshift가 디스크 사용 작업을 모니터링하는 방식을 이해하는 것이 중요합니다. 각 클러스터 노드에 대해 Amazon Redshift는 추가 공간을 제공합니다. 이 공간은 내부용으로 Amazon Redshift에서 예약한 원시 디스크 공간입니다. 이 추가 공간은 사용자가 사용할 수 있는 디스크 공간 크기인 공칭 디스크 용량보다 큽니다. 원시 디스크 공간을 보여주는 Amazon CloudWatch 그래프 및 STV_PATRITION 테이블에서 다양한 Amazon Redshift 디스크 사용률을 확인할 수 있습니다. 모니터링을 위해 디스크 공간의 비율 지표를 사용하는 것이 좋습니다. 디스크 공간은 클러스터 전체에 대해 계산되는 것이 아니라 노드마다 계산됩니다. 노드에 더 이상 사용 가능한 디스크 공간이 없으며 쿼리 실행 중 해당 노드에 실행되는 세그먼트에 디스크 공간이 필요한 경우 Amazon Redshift는 쿼리를 취소하고 해당 트랜잭션을 롤백하여 리소스를 해제합니다. 클러스터에서 사용되는 공칭 디스크 용량의 비율을 보려면 다음을 수행하십시오.

  1. Amazon Redshift 콘솔을 연 다음 탐색 창에서 클러스터를 선택합니다.
  2. 클러스터를 선택한 다음 성능 보기를 선택합니다.
  3. 디스크 공간의 비율에 나열된 지표를 봅니다.

테이블 설계를 위한 Amazon Redshift 모범 사례를 검토하여 디스크 사용량이 급증하고 쿼리 성능이 저하될 수 있는 불량 테이블 디자인을 방지합니다. 특히 편향된 데이터를 방지하기 위한 양호한 배포 키를 사용하고, 쿼리 패턴에 따라 정렬 키를 사용하고, 과도한 메모리 및 임시 디스크 공간의 사용을 방지하기 위해 작은 열 크기를 사용해야 합니다.

갑작스럽게 디스크 공간 사용률이 급증하는 경우 STL_QUERY 테이블을 사용하여 급증하는 동안 실행되는 활동과 작업을 식별합니다. 다음과 유사한 쿼리를 실행하여 특정 기간 동안 실행되는 쿼리를 식별합니다.

select * from stl_query where starttime between '2018-01-01 00:30:00' and '2018-01-01 00:40:00';

참고: 사용률이 급증한 기간의 값을 업데이트하십시오.

일관된 높은 디스크 사용량은 다음과 관련이 있을 수 있습니다.

배포 및 정렬 키 - 테이블의 배포 스타일, 배포 키 및 정렬 키 선택을 검토합니다. 배포 스큐가 있으며 다른 노드보다 한 노드에 더 많은 데이터가 있는 테이블로 인해 디스크 노드가 가득 찰 수 있습니다. 행 스큐는 노드 간 균형이 맞춰지지 않은 테이블 스토리지로 인해 발생합니다. 즉, 특정 테이블의 노드 간에 행의 수가 매우 다릅니다. 배포 스큐 또는 행 스큐는 쿼리 실행 중 중간 행 집합 및 노드 수준 디스크 공간에 영향을 줄 수 있습니다(스토리지 스큐). 예를 들어, 카디널리티가 낮은 열을 KEY(DISTSTYLE) 배포에 대한 DISTKEY로 선택하면 몇 개의 슬라이스에만 데이터가 채워질 수 있습니다. 단일 노드의 디스크 사용량 급증은 배포 키 열에서 단일 값이 우세해서 발생할 수도 있습니다. 자세한 내용은 DISTSTYLE, DISTKEY 및 SORTKEY 옵션을 참조하십시오.

데이터 배포가 최적이 아니며 배포 키가 편향된 테이블이 있는 경우 배포 스타일이나 배포 키를 높은 카디널리티와 균일한 배포가 나타나는 열로 변경하는 것을 고려하십시오. 자세한 내용은 데이터 분배 유형 선택을 참조하십시오. 균일하지 않은 데이터 배포를 식별하려면 데이터 스큐가 발생하거나 미정렬 행이 포함된 테이블 식별을 참조하십시오. 또한 Amazon Redshift table_inspector.sql 유틸리티를 사용하여 배포 키의 데이터베이스 블록이 클러스터의 슬라이스로 매핑되는 방법과 데이터가 클러스터에 배포되는 방법을 확인할 수 있습니다.

다음과 유사한 쿼리를 실행하여 배포 키의 카디널리티를 결정합니다.  

select distkey, count(*) from public.distribution_skew group by distkey having count(*) > 1 order by 2 desc;

참고: ORDER BY 절의 SORT KEY 열을 사용하여 과도한 메모리를 사용하고 디스크로 유출될 수 있는 사용량이 많은 SORT STEP을 방지할 수도 있습니다. 자세한 내용은 정렬 키 선택을 참조하십시오.

쿼리 처리 - 쿼리에 할당된 메모리를 검토합니다. 쿼리가 처리되는 동안 중간 쿼리 결과를 임시 블록에 저장할 수 있습니다. 사용 가능한 메모리가 충분하지 않은 경우 테이블이 디스크로 유출됩니다. 중간 결과 집합은 압축되지 않아 사용 가능한 디스크 공간에 영향을 줄 수 있습니다. 자세한 내용은 쿼리에 할당되는 메모리 부족을 참조하십시오. Amazon Redshift에서는 배포가 균등하고 임시 테이블에 대한 열 인코딩이 없는 테이블 구조로 기본 설정되므로 SELECT...INTO 구문을 사용할 경우 CREATE 문의 사용을 고려하십시오. 자세한 내용은 문제 #10 – 임시 테이블의 비효율적인 사용을 참조하십시오.

쿼리에 할당되는 메모리가 부족하면 is_diskbased 값이 "true"인 SVL_QUERY_SUMMARY의 단계가 표시될 수 있습니다. 이 문제를 해결하려면 쿼리 슬롯의 수를 일시적으로 늘려서 쿼리에 더 많은 메모리를 할당합니다. 그러면 쿼리가 디스크로 유출되는 것을 방지할 수 있습니다. 쿼리에 사용할 슬롯 수를 일시적으로 늘리는 방법에 대한 자세한 내용은 wlm_query_slot_count 또는 복합 워크로드를 실행하도록 WLM 조정을 참조하십시오. 또한 WLM -QMR 규칙을 사용하여 과도하게 리소스를 사용하는 로드에 대응하고 I/O 집약적인 쿼리를 식별할 수 있습니다.

VARCHAR(MAX) 열이 포함된 테이블 - 데이터가 디스크에 저장될 때 생략되지만 쿼리 처리 중 메모리에서 전체 길이(VARCHAR의 경우 최대값: 65535)를 차지할 수 있는 후행 공백에 대한 VARCHAR 또는 CHARACTER VARYING 열을 확인합니다. 큰 VARCHAR 열이 포함된 테이블이 있는 경우 이러한 열에 대해 데이터를 처리하면 메모리에 중간 행 집합이 감소되고 더 많이 디스크로 유출되어 디스크 사용량이 높아집니다. 자세한 내용은 가능한 최소 열 크기 사용을 참조하십시오.

다음과 유사한 쿼리를 실행하여 열 너비가 최대인 테이블 목록을 생성합니다.

SELECT database, schema || '.' || "table" AS "table", max_varchar FROM svv_table_info WHERE max_varchar > 150 ORDER BY 2;

테이블 목록을 생성한 후에는 넓은 VARCHAR 열이 있는 테이블 열을 식별한 후 다음과 유사한 쿼리를 실행하여 각각의 넓은 열에 대한 실제 최대 너비를 결정합니다.

SELECT max(octet_length (rtrim(column_name))) FROM table_name;

높은 열 압축 - 최적의 열 인코딩을 위해 Analyze Compression 또는 Amazon Redshift Column Encoding Utility를 사용하여 모든 열을 인코딩합니다(정렬 키 제외). Amazon Redshift는 읽기 성능을 향상시키고 전체 스토리지 소비를 감소시킬 수 있는 열 인코딩을 제공합니다. 시스템에서 제안하는 압축을 사용하는 것이 가장 좋습니다.

유지 관리 작업 - 테이블에 누락 또는 오래된 통계가 있는지 검토합니다. 이로 인해 최적이 아닌 실행 계획이 수립될 수 있습니다. VACUUM 및 DEEP COPY와 같은 유지 관리 작업은 정렬 작업에 대해 중간 임시 스토리지 공간을 사용하므로 디스크 사용량이 급증합니다. 누락 또는 오래된 통계를 식별하면 쿼리 실행 계획을 최적화할 수 있으며, 불필요한 행을 읽고 스캔하는 것을 방지할 수 있습니다.

다음과 유사한 쿼리를 실행하여 오래된 통계를 찾습니다.

SELECT * FROM svv_table_info WHERE stats_off > 10 ORDER BY size DESC;

최적의 Amazon Redshift 데이터베이스 성능을 위해 데이터베이스 테이블을 정기적으로 분석하고 정리해야 합니다. 자세한 내용은 Amazon Redshift 분석 및 정리 스키마 유틸리티를 참조하십시오.

데카르트 조인 - 크로스 조인(데카르트 곱)이 발생하는 조인 조건이 있으며, 블록의 수가 증가되어 더 많은 메모리를 활용하고 테이블을 디스크로 유출할 수 있는 쿼리를 찾습니다. 크로스 조인에 조인 조건이 없는 경우 두 테이블의 데카르트 곱이 발생할 수 있습니다. 크로스 조인은 일반적으로 가능한 조인 유형 중 가장 느린 중첩 루프 조인으로 실행되므로 대량의 데이터가 디스크로 유출될 수 있어 전체 디스크 사용량이 급증할 수 있습니다. 자세한 내용은 중첩 루프가 포함된 쿼리 식별을 참조하십시오.

최소 테이블 크기 - 두 개의 서로 다른 Amazon Redshift 클러스터 간에 테이블 크기가 서로 다른지 확인하기 위해 테이블 크기를 검토합니다. Amazon Redshift 클러스터 구성이 서로 다른 두 테이블에 할당된 공간은 상당히 다를 수 있으므로 최근에 Amazon Redshift 클러스터의 크기를 조정한 경우 전체 디스크 스토리지에 변경 사항이 있는 것을 확인할 수 있습니다. 각 테이블에 대한 디스크 스토리지 공간 할당은 주로 각 Amazon Redshift 클러스터에서 채워진 슬라이스 수와 각 테이블에서 사용되는 테이블 세그먼트 수의 함수입니다. 자세한 내용은 Amazon Redshift 클러스터의 테이블이 예상보다 많거나 적은 디스크 스토리지 공간을 소비하는 이유는 무엇입니까?를 참조하십시오.

삭제 표시 블록 - 삭제 표시 블록은 일반적으로 Amazon Redshift 테이블에 대한 쓰기 트랜잭션이 발생할 때 생성됩니다. Amazon Redshift에서 블록은 변경할 수 없습니다(변경 불가능). 삽입, 업데이트 또는 삭제 작업은 새로운 삭제 표시 블록 집합을 생성하며, 이전 블록을 "삭제됨"으로 표시합니다. 일반적으로 커밋 시 삭제 표시가 지워지지만, 장기 실행 트랜잭션이 테이블을 읽고 여러 ETL 로드가 동시에 실행될 때 문제가 발생할 수 있습니다. Amazon Redshift는 트랜잭션이 시작될 때부터 트랜잭션이 실행되는 동안 일관된 데이터베이스 보기로 장기 실행 트랜잭션을 제공해야 하므로 데이터베이스에 작성된 모든 테이블에는 삭제 표시 블록이 유지됩니다. 이러한 사항이 정기적으로 여러 로드에 발생할 경우 충분한 삭제 표시가 누적되어 "디스크가 가득 참" 오류가 발생할 수 있습니다. 장기 실행 활성 쿼리가 있는 경우 후속 커밋에 대해 모든 블록이 해제되도록 쿼리를 종료합니다. 또는 블록을 해제하기 위해 장기 실행 쿼리를 종료한 후 다음과 유사한 명령을 실행하여 더미 커밋을 즉시 실행할 수 있습니다.

begin;
create table a (id int);
insert into a values(1);
commit;
drop table a; 

다음과 유사한 쿼리를 실행하여 삭제 표시 블록을 확인합니다.

select trim(name) as tablename, count(case when tombstone > 0 then 1 else null end) as tombstones from svv_diskusage group by 1 having count(case when tombstone > 0 then 1 else null end) > 0 order by 2 desc;

COPY 중 디스크 가득 참 - COPY 작업 중 사용 가능한 스토리지가 충분한 경우에도 "디스크 가득 참" 오류가 발생할 수 있습니다. 정렬 작업이 디스크로 유출되어 임시 블록이 생성될 경우 이 오류가 발생할 수 있습니다. 모범 사례는 데이터 로딩을 위한 Amazon Redshift 모범 사례를 참조하십시오.

쿼리 문제 해결 - 다음 쿼리는 높은 디스크 사용량의 근원을 해결하는 데 도움이 될 수 있습니다.

다음과 유사한 쿼리를 실행하여 상위 20개의 디스크 유출 쿼리를 식별합니다.

select A.userid, A.query, blocks_to_disk, trim(B.querytxt) text from stl_query_metrics A, stl_query B where A.query = B.query and segment=-1 and step = -1 and max_blocks_to_disk > 0 order by 3 desc limit 20;

다음과 유사한 쿼리를 실행하여 디스크에 쿼리가 작성되는지 여부를 확인합니다.

SELECT q.query, trim(q.cat_text)
FROM (
SELECT query,
replace( listagg(text,' ') WITHIN GROUP (ORDER BY sequence), '\\n', ' ') AS cat_text
FROM stl_querytext
WHERE userid>1
GROUP BY query) q
JOIN (
SELECT distinct query
FROM svl_query_summary
WHERE is_diskbased='t'
AND (LABEL ILIKE 'hash%' OR LABEL ILIKE 'sort%' OR LABEL ILIKE 'aggr%' OR LABEL ILIKE 'save%' OR LABEL ILIKE 'window%' OR LABEL ILIKE 'unique%')
AND userid > 1) qs
ON qs.query = q.query;

페이지 내용이 도움이 되었습니까? | 아니요

AWS 지원 지식 센터로 돌아가기

도움이 필요하십니까? AWS 지원 센터를 방문하십시오.

게시 날짜: 2018-08-31