RDS for PostgreSQL 튜닝을 위한 필수 개념 - Amazon Relational Database Service
RDS for PostgreSQL 대기 이벤트RDS for PostgreSQL 메모리RDS for PostgreSQL 프로세스

RDS for PostgreSQL 튜닝을 위한 필수 개념

RDS for PostgreSQL 데이터베이스를 튜닝하기 전에 대기 이벤트가 무엇인지, 왜 발생하는지 확인해 보세요. 또한 RDS for PostgreSQL의 기본 메모리 및 디스크 아키텍처도 검토하세요. 유용한 아키텍처 다이어그램은 PostgreSQL 위키북을 참조하세요.

RDS for PostgreSQL 대기 이벤트

대기 이벤트는 세션이 리소스를 대기 중임을 나타냅니다. 예를 들어 대기 이벤트 Client:ClientRead는 RDS for PostgreSQL이 클라이언트로부터 데이터를 수신하기 위해 대기 중일 때 발생합니다. 세션은 일반적으로 대기하는 리소스는 다음과 같습니다.

  • 버퍼에 대한 단일 스레드 액세스(예: 세션이 버퍼 수정을 시도하는 경우)

  • 현재 다른 세션에 의해 잠겨 있는 행

  • 데이터 파일 읽기

  • 로그 파일 쓰기

예를 들어 쿼리를 충족하기 위해 세션에서 전체 테이블 스캔을 수행할 수 있습니다. 데이터가 아직 메모리에 없는 경우 세션은 디스크 I/O가 완료될 때까지 기다립니다. 버퍼를 메모리로 읽으면 다른 세션이 동일한 버퍼에 액세스하기 때문에 세션을 기다려야 할 수 있습니다. 데이터베이스는 미리 정의된 대기 이벤트를 사용하여 대기를 기록합니다. 이러한 이벤트는 카테고리로 그룹화됩니다.

대기 이벤트 자체는 성능 문제를 나타내지 않습니다. 예를 들어 요청된 데이터가 메모리에 없으면 디스크에서 데이터를 읽어야 합니다. 한 세션이 업데이트를 위해 행을 잠그면 다른 세션은 해당 행의 잠금이 해제될 때까지 기다려 업데이트할 수 있습니다. 커밋을 수행하려면 로그 파일에 대한 쓰기가 완료될 때까지 대기해야 합니다. 대기는 데이터베이스의 정상적인 기능에 필수적입니다.

반면 많은 수의 대기 이벤트는 일반적으로 성능 문제를 나타냅니다. 이러한 경우 대기 이벤트 데이터를 사용하여 세션이 시간을 소비하는 위치를 결정할 수 있습니다. 예를 들어 일반적으로 실행하는 데 몇 분 정도 걸리는 보고서가 몇 시간 동안 실행되는 경우 총 대기 시간에 가장 많이 기여하는 대기 이벤트를 식별할 수 있습니다. 최상위 대기 이벤트의 원인을 확인할 수 있는 경우 성능을 향상시키는 변경 작업을 수행할 수 있습니다. 예를 들어 세션이 다른 세션에 의해 잠긴 행에서 대기 중인 경우 잠금 세션을 종료할 수 있습니다.

RDS for PostgreSQL 메모리

RDS for PostgreSQL 메모리는 공유 메모리와 로컬 메모리로 구분됩니다.

RDS for PostgreSQL의 공유 메모리

RDS for PostgreSQL은 인스턴스가 시작될 때 공유 메모리를 할당합니다. 공유 메모리는 여러 하위 영역으로 나뉩니다. 다음에서 가장 중요한 사항에 대한 설명을 찾을 수 있습니다.

공유 버퍼

공유 버퍼 풀은 애플리케이션 연결에서 사용 중이거나 사용 중인 모든 페이지를 보관하는 RDS for PostgreSQL 메모리 영역입니다. 페이지는 디스크 블록의 메모리 버전입니다. 공유 버퍼 풀은 디스크에서 읽은 데이터 블록을 캐시합니다. 이 풀은 디스크에서 데이터를 다시 읽어야 할 필요성을 줄여 데이터베이스가 더 효율적으로 연산하게 합니다.

모든 테이블과 인덱스는 고정된 크기의 페이지 배열로 저장됩니다. 각 블록에는 행에 해당하는 여러 튜플이 포함되어 있습니다. 튜플은 모든 페이지에 저장할 수 있습니다.

공유 버퍼 풀에는 유한 메모리가 있습니다. 새 요청에 메모리에 없는 페이지가 필요하고 메모리가 더 이상 존재하지 않는 경우 RDS for PostgreSQL은 요청을 수용하기 위해 자주 사용되지 않는 페이지를 삭제합니다. 제거 정책은 클럭 스윕 알고리즘에 의해 구현됩니다.

shared_buffers 파라미터는 서버가 데이터 캐싱에 전념하는 메모리 양을 결정합니다.

미리 쓰기 로그(WAL) 버퍼

미리 쓰기 로그(WAL) 버퍼는 RDS for PostgreSQL이 나중에 영구 스토리지에 쓰는 트랜잭션 데이터를 보유합니다. WAL 메커니즘을 사용하여 RDS for PostgreSQL이 다음을 수행할 수 있습니다.

  • 장애 발생 후 데이터 복구

  • 디스크에 빈번한 쓰기를 방지하여 디스크 I/O 감소

클라이언트가 데이터를 변경하면 RDS for PostgreSQL이 변경 사항을 WAL 버퍼에 기록합니다. 클라이언트가 COMMIT을 발행하면 WAL 라이터 프로세스는 트랜잭션 데이터를 WAL 파일에 씁니다.

