LWLock:BufferIO(IPC:BufferIO) - Amazon Relational Database Service
관련 엔진 버전컨텍스트원인작업

LWLock:BufferIO(IPC:BufferIO)

LWLock:BufferIO 이벤트는 RDS for PostgreSQL이 페이지에 동시에 액세스하려고 하는 다른 프로세스들이 입출력 (I/O) 작업을 완료할 때까지 기다리는 경우에 발생합니다. 그 목적은 동일한 페이지를 공유 버퍼로 읽는 것입니다.

관련 엔진 버전

이 대기 이벤트 정보는 모든 RDS for PostgreSQL 버전과 관련이 있습니다. RDS for PostgreSQL 12 이하 버전의 경우 이 대기 이벤트의 이름이 lwlock:buffer_io인 반면, RDS for PostgreSQL 13 버전에서는 lwlock:bufferio로 이름이 지정됩니다. RDS for PostgreSQL 14 버전부터는 BufferIO 대기 이벤트가 LWLock에서 IPC 대기 이벤트 유형(IPC:BufferIO)으로 변경되었습니다.

컨텍스트

각 공유 버퍼에는 매번 블록(또는 페이지)이 공유 버퍼 풀 외부에서 회수되야 하는 LWLock:BufferIO 대기 이벤트와 연결된 I/O 잠금이 있습니다.

이 잠금은 모두 동일한 블록에 액세스해야 하는 여러 세션을 처리하는 데 사용됩니다. 이 블록은 shared_buffers 파라미터로 정의된 공유 버퍼 풀 외부에서 읽어야 합니다.

공유 버퍼 풀 내에서 페이지를 읽는 즉시 LWLock:BufferIO 잠금은 해제됩니다.

참고

LWLock:BufferIO 대기 이벤트는 IO:DataFileRead 대기 이벤트에 선행됩니다. IO:DataFileRead 대기 이벤트는 스토리지에서 데이터를 읽는 동안 발생합니다.

경량 잠금에 대한 자세한 내용은 잠금 개요를 참조하세요.

원인

상위 대기에서 나타나는 LWLock:BufferIO 이벤트의 일반적인 원인은 다음을 포함합니다.

  • I/O 작업이 보류 중인 동일한 페이지에 액세스하려고 시도하는 여러 백엔드 또는 연결

  • 공유 버퍼 풀의 크기 간의 비율(shared_buffers 파라미터로 정의됨) 및 현재 워크로드에 필요한 버퍼 수

  • 공유 버퍼 풀의 크기가 다른 작업에서 제거되는 페이지 수와 균형이 맞지 않습니다.

  • 엔진이 공유 버퍼 풀에 필요한 것보다 많은 페이지를 읽어야 하는 크거나 부풀린 인덱스

  • DB 엔진이 테이블에서 필요한 것보다 더 많은 페이지를 읽도록 하는 인덱스의 부족

  • 체크포인트가 너무 자주 발생하거나 수정된 페이지를 너무 많이 플러시해야 함

  • 같은 페이지에서 작업을 수행하려고 시도하는 데이터베이스 연결의 갑작스러운 급증

작업

대기 이벤트의 원인에 따라 다른 작업을 권장합니다.

  • BufferCacheHitRatio 및 LWLock:BufferIO 대기 이벤트의 급격한 감소 간의 상관관계에 대한 Amazon CloudWatch 지표가 관찰됩니다. 이 효과는 공유 버퍼 설정이 작음을 의미할 수 있습니다. DB 인스턴스 클래스를 늘리거나 확장해야 할 수 있습니다. 워크로드를 더 많은 리더 노드로 분할할 수 있습니다.

  • LWLock:BufferIO가 BufferCacheHitRatio 지표 강하와 동시에 발생한다면 워크로드 피크 시간을 기준으로 max_wal_size와 checkpoint_timeout을 튜닝하세요. 그런 다음 어떤 쿼리가 발생하는지 식별합니다.

  • 사용되지 않는 인덱스가 있는지 확인한 다음 제거합니다.

  • 분할된 테이블(분할된 인덱스도 있음)을 사용합니다. 이렇게 하면 인덱스 재정렬을 낮게 유지하고 영향을 줄일 수 있습니다.

  • 불필요하게 열을 인덱싱하지 마세요.

  • 연결 풀을 사용하여 갑작스러운 데이터베이스 연결 스파이크를 방지합니다.

  • 데이터베이스에 대한 최대 연결 수를 모범 사례로 제한합니다.