Firebird 하드웨어 가이드

_by Alexey Kovyazin, 최종 업데이트: 2015년 11월 30일

Firebird 기술 지원 그룹에서 다음과 같은 질문을 자주 볼 수 있습니다: “Firebird DBMS에 적합한 하드웨어는 무엇인가요?”. 이 주제는 하드웨어 요구 사항이 작업에 따라 다르고 하드웨어 자체도 시간이 지남에 따라 변하기 때문에 항상 인기가 있습니다.

우리는 Firebird 데이터베이스를 위해 진정으로 효과적인 하드웨어를 선택하려는 모든 사람에게 필요한 지식을 제공하기 위해 이 가이드를 작성하기로 결정했습니다. 이를 위해서는 Firebird, 운영 체제, 그리고 물론 하드웨어가 어떻게 작동하는지에 대한 몇 가지 기본적인 세부 사항을 배워야 합니다.

약간의 이론

Firebird 데이터베이스에 어떤 하드웨어가 적합한지 알아내려면 Firebird가 CPU, RAM, HDD/SSD와 같은 구성 요소를 어떻게 사용하는지, 그리고 이러한 구성 요소가 운영 체제(예: 파일 캐시)와 어떻게 상호 작용하는지 이해해야 합니다.

Firebird 서버 기능 모듈

먼저 그림 1을 통해 Firebird 기능 모듈을 살펴보겠습니다:

그림 1. Firebird 모듈

Firebird에는 다음과 같은 주요 기능 모듈이 포함됩니다:

메타데이터 객체: 뷰, 테이블, 인덱스, 트리거, 저장 프로시저 및 기타 데이터베이스 객체. 메타데이터 객체는 Firebird 프로세스(fbserver, fb_inet_server 또는 firebird.exe일 수 있음)의 주소 공간에 위치합니다.
페이지 버퍼 캐시에는 디스크에서 읽은 데이터베이스 페이지가 포함되며 서버 프로세스의 주소 공간에 위치합니다. 페이지 캐싱 메커니즘은 상당히 복잡하므로 Firebird가 가장 자주 사용되는 데이터베이스 페이지를 캐시한다는 것만 언급하겠습니다.
Firebird는 모든 동시 정렬 작업에 사용되는 메모리 양이 TempCacheLimit 매개변수(firebird.conf)로 설정된 한도에 도달할 때까지 메모리(서버 프로세스의 주소 공간)에서 레코드를 정렬합니다. 이 한도를 초과하면 임시 파일(해당 운영 체제 플래포함)이 임시 파일 폴더에 생성되어 정렬에 사용됩니다. 시스템에 여유 RAM이 있으면 정렬 파일이 운영 체제에 의해 캐시되고 정렬이 메모리에서 수행됩니다.
전역 임시 테이블(GTT)은 운영 체제에 임시 파일로 생성됩니다. 운영 체제에 여유 메모리가 있으면 GTT 작업이 RAM에서 수행됩니다.

하드웨어와의 기본 작업

데이터베이스 작업 중에 Firebird 기능 모듈이 하드웨어 구성 요소와 어떻게 상호 작용하는지 살펴보겠습니다.

Firebird가 시작되면 서버 프로세스는 최소한의 RAM(수 메가바이트)을 점유하고 CPU 또는 RAM에 대한 집중적인 작업을 수행하지 않습니다.

데이터베이스에 연결이 설정되면 서버는 메타데이터 읽기를 시작하고 메모리에 해당 객체를 생성하며, 그 결과 더 많은 테이블, 인덱스, 트리거 및 기타 메타데이터가 사용될수록 프로세스가 더 많은 리소스를 차지하게 됩니다. 메모리 사용량은 증가하지만 이 단계에서는 CPU가 거의 사용되지 않습니다.

클라이언트가 SQL 쿼리(저장 프로시저 포함)를 실행하기 시작하면 서버는 하드웨어를 사용하여 해당 작업을 수행합니다. 하드웨어와의 상호 작용을 포함하는 다음과 같은 기본 작업을 구분할 수 있습니다:

하드 드라이브에서 데이터베이스 페이지 읽기,
하드 드라이브에 데이터베이스 페이지 쓰기,
캐시에서 데이터베이스 페이지 읽기,
캐시에 데이터베이스 페이지 쓰기,
전역 임시 테이블에서 데이터 읽기 및 쓰기,
SQL 쿼리 처리(예: JOIN),
결과 집합의 레코드 정렬.

이러한 각 작업에는 일정량의 시스템 리소스가 필요합니다. 아래 표는 리소스 소비를 강도 단위(1은 가장 낮음, 10은 가장 높음)로 보여줍니다:


	디스크에서 페이지 읽기	디스크에 페이지 쓰기	페이지 버퍼 캐시에서 페이지 읽기	페이지 버퍼 캐시에 페이지 쓰기	GTT에서 읽기	GTT에 쓰기	레코드 정렬	SQL 쿼리 처리
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
디스크 I/O	10	10	1	1	1	1	1	1

