Alexey Kovyazin, 2014년 7월 14일

이전 기사에서 기억하시겠지만, 우리는 Firebird 성능 저하에 대한 신화를 조사했습니다 ( /ko/articles/firebird-performance-degradation-tests-myths-and-truth/ ). 여기서 9Gb에서 30Gb까지의 여러 데이터베이스를 만들었고, 또한 매우 큰 Firebird 데이터베이스(1.7 테라바이트)도 테스트했습니다 (/ko/articles/more-details-about-1-7-terabyte-firebird-sql-database/).

모든 테스트는 동일한 하드웨어에서 수행되었으며, 이는 저예산 구성입니다: CPU AMD-FX8350, RAM 16GB, SATA 소프트웨어 RAID1 2x4Tb HDD Seagate 드라이브, 운영 체제 Windows Server 2008R2 (2008R2는 64비트), 그리고 동일한 Firebird 구성: Firebird 2.5.2 64비트, SuperServer, 증가된 페이지 버퍼와 TempCacheSize를 사용했습니다. 이 SuperServer 구성 파일은 다음 위치에서 무료로 다운로드할 수 있습니다: /ko/optimized-firebird-configuration/

결과적으로, 우리는 데이터베이스 성능에 대한 다음과 같은 그림을 얻었습니다:


그림 1. 9Gb에서 30Gb, 그리고 1.7Tb까지의 성능 저하

포인트 #11은 30Gb 데이터베이스의 성능 지표이고 #12는 1.7 테라바이트 데이터베이스의 성능 지표입니다 - 데이터베이스 크기가 60배(30Gb에서 1813Gb로) 증가했고, 성능 손실은 2.4배(407에서 169포인트로)였습니다.

그렇다면 질문은: 동일한 하드웨어에서 구성 튜닝으로 Firebird 성능을 향상시킬 수 있을까요?

그리고 답은: 그렇습니다!

FirebirdSQL 성능 향상

기억하시겠지만, 이 테스트에서 우리는 집중적인 INSERT와 덜 집중적인 UPDATE를 수행하는 20개의 동시 연결을 실행했습니다.

모든 SELECT는 짧고 잘 정의되어 있으며 효과적인 SQL 실행 계획을 가지므로, 이는 전형적인 OLTP(온라인 트랜잭션 처리) 애플리케이션입니다. 이러한 애플리케이션의 경우 성능에 가장 중요한 것은 병렬 처리입니다. Firebird SuperServer 2.5.2는 다중 스레드 처리에 적합하지 않습니다 - 데이터베이스당 1개의 코어만 효과적으로 사용하며, 이 사실은 SuperServer를 OLTP 애플리케이션에 좋은 선택이 아니게 만듭니다.

따라서, 우리는 다중 스레드 처리를 지원하고 CPU의 여러 코어를 활용하는 Classic 또는 SuperClassic 아키텍처로 Firebird를 변경해야 합니다 (CPU AMD-FX8350에는 8개의 코어가 있습니다).

그런 다음, Firebird의 기본 구성이 우리 테스트 시스템에 최적이 아니므로 약간의 튜닝이 필요합니다.

firebird.conf의 튜닝 매개변수

페이지 캐시

OLTP 성능을 향상시키기 위해 Classic 및 SuperClassic 아키텍처를 시도하기로 결정했습니다. Classic 및 SuperClassic의 핵심 매개변수 중 하나는 캐시의 페이지 버퍼 수입니다. SuperServer와 달리 Classic 및 SuperClassic은 연결별로 페이지 캐시를 할당합니다.

2.5의 Firebird 아키텍처에 대한 자세한 내용은 이 테이블을 검토할 수 있습니다: http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

다른 Firebird 아키텍처의 페이지 캐시 메모리 사용량을 계산하는 쉬운 공식이 있습니다:

1. 1. SuperServer - 데이터베이스당 단일 페이지 캐시. 기본 페이지 캐시 크기는 2048페이지이며, 일반적인 권장 사항은 10000 버퍼입니다. 우리의 경우 캐시는 16k (페이지 크기) x 10000 ~= 160Mb였습니다. 모든 연결에 대한 것입니다.
2. 2. Classic 및 SuperClassic - 엔진은 각 연결에 대해 페이지 캐시를 할당합니다. 기본 크기는 75페이지이므로, 16Kb (페이지 크기) x 75 = ~= 1.17 Mb, 각 연결에 대해.

