Amazon Redshift에서 디스크 사용량이 높거나 가득 찬 문제를 해결하려면 어떻게 해야 합니까?

해결 방법

Amazon Redshift의 높은 디스크 사용률 또는 가득 찬 디스크 사용률 문제를 해결하려면 다음 문제 해결 단계를 따르십시오.

배포 및 정렬 키

테이블의 분포 스타일, 배포 키 및 정렬 키 선택을 검토합니다. 분포 왜도가 있는 테이블로 인해 디스크 노드가 가득 찰 수 있습니다. 왜도된 분포 스타일의 테이블이 있는 경우 분포 스타일을 보다 균일한 분포로 변경하십시오. 분포 및 행 왜도는 쿼리가 실행될 때 스토리지 왜도 및 중간 행 집합에 영향을 줄 수 있습니다.

배포 키의 카디널리티를 가져오려면 다음 쿼리를 실행합니다.

SELECT <distkey column>, COUNT(*)
 FROM <schema name>.<table with distribution skew>
 GROUP BY <distkey column>
 HAVING COUNT(*) > 1
 ORDER BY 2 DESC;

참고: distkey column, schema name, 테이블을 table with distribution skew를 테이블 변수로 바꾸십시오.

정렬 단계를 피하려면 ORDER BY 절에서 SORT KEY 열을 사용하십시오. 정렬 단계에서 과도한 메모리가 사용되어 디스크 유출이 발생할 수 있습니다. 자세한 내용은 정렬 키를 참조하십시오.

필터링된 결과 집합에서 카디널리티가 높은 열을 선택하면 해당 데이터 분포를 볼 수 있습니다. 자세한 내용은 최상의 분포 스타일 선택을 참조하십시오.

쿼리 처리

할당된 쿼리 메모리를 검토합니다. 중간 쿼리 결과는 쿼리가 처리될 때 임시 블록에 저장할 수 있습니다. 사용 가능한 메모리가 충분하지 않으면 테이블로 인해 디스크 유출이 발생합니다. 중간 결과 집합은 압축되지 않아 사용 가능한 디스크 공간에 영향을 줍니다. 자세한 내용은 쿼리에 할당된 메모리 부족을 참조하십시오.

Amazon Redshift는 기본적으로 균등하게 분포되고 임시 테이블에 대한 열 인코딩이 없는 테이블 구조를 사용합니다. SELECT...INTO 구문을 사용하는 경우 CREATE 문을 사용하십시오. 자세한 내용은 Amazon Redshift를 위한 상위 10가지 성능 조정 기술의 팁 #6을 참조하십시오.

쿼리에 충분한 메모리가 할당되지 않은 경우 SVL_QUERY_SUMMARY에 단계가 표시될 수 있습니다. 여기서 is_diskbased는 true 값을 표시합니다. 다음 쿼리는 지정된 시간 동안 발생한 상위 20개의 디스크 유출 쿼리를 식별합니다.

SELECT q.userid, q.query, q.starttime, q.endtime, m.query_temp_blocks_to_disk, btrim(querytxt)  
 FROM stl_query q JOIN SVL_QUERY_METRICS_SUMMARY m ON m.query = q.query
 WHERE m.query_temp_blocks_to_disk > 0
   AND starttime BETWEEN '2025-01-01 00:00:00' AND '2025-01-02 00:00:00'
 ORDER BY m.query_temp_blocks_to_disk DESC
 LIMIT 20;

이 문제를 해결하려면 쿼리 슬롯 수를 늘려 쿼리에 더 많은 메모리를 할당하십시오.

사용률이 갑자기 급증하는 경우 다음 쿼리를 실행하여 상위 20개의 디스크 유출 쿼리를 식별하십시오.

SELECT a.userid, a.query, a.blocks_to_disk, trim(b.text) as text
 FROM stv_query_metrics a, stv_inflight b
 WHERE a.query = b.query
   AND a.segment = -1
   AND a.step_type = -1
   AND a.max_blocks_to_disk > 0
 ORDER BY 3 DESC
 LIMIT 20;

출력에서 blocks_to_disk 열 값을 쿼리하여 디스크 유출을 식별합니다. 유출이 너무 많은 쿼리를 종료한 다음, 쿼리에 메모리를 더 할당한 후 쿼리를 다시 실행하십시오.

또한 WLM 쿼리 모니터링 규칙을 사용하여 과도한 프로세스 로드에 대응하고 I/O 집약적인 쿼리를 식별할 수 있습니다.

VARCHAR(MAX) 열이 있는 테이블

데이터를 디스크에 저장할 때 생략될 수 있는 후행 공백이 있는지 VARCHAR 또는 CHARACTER VARYING 열을 확인하십시오. 쿼리가 처리될 때 후행 공백이 메모리의 전체 길이를 차지할 수 있습니다. VARCHAR 및 CHARACTER VARYING의 최댓값은 65535바이트입니다. 가능한 가장 작은 열 크기를 사용하는 것이 가장 좋습니다.

최대 열 너비의 테이블 목록을 생성하려면 다음 쿼리를 실행합니다.

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;

이 쿼리의 출력에서 길이가 사용 사례에 맞는지 확인하십시오. 열이 최대 길이이고 요구 사항을 초과하는 경우 필요한 최소 크기로 길이를 조정하십시오.

자세한 내용은 Amazon Redshift 테이블 설계 모범 사례를 참조하십시오.

높은 열 압축