보시다시피 가장 리소스를 많이 소비하는 작업은 디스크에 대한 액세스와 관련된 작업입니다. 최근 SSD와 관련된 발전에도 불구하고 디스크는 여전히 가장 느린 하드웨어 구성 요소이기 때문입니다.

이것은 전적으로 하드웨어와 관련된 성능 최적화 방법 중 하나로 이어집니다 - 모든 읽기-쓰기 작업을 RAM으로 가져가는 것입니다. 그러나 페이지 캐시 증가 접근 방식은 작동하지 않는다는 점에 유의하십시오. 이 문제는 RAM 섹션에서 자세히 다루겠습니다.

동시에 수행되는 작업

일반적으로 많은 클라이언트를 서비스할 서버를 위한 하드웨어를 선택해야 하므로 작업의 병렬 처리 구현 방식을 이해하는 것이 정말 중요합니다.

하드웨어 구성 요소의 관점에서 CPU, 디스크 및 RAM의 병렬 사용에 대해 이야기할 수 있습니다. 최신 CPU에는 병렬로 명령어 집합을 실행할 수 있는 여러 코어가 있으므로 DBMS 서버는 작업을 코어 간에 분산합니다. 즉, CPU에 코어가 많을수록 더 많은 클라이언트가 이 서버에서 작업할 수 있다는 결론이 나옵니다.

디스크의 관점에서는 그렇게 간단하지 않습니다. 기존 하드 디스크 드라이브(HDD)가 정보를 읽을 때 유한한 속도로 자기 재료 위에서 헤드를 물리적으로 이동합니다. 데이터베이스는 3테라바이트 크기로 상당히 클 수 있으며, 클라이언트의 SQL 쿼리가 디스크의 서로 다른 영역에 있는 데이터에 병렬로 액세스하면 디스크 헤드가 디스크의 서로 다른 영역 사이를 점프하여 읽기 및 쓰기 작업을 심각하게 느리게 만듭니다. 이로 인해 디스크 대기열이 상당히 증가하고 나머지 리소스(CPU, RAM)는 유휴 상태가 됩니다. 물론 디스크 캐시(HDD 또는 RAID 컨트롤러의 캐시)가 이 속도 저하를 어느 정도 보완하지만 충분하지 않습니다.

기존 HDD와 달리 솔리드 스테이트 드라이브(SSD)는 데이터에 대한 병렬 액세스 시 성능 저하가 훨씬 적습니다. SSD의 장점은 특히 데이터를 병렬로 쓸 때 분명합니다 - 우리 테스트에 따르면 SSD는 SATA 디스크보다 7배 빠릅니다(링크!). 그러나 SSD에는 속도 저하, 조기 고장 및 데이터 손실을 방지하기 위해 사용 중에 고려해야 할 몇 가지 문제가 있습니다(디스크 선택 참조).

RAM 작업은 최신 컴퓨터에서 매우 빠르게 수행되며 실질적으로 데이터 버스 대역폭에 의해서만 제한되므로 많은 병렬 SQL 쿼리가 있어도 이러한 작업이 병목 현상으로 작용하지 않습니다.

데이터 흐름

SQL 쿼리를 실행하는 동안 Firebird는 많은 데이터를 읽고 쓰며, 기능 모듈과 해당 하드웨어 구성 요소 간에 데이터를 전송합니다. 가능한 병목 현상을 식별하려면 데이터 교환이 어떻게 수행되는지 이해해야 합니다. 아래 그림 2가 도움이 될 것입니다:

그림 2. RAM과 영구 저장소 간의 데이터 흐름

분명히 영구 저장소에서 RAM으로 또는 그 반대로 데이터를 전송하는 것이 가장 시간이 많이 걸리는 작업입니다. 이는 두 가지 데이터 흐름을 생성합니다: 데이터베이스 파일에서 데이터 페이지 읽기/쓰기와 정렬 파일 읽기/쓰기입니다. 정렬 파일이 여러 개 있을 수 있고 상당히 클 수 있으므로 디스크에 상당한 부하를 줄 수 있으므로 이러한 입력/출력 흐름을 서로 다른 디스크로 보내는 것이 좋습니다.

백업

Firebird는 gbak 유틸리티를 사용한 검증된 백업과 nbackup 유틸리티를 사용한 검증되지 않은 증분 백업의 두 가지 백업 방법을 제공합니다.

이러한 백업 방법을 결합할 것을 권장합니다: nbackup을 자주 실행하고(예: 매시간, 매일, 매주) gbak을 사용하여 매일 밤 검증된 백업 복사본을 만드십시오.

어떤 백업 방법을 사용하든 데이터베이스 파일(전체 또는 일부)이 읽히고 백업 복사본(전체 또는 증분)이 기록됩니다. 쓰기 작업은 백업 프로세스 중에 순차적으로 수행되므로 SATA 인터페이스(HDD SATA)가 있는 일반적인 저렴한 하드 드라이브가 순차 쓰기가 상당히 빠르기 때문에 백업에 적합합니다.

