고객 중 한 명은 평균 활성 연결 수가 약 70-80 인 35GB 데이터베이스를 보유하고 있습니다. 데이터베이스의 일부 테이블에는 테이블 당 10M 이상의 레코드가 있습니다.대용량 페이지 버퍼 대 다중 동시 프로세스
이제는 4 * 6 코어 = 24 코어 CPU, 48Gb RAM, 2 개의 RAID 컨트롤러 256MB 캐시, 각각 8 개의 SAS 15K HDD를 구입했습니다.
64 비트 OS. 내가 궁금하네요
는 빠른 구성 무엇을 할 것입니다 : 큰 버퍼
1) FB 2.5의 슈퍼 8192 * 3500000 페이지 = 29 기가
또는
와2) FB 2.5 클래식 1000 페이지의 작은 버퍼.
어쩌면 몇 일 전에 이러한 경우를 테스트하고 나에게 작업 : 사전에
감사의 일을 저장합니다.
많은 프로세서가 있으므로 Classic으로 시작합니다.
하지만 모두 시도해보십시오.
아마도 곧 수퍼 클래식으로 2.5는 좋은 것입니다.
확실히 '고전적인'아키텍처 중 하나를 선택하십시오.
Firebird 2.5를 사용하는 경우 check out SuperClassic.
슈퍼 서버는 오직 하나의 프로세서 만 사용합니다. 24 개의 코어가 있으므로 가장 좋은 옵션은 Clasic을 사용하는 것입니다. SuperClasic은 아직 다중 프로세서 환경에서 확장 성이 좋지 않습니다.
현재 비슷한 요구 사항이있는 고객이 있습니다.
무료 메모리 (RAM)가 있으면 윈도우와 리눅스가 파이어 버드가 데이터베이스를 캐싱하기 때문에 FirebirdSQL 2.5 SuperClassic을 설치하고 기본 작은 캐싱 설정 만 남겨 두는 것이 가장 좋은 해결책입니다. Firebird의 캐싱 기능은 그리 빠르지 않으므로 OS가 그렇게하도록하십시오.
또한 사용하는 백업 소프트웨어에 따라 - 파이어 버드 데이터베이스의 전체 백업을 자주 만드는 경우 데이터베이스에서 강제 쓰기를 비활성화 할 수 있습니다. (만약 당신이 무엇을하고 있는지 알고 있다면 강제적 인 쓰기를 비활성화함으로써 어떤 일이 일어날 지 알기 만하면됩니다.)
필자는 _Windows에 동의하지 않으며 리눅스는 파이어 버드보다 데이터베이스 캐싱을 더 잘 수행합니다. 정확하게 말하면 무엇을 의미하는지 자세히 설명해야한다고 생각합니다. – jachguate
필요하면 누구든지 이전 스레드를 찾아냅니다.
우리는 fb classic 2.5를 75GB db 기계에서 거의 동일한 것으로 설명합니다.
SuperServer는 테스트 중에 비효율적이었습니다. 버퍼 및 페이지 크기 변경으로 인해 성능이 약간 비참 해졌습니다. 당신은 아마 serverfault.com에 그들을 찾을 수있는 사람이 있다면
현재 우리는 xinetd를, 페이지 크기 = 16384, 페이지 버퍼 = 5000,
와 클래식을 사용합니다. – mghie