wal_level 파라미터는 WAL에 기록되는 정보의 양을 결정합니다.

RDS for PostgreSQL의 로컬 메모리

모든 백엔드 프로세스는 쿼리 처리를 위해 로컬 메모리를 할당합니다.

작업 메모리 영역

작업 메모리 영역은 정렬 및 해시를 수행하는 쿼리에 대한 임시 데이터를 보유합니다. 예를 들어, 다음을 포함하는 쿼리 ORDER BY 절은 정렬을 수행합니다. 쿼리는 해시 조인 및 집계에서 해시 테이블을 사용합니다.

work_mem 파라미터는 임시 디스크 파일에 쓰기 전에 내부 정렬 작업 및 해시 테이블에서 사용할 메모리 양입니다. 기본값은 4MB입니다. 여러 세션을 동시에 실행할 수 있으며 각 세션은 유지 관리 작업을 병렬로 실행할 수 있습니다. 이러한 이유로 사용되는 총 작업 메모리는 work_mem 설정의 배수가 될 수 있습니다.

유지 관리 작업 메모리 영역

유지 관리 작업 메모리 영역은 유지 관리 작업을 위해 데이터를 캐시합니다. 이러한 작업에는 베큠, 인덱스 생성 및 외래 키 추가가 포함됩니다.

maintenance_work_mem 파라미터는 유지 관리 작업에서 사용할 최대 메모리 양을 지정합니다. 기본값은 64MB입니다. 데이터베이스 세션은 한 번에 하나의 유지 관리 작업만 실행할 수 있습니다.

임시 버퍼 영역

임시 버퍼 영역에서는 각 데이터베이스 세션에 대한 임시 테이블을 캐시합니다.

각 세션은 사용자가 지정한 한도까지 필요에 따라 임시 버퍼를 할당합니다. 세션이 끝나면 서버는 버퍼를 지웁니다.

temp_buffers 파라미터는 각 세션에서 사용하는 임시 버퍼의 최대 수를 설정합니다. 세션 내에서 임시 테이블을 처음 사용하기 전에 temp_buffers 값을 변경할 수 있습니다.

RDS for PostgreSQL 프로세스

RDS for PostgreSQL은 여러 프로세스를 사용합니다.

Postmaster 프로세스

Postmaster 프로세스는 RDS for PostgreSQL을 시작할 때 시작되는 첫 번째 프로세스입니다. 포스트마스터 프로세스는 다음과 같은 주요 책임이 있습니다.

  • 백그라운드 프로세스 포크 및 모니터링

  • 클라이언트 프로세스에서 인증 요청을 수신하고 데이터베이스에서 요청을 처리하도록 허용하기 전에 인증 요청을 인증합니다.

백엔드 프로세스

Postmaster가 클라이언트 요청을 인증하면 postmaster는 postgres 프로세스라고도 하는 새 백엔드 프로세스를 생성합니다. 하나의 클라이언트 프로세스가 정확히 하나의 백엔드 프로세스에 연결됩니다. 클라이언트 프로세스와 백엔드 프로세스는 포스트마스터 프로세스의 개입 없이 직접 통신합니다.

백그라운드 프로세스

Postmaster 프로세스는 서로 다른 백엔드 작업을 수행하는 여러 프로세스를 생성합니다. 몇 가지 중요한 사항은 다음과 같습니다.

  • WAL 라이터

    RDS for PostgreSQL 미리 쓰기 로깅(WAL) 버퍼의 데이터를 로그 파일에 씁니다. 미리 쓰기 로깅의 원칙은 데이터베이스가 변경 사항을 설명하는 로그 레코드를 디스크에 기록하기 전까지는 데이터베이스가 데이터 파일에 변경 사항을 쓸 수 없다는 것입니다. WAL 메커니즘은 디스크 I/O를 줄이고, RDS for PostgreSQL 장애 후 로그를 사용하여 데이터베이스를 복구할 수 있도록 합니다.

  • 백그라운드 라이터

    이 프로세스는 메모리 버퍼에서 데이터 파일로 더티(수정된) 페이지를 주기적으로 씁니다. 백엔드 프로세스가 메모리에서 페이지를 수정하면 페이지가 더티(dirty) 상태가 됩니다.

  • Autovacuum 데몬

    데몬은 다음 구성 요소로 이루어져 있습니다.

    • Autovacuum 시작 관리자

    • Autovacuum 작업자 프로세스

    Autovacuum은 삽입되고 업데이트되거나 삭제된 튜플 수가 많은 테이블이 있는지 확인합니다. 데몬에는 다음과 같은 책임이 있습니다.

    • 업데이트되거나 삭제된 행이 차지하는 디스크 공간 복구 또는 재사용

    • 플래너가 사용하는 통계 업데이트

    • 트랜잭션 ID 랩어라운드로 인해 이전 데이터 손실 방지

    Autovacuum 기능은 VACUUM과 ANALYZE 명령을 자동화합니다. VACUUM에는 다음과 같은 표준 및 전체 변형이 있습니다. 스탠다드 베큠은 다른 데이터베이스 연산과 병행하여 실행됩니다. VACUUM FULL에는 작업 중인 테이블에 독점적인 잠금이 필요합니다. 따라서 동일한 테이블에 액세스하는 연산과 병렬로 실행할 수 없습니다. VACUUM은 상당한 양의 I/O 트래픽을 생성하여 다른 활성 세션의 성능이 저하될 수 있습니다.