적합한 하드웨어 선택

이제 Firebird가 하드웨어와 어떻게 상호작용하는지 알았으니, 각 특정 구성 요소와 그 사양의 선택에 영향을 미치는 요소들에 대해 자세히 살펴보아야 합니다.

때로는 특정 데이터베이스의 실제 통계가 하드웨어 구성 요소 선택에 큰 영향을 미치므로, IBSurgeon의 Firebird 전문 배포 패키지인 HQbird의 도구를 사용하여 이러한 통계를 얻을 것입니다. HQbird의 평가판은 http://hqbird.com/en/hqbird/에서 다운로드할 수 있습니다.

CPU

CPU를 선택할 때 다음 세 가지를 고려해야 합니다:

애플리케이션에서 어떤 쿼리가 주로 실행되는지,
평균 및 최대 부하 시 데이터베이스에 대한 활성 연결 수,
Firebird 버전 및 아키텍처.

애플리케이션에서 어떤 쿼리가 주로 실행되는가?

Firebird는 항상 하나의 쿼리를 하나의 코어에서 실행하므로, 복잡하고 최적화가 잘 되지 않은 쿼리는 하나의 코어를 최대 100%까지 사용하여 다른 쿼리들을 부하가 적은 코어로 밀어낼 수 있습니다. 코어가 많을수록 전체 CPU가 사용되고 사용자가 애플리케이션에서 성능 저하를 인지할 가능성이 낮아집니다.

애플리케이션이 주로 간단한 짧은 SQL 쿼리를 실행하고, 모든 쿼리가 잘 최적화되어 있으며 (예: 보고서용) 임시 쿼리가 생성되지 않는 경우, CPU는 성능에 병목 현상을 일으키지 않으므로 코어 수가 적은 저사양 CPU를 선택할 수 있습니다.

애플리케이션에 보고서 생성기가 포함되어 있거나 많은 양의 데이터를 반환하는 느린 쿼리가 많은 경우, 더 많은 코어를 가진 CPU가 필요합니다.

평균 및 최대 부하 시 데이터베이스에 대한 활성 연결 수

연결 수(활성 사용자)도 CPU 선택에 영향을 줍니다. 불행히도 애플리케이션 개발자조차도 특정 시점에 얼마나 많은 연결, 쿼리 및 트랜잭션이 활성화되어 있는지 정확히 알지 못합니다. 이에 대한 더 정확한 정보를 얻으려면 HQbird의 MON$ Logger 도구를 사용하고 실행 중에 몇 개의 스냅샷을 찍어 실제로 얼마나 많은 연결이 설정되어 있는지 확인하는 것이 좋습니다.

그림 3. MON$ Logger: 연결 수

예를 들어, 여기에서 연결 수가 296개임을 확인할 수 있습니다. 분명히 이 경우 쿼드 코어 CPU를 사용하는 것은 너무 낙관적이며, 24코어 솔루션이 적절할 것입니다. 실행 중인 SQL 쿼리 없이 유휴 상태일 수 있으므로 동시에 실행되는 쿼리 수도 계산하는 것이 좋습니다.

코어 1개당 10~30개의 연결 비율을 사용하여 CPU에 필요한 코어 수를 대략적으로 추정할 수 있습니다. 대부분 복잡하고 느린 쿼리가 있는 애플리케이션의 경우 코어당 10개 연결, 대부분 간단하고 잘 최적화된 쿼리가 있는 애플리케이션의 경우 코어당 30개 연결입니다.

Firebird 버전 및 아키텍처

Firebird 버전 2.5를 사용하는 경우, 여러 코어에 처리를 분산하려면 Classic 또는 SuperClassic 아키텍처를 사용해야 합니다. 버전 2.5에서 SuperServer 아키텍처는 하나의 데이터베이스에 대해 하나의 코어만 사용할 수 있으므로 많은 리소스를 소비하는 시스템에서는 사용하지 않아야 합니다.

Firebird 버전 3.0에서 SuperServer, Classic 및 SuperClassic은 멀티 코어 CPU의 기능을 사용합니다. Firebird 3.0 SuperServer가 최상의 성능을 보여줍니다.

RAM

RAM을 선택할 때 두 가지에 주의해야 합니다:

메모리 모듈에 오류 수정 코드(ECC RAM)가 있어야 합니다.
RAM 용량이 올바르게 계산되어야 합니다.

ECC RAM

ECC RAM은 메모리 작업 중 발생하는 오류 수를 상당히 줄여주며, 산업용 시스템에서 사용하는 것이 강력히 권장됩니다.

필요한 RAM 용량 계산

메모리 용량을 계산하려면 다양한 Firebird 아키텍처의 특성을 살펴봐야 합니다. Firebird 2.5 Classic 및 Firebird 3.0 Classic은 각 연결을 처리하기 위해 별도의 프로세스를 실행하고, SuperClassic은 각 연결에 대해 별도의 스레드를 실행하지만 실질적으로 동일한 메모리 소비 구조를 가집니다 - 각 연결에는 자체 독립적인 페이지 캐시가 있습니다.