분명히 페이지 캐시 크기를 늘려야 합니다, 연결당 75페이지는 너무 낮기 때문입니다. 아래에서 페이지 캐시 크기의 여러 다른 값에 대한 결과를 보여드리겠습니다.

LockHashSlots

내부적으로 Firebird 엔진은 데이터베이스 내부 객체에 대한 요청 및 잠금 획득을 위해 잠금 테이블을 사용하며, Classic 및 SuperClassic에는 LockHashSlots 매개변수(기본값 1009)가 있습니다. 높은 부하에서 잠금 테이블의 해시 체인을 줄이기 위해 증가시켜야 합니다. 음, “높은 부하"는 실제 다중 사용자 애플리케이션이라면 모두 해당되는 것 같으므로, 우리는 이를 30011로 설정했습니다 (모든 테스트에서).

LockMemSize

LockMemSize 매개변수는 초기 잠금 테이블 크기를 설정하는 데 사용됩니다 (기본값 1048576). 엔진은 필요에 따라 테이블 크기를 늘릴 수 있습니다. 그러나 잠금 테이블 증가는 메모리 재매핑을 통해 수행되므로 CPU 및 기타 리소스 측면에서 비용이 많이 듭니다. 따라서 시간과 CPU 리소스를 절약하기 위해 7Mb로 설정했습니다.

테스트 실행

다양한 페이지 캐시 값으로 여러 테스트 실행을 수행했으며 결과는 다음과 같습니다:

페이지 버퍼	Classic, 테스트 포인트	SuperClassic, 테스트 포인트
256	299	372
512	371	359
768	362	386
1024	312	387
1500	390	392
2048	285	284

표 1. Classic 및 SuperClassic 테스트 실행

보시다시피, Classic 및 SuperClassic은 이 작업에서 Firebird SuperServer보다 훨씬 효과적입니다: 테스트 결과가 169포인트에서 300-400으로 향상되었으며, 이는 30Gb 데이터베이스에서 얻은 결과에 가깝습니다!

다음 그래픽에서 결과를 보는 것이 더 좋습니다:

그림 2. 1.7 테라바이트 데이터베이스 테스트 결과

최고 성능(Classic 및 SuperClassic 모두)이 연결당 1500페이지에서 발생했음을 알 수 있습니다, 따라서 연결당 페이지 캐시 크기는:

1500x16k ~= 23.4Mb

연결당 2000페이지에서는 성능이 크게 감소했습니다. 약 1500-2000페이지 부근에서 캐싱의 이점이 각 서버 프로세스의 캐시에서 페이지를 동기화하기 위한 프로세스 간 잠금 테이블 상호작용으로 인한 오버헤드보다 낮아지는 것 같습니다. 분명히, 연결 수가 많을수록 이 현상은 더 일찍 발생하므로, Classic/SuperClassic 서버는 일반적으로 256-512페이지와 같은 숫자로 구성됩니다.

또한 768-1000페이지 캐시 부근에서 Classic 성능이 급락하는 현상이 있습니다 - 왜 발생했는지 확실하지 않습니다.

요약

우리의 실험은 Firebird 아키텍처(SuperServer, Classic 또는 SuperClassic)의 올바른 선택과 특정 아키텍처에 대한 몇 가지 중요한 매개변수의 적절한 튜닝으로 Firebird 성능을 향상시킬 수 있음을 확인합니다.

결과적으로, 거대한 1.7 Tb Firebird SQL 데이터베이스는 저사양 하드웨어에서 충분히 좋은 성능으로 작동할 수 있습니다. 이러한 테스트의 실용적인 결과로, 우리는 모든 버전의 Firebird와 모든 아키텍처에 대한 여러 구성 파일을 만들었습니다. 물론 특정 애플리케이션 및/또는 하드웨어에 맞게 튜닝된 것은 아니지만, 매우 적은 부하를 위해 만들어진 기본 구성 파일보다는 낫습니다.

최적화된 Firebird 구성 파일 전체 세트: /ko/optimized-firebird-configuration/

질문이 있으시면 언제든지 문의하세요: [email protected]

다음은?

우리는 실제 부하 시뮬레이션과 많은 수의 연결로 Firebird 2.5와 Firebird 3.0의 성능을 비교하는 포괄적인 테스트를 준비 중입니다. 계속 지켜봐 주세요!