PostgreSQL 성능을 향상시키는 방법 중 하나로 합성

철학적 소개

아시다시피 문제를 해결하는 방법은 두 가지뿐입니다.

1. 분석 방법이나 추론 방법, 또는 일반적인 방법에서 구체적인 방법으로.
2. 합성 방법이나 유도 방법, 또는 특정 방법에서 일반 방법으로.

"데이터베이스 성능 향상" 문제를 해결하려면 다음과 같이 보일 수 있습니다.

분석 — 우리는 문제를 별도의 부분으로 분석하고 이를 해결함으로써 데이터베이스의 성능을 전체적으로 향상시키려고 노력합니다.

실제로 분석은 다음과 같습니다.

• 문제가 발생했습니다(성능 사고)
• 데이터베이스 상태에 대한 통계 정보 수집
• 병목 현상 찾기
• 우리는 병목 현상으로 인한 문제를 해결합니다

데이터베이스 병목 현상 — 인프라(CPU, 메모리, 디스크, 네트워크, OS), 설정(postgresql.conf), 쿼리:

하부 구조: 엔지니어에게 영향력과 변화의 기회는 거의 제로에 가깝습니다.

데이터베이스 설정: 변경 가능성은 이전 사례보다 약간 더 크지만 일반적으로 특히 클라우드에서는 여전히 매우 어렵습니다.

요청 데이터베이스에: 움직일 수 있는 유일한 공간.

합성 — 결과적으로 데이터베이스 성능이 향상될 것으로 기대하면서 개별 부분의 성능을 향상시킵니다.

서정적 소개 또는 이 모든 것이 필요한 이유

데이터베이스 성능이 모니터링되지 않는 경우 성능 사고를 해결하는 프로세스는 무엇입니까?

고객 - "모든 것이 좋지 않습니다. 시간이 너무 오래 걸립니다. 우리를 위해 좋은 일을 해주세요."
엔지니어 - "얼마나 안 좋은데요?"
고객 – “지금이 그래요(한 시간 전, 어제, 저번에), 천천히”
엔지니어 - "언제 좋았나요?"
고객님 – “일주일(2주) 전에는 나쁘지 않았어요. “(다행이다)
고객 - “언제는 좋았는지 기억이 안 나지만 지금은 별로예요” (평소 답변)

결과는 고전적인 그림입니다.

누가 책임을지고 무엇을해야합니까?

질문의 첫 번째 부분은 대답하기 가장 쉬운 부분입니다. 항상 책임은 DBA 엔지니어에게 있습니다.

두 번째 부분 역시 답변하기 어렵지 않습니다. 데이터베이스 성능 모니터링 시스템을 구현해야 합니다.

첫 번째 질문이 발생합니다 - 무엇을 모니터링해야 합니까?

경로 1. 모든 것을 모니터링합니다.

CPU 로드, 디스크 읽기/쓰기 작업 수, 할당된 메모리 크기 및 어느 정도 작동 중인 모니터링 시스템이 제공할 수 있는 또 다른 메가톤의 다양한 카운터.

그 결과 수많은 그래프, 피벗 테이블, 지속적인 이메일 알림이 생성되고 100% 바쁜 엔지니어가 동일한 티켓 묶음을 해결하지만 일반적으로 "일시적인 문제"라는 표준 문구를 사용합니다. 조치가 필요하지 않습니다.” 그러나 모두가 바쁘고 항상 고객에게 보여줄 것이 있습니다. 작업이 본격화되고 있습니다.

Way 2. 필요한 것만 모니터링하고, 필요하지 않은 것은 모니터링할 필요가 없습니다.

조금 다르게 엔터티와 이벤트만 모니터링할 수 있습니다.

• 영향을 미칠 수 있는 DBA 엔지니어
• 이벤트가 발생하거나 엔터티가 변경될 때 동작 알고리즘이 있습니다.

이 가정을 바탕으로 "철학적 소개"규칙적인 반복을 피하기 위해"서정적 소개 또는 이 모든 것이 필요한 이유“최적화와 분석을 위해 개별 쿼리의 성능을 모니터링하는 것이 바람직하며, 이는 궁극적으로 전체 데이터베이스의 성능 향상으로 이어집니다.

하지만 전체 데이터베이스 성능에 영향을 미치는 무거운 쿼리를 개선하려면 먼저 이를 찾아야 합니다.

따라서 두 가지 상호 관련된 질문이 발생합니다.

• 어려운 요청으로 간주되는 요청
• 어려운 검색어를 검색하는 방법.

분명히 무거운 쿼리는 결과를 얻기 위해 많은 OS 리소스를 사용하는 쿼리입니다.

두 번째 질문인 무거운 쿼리를 검색하고 모니터링하는 방법으로 넘어가겠습니다.