Firebird SuperServer는 모든 연결에 대해 하나의 페이지 캐시를 가진 하나의 프로세스를 실행합니다.

따라서 다음 매개변수가 전체 메모리 소비에 영향을 미칩니다:

연결 수
데이터베이스 페이지 크기
메타데이터 크기(테이블, 트리거, 저장 프로시저 등의 수에 비례; 조정 불가; 실제 사용에 의해 결정됨)
Classic 및 SuperClassic의 경우 - 연결당
SuperServer의 경우 - 열린 데이터베이스 인스턴스당
페이지 캐시 크기(데이터베이스 헤더 또는 firebird.conf 또는 특정 연결의 속성에 있는 매개변수에 의해 결정됨)
Classic 및 SuperClassic의 경우 - 연결당
SuperServer의 경우 - 열린 데이터베이스 인스턴스당
정렬 캐시 크기(firebird.conf의 매개변수에 의해 결정됨). 정렬을 위한 메모리는 한 번에 할당되는 것이 아니라 필요에 따라 할당됩니다.
Classic의 경우 - 연결당
SuperServer 및 SuperClassic의 경우 - 프로세스당(즉, 하나의 정렬 캐시)
Classic/SuperClassic의 경우 - 잠금 테이블 크기(일반적으로 작으므로 계산에서 제외합니다).

IBSurgeon 회사는 몇 가지 테스트를 수행하여 Firebird 페이지 캐시의 페이지 수에 대한 최적 값 집합을 얻었습니다:

Classic/SuperClassic - 256~2000페이지
SuperServer 2.5 - 10000페이지
SuperServer 3.0 - 100000페이지

이 테스트를 기반으로 4-6GB 메모리를 가진 서버용 최적화된 Firebird 구성 파일을 만들었습니다. 여기에서 다운로드할 수 있습니다: /ko/optimized-firebird-configuration/

필요한 RAM 용량 계산 공식

아래에서 Firebird에 필요한 대략적인 메모리 양을 추정하는 데 사용되는 공식을 확인할 수 있습니다. 이 추정치는 메타데이터, 인덱스의 비트 마스크 등에 필요한 메모리 양을 고려하지 않아 메모리 소비가 증가할 수 있으므로 실제 메모리 소비는 다를 수 있습니다. 그러나 모든 연결에서 정렬 메모리가 최대한 사용된다고 가정하는데, 이는 일반적으로 사실이 아닙니다.

데이터베이스가 이미 사용 중인 경우, (작업 관리자 또는 ProcessExplorer를 통해) Firebird 프로세스가 사용하는 평균 메모리 양을 확인할 수 있습니다.

Classic에 대한 추정:

연결 수 * ( (캐시의 페이지 수 * 페이지 크기) + 정렬 캐시 크기 )

Classic 예시: 100명의 활성 사용자를 예상하고, 데이터베이스 페이지 크기가 8KB로 설정되어 있으며 페이지 캐시의 페이지 수가 256으로 설정되어 있고, 정렬 캐시 크기가 8MB(Classic 및 SuperClassic의 기본값)에서 64MB로 증가된 경우:

((256.8 KB)+64) = 6600 MB

SuperClassic에 대한 추정:

연결 수 * (캐시의 페이지 수 * 페이지 크기) + 정렬 캐시 크기

SuperClassic 예시: 100명의 사용자, 데이터베이스 페이지 크기 8KB, 페이지 캐시의 페이지 수 256, 정렬 캐시 크기 1024MB:

100.(256.8 KB) + 1024 MB = 2024 MB

SuperServer에 대한 추정:

(캐시의 페이지 수 * 페이지 크기) + 정렬 캐시 크기

SuperServer(Firebird 2.5) 예시: 1개의 데이터베이스, 100명의 사용자, 데이터베이스 페이지 크기 8KB, 페이지 캐시의 페이지 수 10000, 정렬 캐시 크기 1024MB:

(10000.8 KB) + 1024 = 1102 MB

SuperServer(Firebird 3.0) 예시: 1개의 데이터베이스, 100명의 사용자, 데이터베이스 페이지 크기 8KB, 페이지 캐시의 페이지 수 100000, 정렬 캐시 크기 1024MB:

(100000.8 KB) + 1024 = 1805 MB

“과도한 메모리”

Firebird는 비효율적인 메모리 사용으로 종종 비난받습니다 - 서버의 실행 중인 프로세스가 소량의 RAM만 소비하고 나머지 메모리는 사용되지 않은 채 남아 있다고 주장합니다.

실제로는 그렇지 않습니다. 이러한 결론은 기본적으로 Firebird 캐싱 메커니즘이 어떻게 작동하는지에 대한 이해 부족과 운영 체제 모니터링 도구의 불완전성에 기인합니다.

