연결 프로파일러 소개

postgres 성능을 이해하는 것은 기본적으로 클라이언트와 postgresql의 '백엔드'라는 데이터베이스 측 프로세스 간의 통신에 의존합니다. Postgres 데이터베이스 연결 네트워크 통신을 프로파일링하기 위해 작은 유틸리티를 만들었습니다. connection-profiler

대답해야 할 첫 번째 질문은 pgbench이 있는 동안 연결 프로파일러 도구를 만드는 이유입니다. 이에 대한 대답은 pgbench가 벤치마크를 실행하기 위한 것인데, 이는 개별 요청을 검사하기 위한 것이 아니라 postgres에 대해 SQL을 실행한다는 것을 의미합니다. 따라서 connection-profiler과는 다른 기능을 합니다. 작업에 적합한 도구를 사용하는 것이 중요합니다!

연결 프로파일러는 host=192.168.66.80 port=5433 sslmode=disable user=yugabyte password=yugabyte 와 같은 연결 URL을 사용하여 데이터베이스에 연결하고 선택적으로 SQL 문을 실행할 수 있습니다.

연결 프로토콜(단순, 확장 또는 준비)을 지정할 수 있습니다. 단순 설정은 postgres 단순 쿼리 프로토콜을 사용하고, 확장 설정은 postgres 확장 프로토콜을 사용하고, 준비된 설정은 postgres 확장 프로토콜을 사용하고 준비된 문을 사용합니다.

연결 프로파일러가 기본적으로 수행하는 단일 SQL 실행의 경우 준비된 명령문을 사용하는 것은 의미가 없습니다. 준비된 명령문의 목적은 명령문을 구문 분석된 상태로 유지하여 구문 분석 단계(구문 및 의미론 구문 분석 및 재작성)은 준비된 명령문이 생성(따라서 구문 분석)된 후 건너뛸 수 있습니다. 또한 Postgres 플래너가 일반 계획(기본 "사용자 지정 계획"을 5회 이상 실행해야 함)을 사용하도록 결정할 수 있습니다.

그렇다면 이 옵션을 제공하는 이유는 무엇입니까? 이는 도구의 목적이 연결 내부에서 일어나는 일을 측정하는 것이고 준비된 명령문을 사용하는 것이 고유한 패턴이기 때문입니다.

선택적으로 동일한 연결 내에서 지정된 SQL을 여러 번 실행하거나 연결을 종료하고 다시 연결하여 지정된 SQL을 실행하도록 연결 프로파일러를 구성할 수 있습니다. 이것은 숫자를 취하는 -r/--repeat-sql 스위치와 역시 숫자를 취하는 -n/--repeat-connect 스위치로 이루어집니다.

이것이 영향을 나타낼 수 있는 것 중 하나는 시작 후 데이터베이스에 로그온하는 첫 번째 백엔드에 대한 pg_internal.init 파일의 재생성 및 YugabyteDB에서 RPC를 수행해야 할 수 있는 구문 분석 대기 시간의 영향입니다. 두 시간 모두 pg_stat_statements에 표시되지 않는 호출입니다.

Rust 실행 파일 자체와 그것이 rust-postgres 크레이트를 사용하는 방식에 관심이 있다면(Rust 크레이트에 익숙하지 않은 사람들을 위해: 크레이트는 본질적으로 라이브러리입니다): Cargo를 사용하면 '패치 모드'에서 크레이트를 사용할 수 있습니다. , 즉 크레이트의 소스를 다운로드하고 패치 모드에서 사용하겠다고 말하면서 크레이트Cargo.toml를 가리킵니다.

[patch.crates-io]
postgres-protocol = { path = "rust-postgres/postgres-protocol"}
tokio-postgres = { path = "rust-postgres/tokio-postgres"}

이제 크레이트의 파일을 변경할 수 있으며 Cargo는 변경 사항을 적용하여 실행 파일을 컴파일합니다.

어떤 사람이 상자에서 무슨 일이 일어나고 있는지에 대한 더 많은 통찰력을 제공하는 다른 부분을 발견하면 저에게 연락해 주세요. 그러면 저장소에 추가하겠습니다.