PostgreSQL에는 어떤 쿼리 모니터링 기능이 있습니까?

Oracle에 비해 가능성은 거의 없지만 여전히 뭔가를 할 수 있습니다.

PG_STAT_STATEMENTS

표준 확장 pg_stat_statements는 PostgreSQL에서 과도한 쿼리를 검색하고 모니터링하도록 설계되었습니다.

확장 기능을 설치하면 동일한 이름의 보기가 대상 데이터베이스에 나타나며 모니터링 목적으로 사용해야 합니다.

모니터링 시스템 구축을 위한 대상 pg_stat_statements 열:

• 쿼리ID 연산자의 구문 분석 트리에서 계산된 내부 해시 코드
• 최대 시간 명령문에 소요된 최대 시간(밀리초)

이 두 컬럼에 대한 통계를 축적하고 활용함으로써 모니터링 시스템을 구축할 수 있습니다.

pg_stat_statements를 사용하여 PostgreSQL 성능을 모니터링하는 방법

쿼리 성능을 모니터링하려면 다음을 사용하세요.
대상 데이터베이스 측 - pg_stat_statements 보기
옆에서 서버 그리고 모니터링 데이터베이스 - 일련의 bash 스크립트와 서비스 테이블입니다.

1단계 - 통계 데이터 수집

cron 모니터링 호스트에서는 대상 데이터베이스의 pg_stat_statements 보기 내용을 모니터링 데이터베이스의 pg_stat_history 테이블로 복사하는 스크립트가 정기적으로 실행됩니다.

이렇게 하면 성능 보고서를 생성하고 지표를 구성하는 데 사용할 수 있는 개별 쿼리 실행 기록이 생성됩니다.

2단계 - 성과 지표 설정

수집된 데이터를 기반으로 클라이언트(애플리케이션)에 실행이 가장 중요/중요한 쿼리를 선택합니다. 고객과 합의하여 queryid 및 max_time 필드를 사용하여 성능 지표 값을 설정했습니다.

결과 - 성능 모니터링 시작

1. 모니터링 스크립트가 실행되면 메트릭의 max_time 값을 대상 데이터베이스의 pg_stat_statements 뷰 값과 비교하여 구성된 성능 메트릭을 확인합니다.
2. 대상 데이터베이스의 값이 메트릭 값을 초과하면 경고가 생성됩니다(티켓 시스템의 사고).

추가 옵션 1

쿼리 계획 기록

후속 성능 사고 해결을 위해서는 쿼리 실행 계획 변경 내역을 보유하는 것이 매우 좋습니다.

log_query 서비스 테이블은 기록을 저장하는 데 사용됩니다. 로드된 PostgreSQL 로그 파일을 분석할 때 테이블이 채워집니다. 로그 파일에는 pg_stat_statements 뷰와 달리 정규화된 텍스트가 아닌 실행 매개변수 값이 포함된 전체 텍스트가 포함되어 있으므로 요청 시간 및 기간뿐만 아니라 현재 실행 계획도 저장할 수 있습니다. 시간.

추가 옵션 2

지속적인 성능 개선 프로세스

일반적인 개별 쿼리 모니터링은 개별 쿼리에 대해서만 성능 문제를 모니터링하고 해결하기 때문에 데이터베이스 전체의 지속적인 성능 개선 문제를 해결하기 위한 것이 아닙니다. 그러나 방법을 확장하고 모든 데이터베이스에 대한 모니터링 쿼리를 구성할 수 있습니다.

이렇게 하려면 추가 성능 지표를 입력해야 합니다.

• 최근에
• 기준기간 동안

스크립트는 대상 데이터베이스의 pg_stat_statements 보기에서 쿼리를 선택하고 max_time 값을 평균 max_time 값과 비교합니다. 첫 번째 경우는 마지막 날에 대해, 두 번째 경우에는 선택한 기간(기준)에 대해 비교합니다.

따라서 요청에 대한 성능 저하가 발생하는 경우 보고서를 수동으로 분석하지 않고도 자동으로 경고가 생성됩니다.

합성이 그것과 무슨 관련이 있습니까?

설명된 접근 방식에서는 합성 방법에서 알 수 있듯이 시스템의 개별 부분을 개선하여 시스템 전체를 개선합니다.

• 데이터베이스에 의해 실행되는 쿼리 - 추상
• 수정된 요청 - 대조
• 시스템 상태 변경 - 합성

시스템 개발

• pg_stat_activity 시스템 보기에 대한 기록을 추가하여 수집된 통계 확장
• 쿼리에 참여한 개별 테이블의 통계에 대한 이력을 추가하여 수집 통계 확장
• AWS 클라우드 모니터링 시스템과 통합
• 그럼에도 불구하고 뭔가 생각해 낼 수 있습니다 ...

출처 : habr.com