우선, Firebird가 운영 체제의 파일 캐시를 광범위하게 사용한다는 점을 분명히 이해해야 합니다. 페이지가 Firebird 페이지 캐시에 로드될 때, 그것은 운영 체제 파일 캐시를 통과합니다. Firebird가 페이지 캐시에서 페이지를 내릴 때, 운영 체제는 충분한 여유 메모리가 있다면 데이터베이스의 해당 청크를 RAM에 계속 보관합니다.

그림 4. 캐시 수준: Firebird, OS 및 저장소

그러나 단순히 보기만 하면, 운영 체제는 파일 캐시에 할당된 메모리를 사용 중으로 표시하지 않습니다. 예를 들어, Firebird 서버가 실행 중일 때 작업 관리자에 표시되는 일반적인 메모리 분포 상황은 다음과 같습니다:

그림 5. 작업 관리자는 파일 캐시 사용량을 표시하지 않음

16GB 중 6.3GB만 사용된 것처럼 보입니다.

그러나 RAMMap 도구(Microsoft의 SysInternals 제공)를 사용하면 모든 것이 훨씬 더 논리적으로 보입니다:

그림 6. RAMMap은 메모리 사용량에 대한 세부 정보를 표시합니다: 매핑된 파일은 캐시된 데이터베이스입니다

데이터베이스 파일(dbw350.fb252x64.fdb 및 dbw250.fb252x64.fdb)은 운영 체제에 의해 캐시되며 작업 관리자가 여유 공간으로 선언한 전체 메모리를 차지합니다:

그림 7. RAMMap: 파일 캐시 사용량에 대한 세부 정보

따라서 우리는 운영 체제가 데이터베이스를 메모리에 완전히 로드할 때까지 사용 가능한 전체 메모리를 효과적으로 사용하여 데이터베이스를 캐시한다고 결론을 내립니다.

디스크 하위 시스템

디스크 하위 시스템의 올바른 구성은 Firebird용 하드웨어를 선택하고 구성하는 데 중요한 역할을 합니다. 이 단계에서의 실수는 수정하기 어려운 주요 장애를 초래할 수 있기 때문입니다.

모든 것을 위한 별도의 디스크

데이터베이스 파일 작업 간의 디스크 입력/출력 경쟁을 줄이고 데이터베이스와 백업이 동시에 손실될 가능성을 낮추기 위해, 세 개의 서로 다른 디스크(또는 RAID 어레이)를 두는 것이 권장됩니다: 하나는 데이터베이스용, 하나는 임시 파일용, 하나는 백업 복사본 생성 및 저장용입니다.

“별도의 디스크"라고 말할 때, 데이터 흐름이 서로 다른 입력/출력 채널을 통과해야 한다는 의미입니다. 하나의 물리적 디스크에 세 개의 논리적 디스크를 만들면 성능이 향상되지 않습니다. 그러나 다중 채널 컨트롤러가 장착된 데이터 저장 장치에 세 개의 논리적 디스크를 구성하면, 장치가 컨트롤러 간에 데이터 흐름을 분산할 수 있으므로 성능이 향상될 가능성이 높습니다. 때로는 운영 체제 파일과 운영 체제 스왑 파일 저장을 위해 별도의 디스크를 전용으로 사용하면 성능이 향상된다고도 합니다.

데이터베이스용 SSD

SSD는 병렬 입력/출력 중 뛰어난 확장성을 보장하므로 데이터베이스 작업에 가장 적합한 선택입니다. 읽기/쓰기 주기가 증가된 엔터프라이즈 디스크를 반드시 사용해야 합니다. 그렇지 않으면 SSD 장애로 인해 데이터를 잃을 가능성이 매우 높습니다.

얼마 전까지만 해도 SSD는 디스크에 여유 공간이 거의 없을 때(30% 미만) 마모가 증가하는 경향이 있었습니다. 간단히 말해, SSD의 각 수정은 새 여유 셀에 기록되므로 여유 공간 부족은 남아 있는 여유 셀의 마모를 증가시키고 디스크 수명을 단축시켰습니다.

최신 SSD 컨트롤러 제조업체는 정적 데이터를 예방적으로 이동하여 이 문제를 해결했으며 이제 셀 마모가 어느 정도 균등해졌다고 주장합니다. 그러나 SSD의 정확한 사양과 작동 알고리즘은 제조업체가 기밀로 유지하므로, 우리는 여전히 SSD에 30%의 공간을 비워두고 예상 수명을 줄여 3년에 한 번 이상 교체할 계획을 세울 것을 권장합니다.

현재 데이터베이스 크기가 100GB이고 매월 1GB씩 증가한다고 가정해 보겠습니다. 이 경우 최소 크기의 SSD(120GB)를 구매해서는 안 되며, 제품 라인의 다음 장치인 250GB를 선택하는 것이 좋습니다. 동시에 512GB SSD를 구매하는 것은 3년 후 디스크를 교체하는 것이 바람직하므로 돈 낭비가 될 것입니다.

