proxmox를 사용하는 ZFS의 PostgreSQL/TimescaleDB VM에 대한 캐시 구성

proxmox를 사용하는 ZFS의 PostgreSQL/TimescaleDB VM에 대한 캐시 구성

단일 노드로 구성된 proxmox 클러스터가 있고 PostgreSQL 및 TimescaleDB를 사용하여 새 VM을 시작하고 싶습니다. 이 목적을 위해 ZFS 볼륨을 조정하는 방법에 대해 많은 내용을 읽은 후에도 캐시 옵션에 대해 여전히 의문이 있습니다. 캐시는 3개입니다: proxmox 캐시(ARC), linux vm 캐시(LRU), PostgreSQL 캐시(클럭 스윕); 더 먼 곳에서 DB에 더 가까운 곳으로 이동합니다.

나는 많은 정보를 읽었고 그 중 일부는 모순적이어서 이것이 사실인지는 모르지만 PG 캐시는 모든 것을 포착하려고 시도하는 커널 캐시와 같은 방식으로 설계되지 않은 것 같습니다. 캐싱을 계속할 공간이 충분하지 않은 경우에만 제거하십시오. 실제로는 장기 캐시가 아닌 현재 처리 중인 데이터에 대한 버퍼에 더 가까운 것 같습니다. 실제로 이를 공유 버퍼라고 합니다. 그래서 문서에서는 shared_buffers를 ARC처럼 사용 가능한 램의 높은 %로 설정하지 않는 것이 좋지만 25~50% 사이로 설정하는 것이 좋습니다. 실제 PG 캐시는 shared_buffers가 아닌 커널 캐시인 것 같습니다.

이를 고려하여 고려할 수 있는 몇 가지 구성이 있습니다.

  1. 적당한 양의 RAM(12GB라고 가정)을 사용하여 VM을 만들고 shared_buffers를 10GB로 설정합니다. 시도해 보세요: 1) 진행 중인 쿼리에 대한 버퍼 역할을 할 수 있는 충분한 양의 메모리를 확보하십시오. 2) 캐시를 사용하지 않도록 VM RAM을 억제합니다. LRU 구성은 최악의 구성이어야 하며 대신 가중치가 더 높은 ARC를 사용해야 합니다. 이 구성의 문제는 캐시가 VM 외부에 있어 성능을 향상시키기는커녕 오히려 저하시킬 수 있다는 점에서 발생할 수 있습니다. 또한 VM OS 및 기타 DB 프로세스를 실행하기 위해 shared_buffers 크기에 얼마나 많은 공간을 남겨야 하는지 잘 모르겠습니다.
  2. 대용량 RAM(예: 48GB)이 있는 VM을 만들고 shared_buffers를 동일한 10GB로 유지합니다. 또한 zfs는 기본 캐시를 메타데이터로 설정합니다. 이렇게 하면 캐시가 DB와 VM 내부에 더 가까워지지만 논리는 최악입니다. LRU는 DB에 좋지 않은 것 같습니다.
  3. 많은 양의 RAM과 Primarycache=all을 사용하여 VM을 만듭니다. 나는 이것이 나쁜 일이 될 것이라고 생각합니다. 1) VM과 proxmox chaches는 리소스를 놓고 경쟁할 것입니다. 2) 캐시 복제.

일부 컨텍스트를 제공하기 위해 노드에는 총 64GB의 RAM이 있으며 PG/timescaleDB는 여기에서 실행되는 더 까다롭고 우선순위가 높은 애플리케이션이 될 것입니다.

그렇다면 나의 초기 가정이 정확합니까? 어떤 구성이 더 잘 작동할까요? 무엇을 바꾸시겠습니까?

감사합니다. 시간 내주셔서 감사합니다.

헥토르

답변1

내 권장 사항은 솔루션 #4를 사용하는 것입니다. 대용량 RAM을 사용하고 KVM(Proxmox) 측에서 cache=none데이터 디스크를 사용하는 VM을 만듭니다. 이렇게 하면 Proxmox가 호스트 페이지 캐시를 전혀 사용하지 않게 되어 실제 저장소 동기화를 효과적으로 실행하게 됩니다. 이렇게 하면 VM에서 가능한 한 베어메탈에 가까워지고 거기에서 캐시를 미세 조정할 수 있습니다.

내가 아는 모든 데이터베이스(PostgreSQL 포함)에 대해 RAM 버퍼는 단순한 디스크 캐시가 아니라 데이터의 적어도 일부를 온디스크 형식에서 바로 읽을 수 있는 형식으로 유지한다는 점을 알아두세요. 이는 DB 프로세스를 위해 별도로 설정된 RAM이 I/O 버퍼로 사용되는 RAM보다 더 가치가 있음을 의미합니다.

DB가 (자체) RAM의 쿼리에 응답할 수 있으면 IO 스택을 전혀 실행하지 않으므로 대기 시간이 크게 절약됩니다.

관련 정보