source

스탠드아론 mariaDB 서버에 비해 galera의 퍼포먼스가 매우 나쁘다

gigabyte 2022. 11. 28. 21:10
반응형

스탠드아론 mariaDB 서버에 비해 galera의 퍼포먼스가 매우 나쁘다

제가 만든 galera 셋업으로 허용할 수 없는 낮은 퍼포먼스를 얻을 수 있습니다.설정에는 액티브-액티브 노드가 2개 있으며 HA 프록시 로드 밸런서를 사용하여 라운드 로빈 방식으로 두 노드에서 읽기/쓰기를 수행합니다.

36 vpcu, 60 GB RAM, SSD, 10 Gig 전용 파이프 구성의 단일 mariadb 서버에서 애플리케이션 상에서 10,000 TPS 이상을 쉽게 얻을 수 있었습니다.

ha-proxy에 의한 2노드(36vcpu, 60GB RAM)의 DB 로드밸런싱을 사용하고 있지만 galera에서는 3500TPS를 거의 얻을 수 없습니다.참고로 ha-proxy는 다른 서버에서 독립 실행형 노드로 호스트됩니다.현재 ha-proxy를 제거했지만 성능 향상은 없습니다.

my.cnf의 튜닝 파라미터를 제안해 주십시오.이러한 퍼포먼스 저하의 설정을 튜닝하는 것을 검토해 주십시오.

다음 my.cnf 파일을 사용하고 있습니다.

여기에 이미지 설명 입력

여기에 이미지 설명 입력

36 vpcu, 60 GB RAM, SSD, 10 Gig 전용 파이프 구성의 단일 mariadb 서버에서 애플리케이션 상에서 10,000 TPS 이상을 쉽게 얻을 수 있었습니다.

ha-proxy에 의한 2노드(36vcpu, 60GB RAM)의 DB 로드밸런싱을 사용하고 있지만 galera에서는 3500TPS를 거의 얻을 수 없습니다.

Galera 기반의 클러스터는 사용자가 의도하는 대로 쓰기 규모를 확장하도록 설계되지 않았습니다.실제로 Rick이 전술한 바와 같이 동일한 테이블에 대해 여러 노드에 쓰기를 전송하면 인증 경합이 발생하여 애플리케이션의 교착 상태가 반영되어 막대한 오버헤드가 발생합니다.

제가 만든 galera 셋업으로 허용할 수 없는 낮은 퍼포먼스를 얻을 수 있습니다.설정에는 액티브-액티브 노드가 2개 있으며 HA 프록시 로드 밸런서를 사용하여 라운드 로빈 방식으로 두 노드에서 읽기/쓰기를 수행합니다.

모든 쓰기를 단일 노드에 전송하여 성능이 향상되는지 확인하십시오.Galera가 사용하는 가상 동기식 복제의 특성상 항상 약간의 오버헤드가 발생합니다.그 때문에, 실제로 실행하는 각 쓰기의 네트워크 오버헤드가 증가합니다(실제 클럭 베이스의 병렬 복제는 이 영향을 꽤 상쇄합니다만, throughput의 양은 약간 낮아집니다).

또, 레플리케이션 인증 프로세스는 싱글 스레드이며, 다른 노드에서의 기입이 정지하기 때문에(라이터 노드에 트랜잭션 wsrep 프리 커밋 스테이지가 표시되어 있는 경우는, 다른 노드가 대규모로 인증을 실시하고 있는 것을 의미하고 있는 경우), 반드시 트랜잭션을 짧게 해 주세요.트랜잭션 또는 노드의 성능 문제(예: 하드웨어, 전체 디스크, 대량 읽기)가 발생하고 있습니다.

이것이 도움이 되기를 바라며, 단일 노드로 이동하면 어떻게 되는지 알려주십시오.

QC를 끕니다.

query_cache_size = 0  -- not 22 bytes
query_cache_type = OFF -- QC is incompatible with Galera

증가하다innodb_io_capacity

두 노드의 간격(ping 시간)은 얼마나 됩니까?

마스터-슬레이브인 척하라고 제안해봐즉, HAProxy가 한쪽 노드에 모든 트래픽을 전송하고 다른 한쪽 노드는 핫백업으로 남깁니다.이 모드에서는 특정 작업이 더 빨리 실행될 수 있습니다. 앱에 대해서는 잘 모르겠습니다.

언급URL : https://stackoverflow.com/questions/41610698/getting-a-very-bad-performance-with-galera-as-compared-to-a-standalone-mariadb-s

반응형