가장 좋은 방법은 SSD를 데이터베이스 작업 전용으로 사용하는 것입니다. 모든 입력/출력 작업은 디스크 수명을 줄이기 때문입니다.

임시 파일용 디스크

임시 파일은 RAM이 충분하지 않을 때만 디스크에 나타나므로, 물론 이 상황을 아예 피하는 것이 가장 좋은 방법입니다. 프로덕션 시스템에서 임시 파일의 수와 크기를 평가하는 것은 임시 파일 폴더를 모니터링해야만 가능합니다. HQbird 배포 패키지의 FBDataGuard가 이러한 모니터링을 수행합니다. 디스크에 생성되는 임시 정렬 파일의 수와 생성 시점을 알게 되면 RAM 용량을 늘리고 firebird.conf의 구성을 변경할 수 있습니다.

어쨌든 Firebird는 임시 파일이 저장될 폴더를 지정해야 합니다. 일반적으로 기본값은 변경하지 않고 운영 체제의 임시 파일 폴더를 사용합니다. 여유 RAM이 충분하다면 이것은 좋은 선택입니다.

그러나 디스크에서 임시 파일의 위치와 관련된 또 다른 중요한 문제가 있습니다. 바로 gbak 유틸리티로 생성된 검증된 백업 복사본을 복원할 때 인덱스를 생성하는 것입니다. 인덱스가 생성되면 이 인덱스의 모든 키가 포함된 임시 파일도 생성됩니다. 데이터베이스가 상당히 크면 일부 대형 테이블의 인덱스 크기도 상당히 클 수 있습니다. 예를 들어, 1테라바이트 데이터베이스에서 32억 개의 레코드를 포함하는 가장 큰 테이블의 인덱스는 29GB이지만, 이 인덱스를 생성하는 데 180GB의 여유 공간이 필요했습니다:

시스템 디스크의 여유 공간 부족을 방지하기 위해 firebird.conf에서 추가 예약 공간으로 다른 디스크를 하나 더 지정할 수 있습니다:

TempDirectories =C:\temp; H:\Temp

첫 번째 디스크에 공간이 없으면 Firebird는 계속해서 두 번째 디스크를 임시 파일용으로 사용하는 식입니다.

백업용 HDD

SATA 또는 nSAS 인터페이스를 갖춘 일반 HDD는 백업 복사본 생성 및 저장에 적합합니다. 백업 파일에 대한 빠른 순차 쓰기 및 읽기 작업을 보장하며 크기를 아끼지 않고 여러 백업 복사본을 유지할 수 있을 만큼 저렴합니다.

백업 복사본용 디스크에는 항상 추가 여유 공간이 남아 있어야 합니다: 최신 백업 복사본 크기 + 10%. 이 경우 새 백업 복사본을 만들고 백업 프로세스가 성공적으로 완료되었는지 확인한 다음(수 테라바이트 크기의 데이터베이스의 경우 이 프로세스는 몇 시간이 걸릴 수 있음) 이전 백업 복사본을 삭제할 수 있습니다.

새 백업 복사본이 생성되기 전에 이전 백업 복사본을 삭제하면, 새 백업 복사본이 생성되지 않을 수 있고 이전 복사본은 이미 삭제된 상태에서 데이터베이스가 예를 들어 디스크 장애로 인해 손상될 수 있습니다.

위에서 권장한 백업 방법(증분 3단계 백업과 하루에 한 번 최신 복사본만 저장하는 검증된 백업의 조합)을 사용하는 경우 다음 공식을 사용하여 백업에 필요한 최소 공간을 계산합니다:

Database_size*3+0.2.Database_size

백업에 필요한 공간의 샘플 계산을 고려해 보겠습니다:

100GB 데이터베이스가 있고 3단계 증분 백업(주-일-시간 - 각각 하나의 복사본)과 일일 검증된 백업 복사본 하나를 저장한다고 가정합니다. 이 경우 백업 복사본은 다음 공간을 차지합니다:

Nbackup_level_0.weekly - 100GB
Nbackup_level_1.daily - 약 5GB
Nbackup_level_2.hourly - 약 200MB
일일 검증된 백업 - 약 100GB
또한 다음 백업 복사본을 생성할 수 있도록 110GB의 예약 공간이 필요합니다.

총 - 316GB.

! 1단계 이상의 증분 파일 크기는 nbackup이 마지막으로 실행된 이후 수정된 페이지 수에 따라 달라집니다. 이러한 파일의 크기는 데이터베이스의 변경량이 애플리케이션에 따라 달라지므로 실험적으로만 결정할 수 있습니다.

물론, 백업을 위한 공간을 산정할 때는 데이터베이스 크기의 비정상적인 증가 가능성을 고려하여 여유 공간을 그에 맞게 늘려야 합니다. 그렇지 않으면 공간 부족으로 인해 백업 프로세스가 예기치 않게 중단될 수 있습니다.

