Postgres를 OLTP 유형 작업 부하와 함께 사용할 시스템의 백엔드로 조사하기 시작했습니다. 95 % (가능하면> 99 %)의 트랜잭션이 1 행을 4 개의 개별 테이블에 삽입하고, 또는 1 행을 갱신하는 것. 테스트 시스템은 기존의 7200 RPM 디스크를 사용하는 4 코어 i7 프로세서가 포함 된 저렴한 클라우드 호스트 Windows VM에서 9.5.6 (기본 구성 옵션 사용)을 실행 중입니다. 이것은 목표로 삼은 생산 하드웨어보다 훨씬 느리지 만 기본 디자인에서 병목 현상을 찾는 데는 현재 유용합니다.Postgres에 적합한 기본 OLTP 구성은 무엇입니까?
우리의 초기 테스트는 꽤 낙담했습니다. 삽입 명령문 자체는 상당히 빠르게 실행되지만 (조합 된 실행 시간은 약 2ms입니다.) 전체 트랜잭션 시간은 커밋 문이 38ms이므로 약 40ms입니다. 또한 간단한 3 분로드 테스트 (5000 건의 트랜잭션) 중에 초당 약 30 건의 트랜잭션이 발생하며, "확정"(38ms 평균)에 3 분이 걸린 pgbadger가보고되고 그 다음으로 높은 문장은 10 (2ms) 및 3 (0.6ms)마다 삽입합니다. 이 테스트를하는 동안 postgres 인스턴스의 CPU가 100 % 고정됩니다.
커밋에 소요 된 시간이 테스트 경과 시간과 동일하다는 사실은 저에게 커밋이 직렬화되었음을 나타냅니다. 이 시스템에서는 상대적으로 느린 디스크), 그 기간 동안 CPU를 소비하고 있다는 사실에 놀랐습니다. 우리가 I/O 경계에 있다면 우리는 CPU 사용량이 매우 낮지 만 사용률은 높지 않다고 생각할 것입니다.
약간의 독서를하면 비동기식 커밋을 사용하면 많은 문제가 해결되지만 충돌/즉시 종료시 데이터가 손실된다는 경고가 표시됩니다. 마찬가지로 트랜잭션을 단일 시작/완료 블록으로 그룹화하거나 다중 행 삽입 구문을 사용하면 처리량도 향상됩니다.
이러한 모든 옵션을 사용할 수 있지만 기존의 OLTP 응용 프로그램에서는 아무 것도 필요하지 않습니다 (빠른, 원자 적, 동기식 트랜잭션이 필요합니다). 4 코어 박스에서 초당 35 회의 트랜잭션이 20 년 전에는이 테스트 머신보다 훨씬 느린 하드웨어에서 실행되는 다른 RDBM에서 용납 될 수 없었습니다. Postgres는 훨씬 더 높은 작업 부하를 처리합니다.
나는 주위를 둘러 보았지만 Postgres 인스턴스 튜닝을위한 시작점 역할을하는 상식 설정 옵션을 찾을 수 없습니다. 어떤 제안?
나는 그것이 사실이라고 생각했다. 그러나 시간에 상응하는 높은 CPU 사용량이 커밋에 소비 된 이유는 무엇입니까? –
또한 # 1의 경우 어떤 조치를 취해야합니까? –
죄송합니다. 명확하지 않았습니다. # 1이 원하는 동작입니다. 높은 CPU 사용량은 이상합니다. 시간이 어디에서 소비되는지 알아낼 수 있습니까? 아마도 I/O가 완료되기를 기다리고있을 것입니다 (Windows에서 어떻게 구별 할 수 있을지 모르겠다)? –