정렬 키를 제외한 모든 열을 인코딩하려면 ANALYZE COMPRESSION 또는 자동 테이블 최적화를 사용하십시오. 열 인코딩을 사용하는 것이 가장 좋습니다.

유지 관리 작업

Amazon Redshift 데이터베이스의 데이터베이스 테이블을 정기적으로 분석하고 정리해야 합니다. 통계가 누락된 테이블에 대해 실행되는 쿼리를 식별합니다. 그런 다음, Amazon Redshift가 불필요한 테이블 행을 스캔하지 않도록 통계가 누락된 테이블에 대해 실행되는 쿼리를 방지합니다.

참고: VACUUM 및 DEEP COPY와 같은 유지 관리 작업은 정렬 작업에 임시 스토리지 공간을 사용하므로 디스크 사용량이 급증할 수 있습니다.

예를 들어, 다음 쿼리는 Amazon Redshift에서 오래된 통계를 식별합니다.

SELECT table_id, database, schema, "table", stats_off, size
 FROM svv_table_info
 WHERE stats_off > 10
 ORDER BY size DESC;

또한 ANALYZE 명령을 사용하여 테이블 통계를 보고 분석할 수 있습니다.

크로스 조인이 있는 카테시안 곱

쿼리의 EXPLAIN 계획을 사용하여 카테시안 곱이 있는 쿼리를 찾습니다. 카테시안 곱은 서로 관련이 없고 블록 번호를 높일 수 있는 크로스 조인입니다. 이러한 크로스 조인으로 인해 메모리 사용률이 늘어나고 디스크에 더 많은 테이블이 유출될 수 있습니다. 크로스 조인이 JOIN 조건을 공유하지 않는 경우 조인은 두 테이블의 카테시안 곱을 생성합니다. 한 테이블의 모든 행은 다른 테이블의 모든 행과 조인됩니다.

크로스 조인은 중첩 루프 조인으로 실행될 수도 있어 처리 시간이 길어질 수 있습니다. 중첩 루프 조인으로 인해 전체 디스크 사용량이 급증합니다. 자세한 내용은 중첩 루프로 쿼리 식별을 참조하십시오.

최소 테이블 크기

클러스터마다 개별 테이블의 크기가 다를 수 있습니다. 최소 테이블 크기는 열 수, 테이블에 SORTKEY가 있는지 여부 및 채워진 슬라이스 수에 따라 결정됩니다. 최근에 Amazon Redshift 클러스터의 크기를 조정한 경우 슬라이스 변경으로 인해 전체 디스크 스토리지가 변경될 수 있습니다. Amazon Redshift는 각 테이블에서 사용하는 테이블 세그먼트도 계산합니다. 자세한 내용은 Amazon Redshift 클러스터의 테이블이 예상보다 많거나 적은 디스크 스토리지 공간을 소비하는 이유는 무엇입니까?를 참조하십시오.

삭제 표식 블록

삭제 표식 블록은 Amazon Redshift 테이블에 대한 쓰기 트랜잭션이 발생하고 동시 읽기 작업이 있을 때 생성됩니다. Amazon Redshift는 동시 읽기 작업의 일관성을 유지하기 위해 쓰기 작업 전 블록을 보관합니다. Amazon Redshift 블록은 변경할 수 없습니다. 모든 삽입, 업데이트 또는 삭제 작업은 새 블록 세트를 만들고 이전 블록을 삭제 표기됨으로 표시합니다.

장기 실행 테이블 트랜잭션으로 인해 커밋 단계에서 삭제 표식이 지워지지 않는 경우가 있습니다. 동시에 실행되는 ETL 로드가 너무 많으면 삭제 표식이 지워지지 않을 수도 있습니다. Amazon Redshift는 트랜잭션이 시작되는 시점부터 데이터베이스를 모니터링하기 때문에 데이터베이스에 기록된 모든 테이블에도 삭제 표식 블록이 유지됩니다. 장기 실행 테이블 트랜잭션이 정기적으로 여러 로드에 걸쳐 발생하는 경우, 충분한 삭제 표식이 누적되어 "Disk Full" 오류가 발생할 수 있습니다.

활성 상태인 장기 실행 쿼리가 있는 경우 commit 명령을 실행하여 쿼리를 종료하고 후속 블록을 모두 해제합니다.

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 작업 시 "Disk Full 오류"가 발생할 수 있습니다. 이 오류는 정렬 작업이 디스크로 유출되어 임시 블록을 만들 때 발생합니다.

"Disk Full" 오류가 발생하면 STL_DISK_FULL_DIAG 테이블을 확인하십시오. 임시 블록과 오류를 일으킨 쿼리 ID를 확인합니다.

SELECT
  '2000-01-01'::timestamp + (currenttime/1000000.0)* interval '1 second' as currenttime,
  node_num,
  query_id,
  temp_blocks
 FROM stl_disk_full_diag;

자세한 내용은 Amazon Redshift 데이터 로드 모범 사례를 참조하십시오.

소비자 클러스터의 데이터 공유 쿼리 블록

소비자 클러스터에서 데이터 공유 쿼리를 실행하면 쿼리와 연결된 데이터 블록이 PercentageDiskSpaceUsed 지표에 계산됩니다. 이러한 데이터 블록은 클러스터 재부팅 및 기타 요인으로 인해 PercentageDiskSpaceUsed 지표에서 제거됩니다. 이 예상 동작에 대한 추가 작업은 필요하지 않습니다.

디스크 공간 확인

Amazon Redshift 콘솔의 성능 탭에서 디스크 공간 백분율을 확인하십시오.

관련 정보

Amazon Redshift 성능