당연히, 스마트 백업 도구(HQbird의 FBDataGuard)는 백업 복사본을 위한 공간 부족을 감지하고 관리자에게 해당 메시지를 보냅니다.

데이터베이스용 HDD

SSD는 너무 비싼 솔루션이거나 데이터베이스가 너무 커서 덜 비싼 방법을 사용해야 할 수도 있습니다. 이 경우 SAS 인터페이스가 있는 HDD를 사용해야 합니다. 그것이 불가능하다면, nSAS 인터페이스가 있는 SATA 디스크나 가장 저렴한 옵션인 일반 SATA 디스크를 사용하십시오.

하드 디스크의 속도(및 아래에서 설명할 신뢰성)를 높이려면 RAID10으로 결합해야 합니다. RAID10은 미러링(RAID1)과 스트라이핑(RAID0) 블록의 조합입니다. 대용량 캐시를 갖춘 잘 구성된 RAID 컨트롤러는 SSD에 대한 훌륭한 대안입니다.

신뢰성 및 RAID

물론, 위에서 언급한 모든 변형(임시 파일 전용 디스크 제외)에서 디스크를 RAID로 결합하여 디스크 하위 시스템의 신뢰성을 높이는 것이 필요합니다.

• SSD의 경우 RAID1을 사용해야 합니다. 즉, 두 개의 미러링된 디스크에 변경 사항이 동시에 기록되어 데이터를 잃을 가능성이 훨씬 줄어듭니다. SSD로 구성된 RAID 10은 RAID 버스가 처리량을 제한하므로 대부분 중복될 가능성이 높습니다. 예를 들어, 6Gbit/s 인터페이스는 초당 600MB의 처리량을 가지며 최신 단일 SSD는 이미 이 속도에 도달했습니다. 따라서 RAID 10의 경우에도 동일한 600MB/s 제한을 얻게 됩니다.

단, PCI Express 3.0을 사용하여 SSD를 RAID 10으로 결합할 수 있습니다. 이 버스의 처리량은 이미 초당 16기가비트 이상이기 때문입니다.

• 백업 목적으로 HDD를 사용하는 경우 RAID1이면 충분하며 백업 복사본의 안전과 허용 가능한 읽기/쓰기 속도를 보장합니다.

• 데이터베이스에 사용되는 HDD는 비용, 신뢰성 및 성능의 최적 조합을 제공하는 RAID10(최소 4개 디스크)으로 결합해야 합니다. 일부 사용자는 더 큰 공간을 위해 성능을 희생하면서 RAID5를 사용하기도 합니다.

Firebird용 RAID 구성

우선, RAID에 제대로 충전된 백업 배터리 유닛(BBU)이 있는지 확인해야 합니다. 이러한 배터리 유닛이 없으면 대부분의 RAID는 안전한 쓰기 모드(디스크 캐시가 완전히 비활성화됨)로 전환되어 일반 SATA 디스크보다 낮은 입출력 속도를 제공합니다!

이 사실은 값비싼 서버를 구입하고 데스크톱 컴퓨터보다 느리게 작동한다는 것을 알게 된 사용자들의 기술 지원에 대한 대부분의 불만 메시지의 원인입니다. 불행히도 일부 공급업체는 기본적으로 배터리 유닛을 포함하지 않으므로 이것이 가장 먼저 확인하고 필요한 경우 수정해야 할 사항입니다.

그런 다음 읽기 및 쓰기 캐시를 구성해야 합니다. 종종 캐시는 기본적으로 비활성화되어 있으며 RAID를 상당히 빠르게 만들려면 캐시를 활성화해야 합니다.

캐시를 활성화하는 것 외에도 작동 방식을 확인해야 합니다. write through 또는 write back일 수 있습니다. 캐시로 작업하는 빠른 방법은 write back입니다. 이 경우 모든 변경 사항이 캐시 컨트롤러에 기록된 후 잠시 후 디스크에 직접 기록됩니다.

RAID와 함께 제공되는 제조업체 도구를 사용하여 배터리 유닛, 캐시 및 모드를 확인할 수 있습니다.

최신 RAID 컨트롤러는 캐시를 미세 조정할 수도 있습니다. 읽기 또는 쓰기를 용이하게 하도록 조정할 수 있습니다. 일반적으로 읽기와 쓰기에 대해 50%/50%로 분할됩니다.

캐시를 정확히 구성하는 방법을 알아내기 위해 고급 HQbird 배포 패키지의 MON$ Logger 도구를 사용할 수도 있습니다. 이 도구는 서버에 처음 연결한 시점부터 집계된 읽기 및 쓰기 작업의 비율을 보여줍니다:

그림 8. HQbird MON$Logger: 읽기/쓰기 비율

보시다시피 이 예에서는 쓰기 작업보다 읽기 작업이 훨씬 많으므로 RAID 컨트롤러를 읽기 작업 80%, 쓰기 작업 20%로 구성하는 것이 합리적입니다.

SAN 및 데이터베이스

통합 스토리지가 최근에 인기를 얻고 있습니다. 여기에는 고급 캐싱 기능을 갖춘 유연하게 사용자 정의할 수 있는 디스크 배열(모든 유형의 RAID)이 포함됩니다. 일반적으로 SAN에는 여러 입출력 컨트롤러가 있어 여러 서버를 동시에 서비스하고 상당히 빠르게 작동할 수 있습니다.

많은 조직에서 SAN을 구입하여 Firebird 데이터베이스 작업에 사용합니다. SAN이 올바르게 구성되면 좋은 성능을 달성할 수 있습니다. SAN을 사용하는 경우 다음 사항을 고려해야 합니다:

다중 채널 데이터 교환을 제공하는 여러 고성능 디스크 컨트롤러가 있어야 합니다.
설계상 제공되는 경우 백업 배터리 유닛(BBU)이 있어야 합니다.
데이터베이스 디스크는 RAID10으로 결합해야 합니다.
캐시가 활성화되어야 하며 쓰기 모드는 write back으로 전환되어야 합니다.
여러 컴퓨터가 SAN에 연결된 경우 각 컴퓨터에는 자체 컨트롤러가 있어야 합니다.
최신 SAN 드라이버가 설치되어 있어야 합니다. 이후 제공된 드라이버가 30%의 성능 향상을 제공한 사례를 접한 적이 있습니다.
SAN에 여러 논리 디스크(데이터베이스, 백업 복사본, 운영 체제용)가 있는 경우 서로 다른 입출력 채널을 가집니다. 모든 디스크에 하나의 채널을 함께 사용하려고 하면 성능이 저하됩니다.
마찬가지로 여러 서버와 데이터베이스가 동시에 SAN을 사용하는 경우 입출력 컨트롤러의 대역폭 증가로 인해 성능이 저하될 수 있습니다.
운영 체제와 임시 파일은 로컬 디스크에 저장하고 데이터베이스와 백업 파일은 SAN에 저장하는 결합 방식이 자주 사용됩니다.

장애 방지 클러스터를 만들기 위해 SAN은 종종 “두 서버 - 하나의 SAN"으로 사용됩니다. 이러한 클러스터는 서버 중 하나의 하드웨어 오류와 관련된 문제만 두 번째 서버로 즉시 전환하여 해결할 수 있습니다. 문제가 SAN이나 데이터베이스 자체와 관련된 경우 이 솔루션은 도움이 되지 않습니다.

실제로 장애 방지 솔루션을 구축하려면 두 데이터베이스 인스턴스 간에 데이터를 복제하는 솔루션을 사용해야 합니다. Firebird에 사용 가능한 더 많은 솔루션을 알아보려면 [email protected]에 문의할 수 있습니다.

간략한 결론 및 권장 사항

Firebird와 관련된 하드웨어에 대한 결론과 권장 사항을 요약해 보겠습니다.

많은 수의 사용자를 서비스하려면 멀티 코어 CPU를 사용해야 합니다.
최소 RAM 용량은 사용자 수와 데이터베이스 구성에 따라 계산되며, 초과 RAM은 운영 체제가 데이터베이스 파일을 캐시하는 데 효과적으로 사용됩니다.
데이터베이스, 임시 파일 및 백업 파일에 별도의 디스크를 사용하십시오.
데이터베이스에는 SSD를 사용하는 것이 좋습니다.
SSD에 최소 30%의 여유 공간을 확보하십시오.
데이터베이스 전용 디스크를 할당하는 것이 좋습니다.
엔터프라이즈 SSD(읽기/쓰기 주기가 많은)를 사용하십시오.
RAID를 사용해야 합니다.
SSD의 경우 - RAID 1, HDD의 경우 - RAID10, 백업 HDD의 경우 - RAID1. i. SAS, SATA, nSAS
RAID 배터리가 있고 충전되어 있는지 확인하십시오.
write back으로 전환되어 있는지 확인하십시오.
일부 RAID 컨트롤러는 이미 캐시 크기가 구성되어 있습니다(예: 읽기 75%, 쓰기 25%, 또는 50/50 등). 따라서 RAID 매개변수를 제어하고 읽기/쓰기 비율을 확인하며 RAID 설정을 변경할 수 있는 MON$Logger 소프트웨어를 설치해야 합니다.
SAN 사용에는 장단점이 있습니다. 최대한 활용하려면 SAN을 올바르게 구성해야 합니다.
장애 방지 솔루션을 구축하려면 다른 서버에서 실행되는 복제본이 있는 솔루션을 사용해야 합니다.

연락처

IBSurgeon/IBase.ru 회사는 기업을 위한 고급 HQbird 배포 패키지를 개발하고 Firebird에 대한 복잡한 기술 지원을 제공하며 맞춤형 배포 패키지를 개발하고 기타 복잡한 문제를 해결하고 있습니다.

IBSurgeon은 Firebird 데이터베이스 성능을 향상시키기 위한 Firebird 최적화 서비스도 제공합니다.

문의하기: [email protected]