Firebird 硬件指南

_by Alexey Kovyazin, последнее обновление: 30 ноября 2015 года

Вы часто можете увидеть следующий вопрос в группах технической поддержки Firebird: «Какое оборудование выбрать для СУБД Firebird?». Эта тема остается постоянно популярной, потому что требования к оборудованию различаются в зависимости от задач, а само оборудование меняется со временем.

Мы решили написать это руководство, чтобы предоставить необходимые знания всем, кто хочет выбрать действительно эффективное оборудование для своей базы данных Firebird. Для этого вам придется изучить некоторые базовые детали о том, как работают Firebird, операционная система и, конечно же, оборудование.

Немного теории

Чтобы выяснить, какое оборудование лучше всего подойдет для вашей базы данных Firebird, мы должны понять, как Firebird использует свои компоненты: процессор, оперативную память, HDD/SSD и как эти компоненты взаимодействуют с операционной системой (например, с файловым кэшем).

Функциональные модули сервера Firebird

Прежде всего, мы рассмотрим функциональные модули Firebird с помощью рисунка 1:

Рисунок 1. Модули Firebird

Firebird включает следующие основные функциональные модули:

Объекты метаданных: представления, таблицы, индексы, триггеры, хранимые процедуры и другие объекты базы данных. Объекты метаданных расположены в адресном пространстве процесса Firebird (это может быть fbserver, fb_inet_server или firebird.exe).
Кэш буферов страниц содержит страницы базы данных, прочитанные с диска, и расположен в адресном пространстве серверного процесса. Механизм кэширования страниц довольно сложен, поэтому мы лишь отметим, что Firebird кэширует наиболее часто используемые страницы базы данных.
Firebird сортирует записи в памяти (в адресном пространстве серверного процесса), пока объем памяти, используемой для всех одновременных операций сортировки, не достигнет предела, установленного параметром TempCacheLimit (firebird.conf). Как только этот предел превышен, в папке с временными файлами создается временный файл (с соответствующим флагом операционной системы), который используется для сортировки. Если в системе есть свободная оперативная память, файл сортировки будет кэшироваться операционной системой, и сортировка будет выполняться в памяти.
Глобальные временные таблицы (GTT) создаются как временные файлы в операционной системе. Если у операционной системы есть свободная память, операции с GTT выполняются в оперативной памяти.

Основные операции с оборудованием

Давайте посмотрим, как функциональные модули Firebird взаимодействуют с аппаратными компонентами во время операций, выполняемых в процессе работы с базами данных.

После запуска Firebird серверный процесс занимает минимальный объем оперативной памяти (несколько мегабайт) и не выполняет интенсивных операций с процессором или оперативной памятью.

Когда устанавливается соединение с базой данных, сервер начинает читать ее метаданные и создавать соответствующие объекты в памяти, в результате чего процесс занимает тем больше ресурсов, чем больше таблиц, индексов, триггеров и других метаданных используется. Использование памяти увеличивается, но на этом этапе процессор практически не задействован.

Когда клиент начинает выполнять 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
Дисковый ввод/вывод	10	10	1	1	1	1	1	1

Как вы можете видеть, наиболее ресурсоемкими являются операции, связанные с доступом к диску, потому что диски остаются самым медленным аппаратным компонентом, несмотря на прогресс последних лет, связанный с SSD.

Это приводит к одному из способов оптимизации производительности, который полностью связан с оборудованием, - перенести все операции чтения и записи в оперативную память. Но обратите внимание, что подход с увеличением кэша страниц не работает. Мы подробно рассмотрим этот вопрос в разделе об оперативной памяти.

Одновременно выполняемые операции

Обычно необходимо выбирать оборудование для сервера, который будет обслуживать множество клиентов, поэтому очень важно понимать, как реализован параллелизм операций.

С точки зрения аппаратных компонентов мы можем говорить о параллельном использовании процессора, диска и оперативной памяти. Современные процессоры имеют несколько ядер, которые могут выполнять наборы инструкций параллельно, поэтому сервер СУБД распределяет операции между ядрами, что означает вывод: чем больше ядер у процессора, тем больше клиентов смогут работать на этом сервере.

С точки зрения дисков все не так просто. Когда традиционные жесткие диски (HDD) читают информацию, они физически перемещают головку над магнитным материалом с некоторой конечной скоростью. База данных может быть довольно большой, например, 3 терабайта, и если SQL-запросы от клиентов обращаются к ее данным, расположенным в разных областях диска параллельно, головка диска будет прыгать между разными областями, серьезно замедляя операции чтения и записи. Это значительно увеличит очередь диска, в то время как остальные ресурсы (процессор, оперативная память) будут простаивать. Конечно, кэш диска (кэш HDD или RAID-контроллера) в некоторой степени компенсирует это замедление, но этого недостаточно.

В отличие от традиционных HDD, твердотельные накопители (SSD) гораздо менее подвержены деградации производительности при параллельном доступе к данным. Преимущество SSD особенно очевидно при параллельной записи данных - наши тесты показывают, что SSD в 7 раз быстрее SATA-диска (ссылка!). Однако у SSD есть некоторые проблемы, которые необходимо учитывать при их использовании (см. «Выбор дисков»), чтобы избежать замедлений, преждевременных поломок и потери данных.

Операции с оперативной памятью на современных компьютерах выполняются очень быстро, они практически ограничены только пропускной способностью шины данных, поэтому эти операции не являются узким местом, даже если есть много параллельных SQL-запросов.

Потоки данных

При выполнении SQL-запросов Firebird читает и записывает много данных, передает их между функциональными модулями и соответствующими аппаратными компонентами. Чтобы выявить возможные узкие места, нам нужно понять, как осуществляется обмен данными. Рисунок 2 ниже поможет нам в этом:

Рисунок 2. Потоки данных между оперативной памятью и постоянным хранилищем

Очевидно, что передача данных из постоянного хранилища в оперативную память и обратно является самой трудоемкой операцией. Она создает два потока данных: чтение/запись страниц данных из файлов базы данных и чтение/запись файлов сортировки. Поскольку файлов сортировки может быть несколько и они могут быть довольно большими, они могут создавать значительную нагрузку на диски, поэтому целесообразно направлять эти потоки ввода/вывода на разные диски.

Резервное копирование

Firebird предлагает два метода резервного копирования: проверенное резервное копирование с помощью утилиты gbak и непроверенное инкрементальное резервное копирование с помощью утилиты nbackup.

Мы рекомендуем комбинировать эти методы резервного копирования: запускать nbackup часто (например, каждый час, день и неделю) и создавать проверенную резервную копию каждую ночь с помощью gbak.

Какой бы метод резервного копирования вы ни использовали, файл базы данных читается (целиком или частично) и записывается резервная копия (полная или инкрементальная). Операции записи выполняются последовательно во время процесса резервного копирования, что означает, что обычные недорогие жесткие диски с интерфейсом SATA (HDD SATA) будут хороши для резервного копирования, поскольку они последовательно записывают довольно быстро.

选择合适的硬件

既然我们已经了解了 Firebird 如何与硬件交互，接下来就应该详细探讨影响每个特定组件及其规格选择的因素。

有时，特定数据库的实际统计数据会严重影响硬件组件的选择，因此我们将使用 HQbird（IBSurgeon 出品的 Firebird 专业发行包）中的工具来获取这些统计数据。您可以在 http://hqbird.com/en/hqbird/ 下载 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 运行一个进程，为所有连接提供一个页缓存。

因此，以下参数影响总体内存消耗：

连接数
数据库页大小
元数据大小（与表、触发器、存储过程等的数量成正比；不可调整；由实际使用情况决定）
页缓存大小（由数据库头、firebird.conf 或特定连接的属性中的参数决定）
1. 对于 Classic 和 SuperClassic–每个连接
2. 对于 SuperServer–每个打开的数据库实例
排序缓存大小（由 firebird.conf 中的参数决定）。请注意，排序内存不是一次性分配的，而是根据需要逐步分配的。
1. 对于 Classic–每个连接
2. 对于 SuperServer 和 SuperClassic–每个进程（即一个排序缓存）
对于 Classic/SuperClassic–锁表大小（通常很小，因此我们将其排除在计算之外）。

IBSurgeon 公司进行了一些测试，获得了 Firebird 页缓存中页数的一组最优值：

Classic/SuperClassic–256 到 2000 页
SuperServer 2.5–10000 页
SuperServer 3.0–100000 页

以这些测试为基础，我们为 4-6 GB 内存的服务器创建了优化的 Firebird 配置文件。您可以在此处下载：/zh/optimized-firebird-configuration/

计算所需 RAM 容量的公式

下面您可以看到用于估算 Firebird 所需大致内存容量的公式。实际内存消耗可能有所不同，因为此估算未考虑元数据、索引位掩码等所需的内存，这些可能会增加内存消耗。然而，它也假设所有连接都将充分利用排序内存，而实际情况通常并非如此。

当您的数据库已在运行时，您可以查看 Firebird 进程的平均内存使用量（借助任务管理器或 ProcessExplorer）。

Classic 的估算：

连接数 * (（缓存中的页数 * 页大小）+ 排序缓存大小 )

Classic 示例：假设我们预计有 100 个活跃用户，数据库页大小设置为 8 KB，页缓存中的页数设置为 256，排序缓存大小从 8 MB（Classic 和 SuperClassic 的默认值）增加到 64 MB：

((256.8 KB)+64) = 6600 MB

SuperClassic 的估算：

连接数 * (缓存中的页数 * 页大小) + 排序缓存大小

SuperClassic 示例：100 个用户，数据库页大小为 8 KB，页缓存中的页数为 256，排序缓存大小为 1024 MB

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

SuperServer 的估算：

(缓存中的页数 * 页大小) + 排序缓存大小

SuperServer（Firebird 2.5）示例：1 个数据库，100 个用户，数据库页大小为 8 KB，页缓存中的页数为 10000，排序缓存大小为 1024 MB：

(10000.8 KB) + 1024 = 1102 MB

SuperServer（Firebird 3.0）示例：1 个数据库，100 个用户，数据库页大小为 8 KB，页缓存中的页数为 100000，排序缓存大小为 1024 MB：

(100000.8 KB) + 1024 = 1805 MB

“内存过剩”

Firebird 经常因内存使用效率低下而受到指责–当服务器运行进程只消耗少量 RAM，而其余内存据称未被使用时。

实际上，这种说法并不正确。这一结论基本上源于对 Firebird 缓存机制工作原理的误解以及操作系统监控工具的不完善。

首先，你必须完全清楚，Firebird 广泛使用操作系统的文件缓存。当一个页面被加载到 Firebird 页面缓存中时，它会经过操作系统的文件缓存。当 Firebird 从其页面缓存中卸载一个页面时，只要操作系统有足够的空闲内存，它就会继续在 RAM 中保留该数据库块。

图 4. 缓存级别：Firebird、操作系统和存储

然而，如果你只是看一下，操作系统并不会显示分配给文件缓存的内存为已使用。例如，以下是 Firebird 服务器运行时内存分布的典型情况，如任务管理器所示：

图 5. 任务管理器不显示文件缓存使用情况

看起来好像 16 GB 中只使用了 6.3 GB。

但是，如果你使用 RAMMap 工具（来自微软的 SysInternals），一切看起来就更有逻辑了：

图 6. RAMMap 显示内存使用的详细信息：映射文件是被缓存的数据库

数据库文件（dbw350.fb252x64.fdb 和 dbw250.fb252x64.fdb）被操作系统缓存，并占用了任务管理器声明为空闲的全部内存：

图 7. RAMMap：文件缓存使用详情

因此我们得出结论，操作系统有效地使用所有可用内存来缓存数据库，直到将数据库完全加载到内存中。

磁盘子系统

磁盘子系统的正确配置在为 Firebird 选择和配置硬件时起着重要作用，因为此步骤中的任何错误都将导致难以修复的重大故障。

为所有内容使用独立磁盘

为了减少数据库文件操作之间的磁盘输入/输出竞争，并降低数据库和备份同时丢失的可能性，建议使用三个不同的磁盘（或 RAID 阵列）：一个用于数据库，一个用于临时文件，一个用于创建和存储备份副本。

当我们说“独立磁盘”时，意味着数据流必须通过不同的输入/输出通道。如果你在一个物理磁盘上创建三个逻辑磁盘，性能不会有任何提升。然而，如果你在配备多通道控制器的数据存储设备上安排三个逻辑磁盘，性能很可能会提高，因为设备可以在控制器之间分配数据流。有时，将单独的磁盘专用于存储操作系统文件和操作系统的交换文件也被认为可以提高性能。

数据库使用 SSD

SSD 是处理数据库的最佳选择，因为它们确保并行输入/输出时具有良好的扩展性。必须使用具有更高读写循环次数的企业级磁盘，否则极有可能因 SSD 故障而丢失数据。

一段时间以前，当磁盘上剩余可用空间较少（少于 30%）时，SSD 容易加剧磨损。简单来说，SSD 上的每次修改都会写入一个新的空闲单元，因此空闲空间的缺乏导致剩余空闲单元的磨损加剧，从而缩短了磁盘的使用寿命。

现代 SSD 控制器制造商声称，通过预防性移动静态数据解决了这个问题，现在单元的磨损或多或少是均衡的。然而，SSD 的确切规格和操作算法由制造商保密，因此我们仍然建议你在 SSD 上保留 30% 的空闲空间，同时降低其预期使用寿命，并计划至少每三年更换一次。

假设你当前的数据库大小为 100 GB，每月增长 1 GB。在这种情况下，你不应购买最小尺寸的 SSD（120 GB），而最好选择产品线中的下一个设备–250 GB。同时，购买 512 GB 的 SSD 将是浪费金钱，因为建议在三年内更换磁盘。

最佳实践是将 SSD 专用于数据库工作，因为任何输入/输出操作都会缩短磁盘的使用寿命。

临时文件磁盘

由于临时文件仅在 RAM 不足时出现在磁盘上，最好的方式当然是避免这种情况。只有在生产系统中监控临时文件文件夹，才能评估临时文件的数量和大小。来自 HQbird 发行版的 FBDataGuard 可以进行此类监控。一旦你了解了磁盘上创建了多少临时排序文件以及何时创建，你就能增加 RAM 数量并更改 firebird.conf 中的配置。

无论如何，Firebird 要求你指定存储临时文件的文件夹。通常，默认设置保持不变，即使用操作系统的临时文件文件夹。如果空闲 RAM 足够，这是一个不错的选择。

然而，关于临时文件在磁盘上的位置还有另一个重要问题–当你恢复经过验证的备份副本（使用 gbak 工具创建）时创建索引。创建索引时，也会创建一个包含该索引所有键的临时文件。如果数据库相当大，某些大表的索引大小也可能相当大。例如，一个 1 TB 数据库中包含 32 亿条记录的最大表的索引为 29 GB，但创建该索引需要 180 GB 的可用空间：

为了防止系统磁盘空间不足，可以在 firebird.conf 中指定另一个磁盘作为额外的保留空间：

TempDirectories =C:\temp; H:\Temp

如果第一个磁盘上没有空间，Firebird 将继续使用第二个磁盘存储临时文件，依此类推。

备份使用 HDD

带有 SATA 或 nSAS 接口的常规 HDD 适合创建和存储备份副本。它们确保备份文件的快速顺序写入和读取操作，并且价格足够便宜，不必在尺寸上节省，可以保留多个备份副本。

用于备份副本的磁盘必须始终留有额外的空闲空间：最新备份副本的大小 + 10%。在这种情况下，可以创建新的备份副本，确保备份过程成功完成（对于大小为几 TB 的数据库，此过程可能需要几个小时），然后才删除之前的备份副本。

如果你在新备份副本创建之前删除之前的备份副本，则可能不会创建新的备份副本，而旧的备份副本已被删除，数据库可能会损坏，例如由于磁盘故障。

如果你使用上面推荐的备份方法（三级增量备份与每天一次仅存储最新副本的验证备份的组合），请使用以下公式计算备份所需的最小空间：

数据库大小*3+0.2.数据库大小

让我们考虑以下备份所需空间的计算示例：

假设我们有一个 100 GB 的数据库，为其存储三级增量备份（周-日-小时–各一份）和一份每日验证备份。在这种情况下，备份副本将占用以下空间：

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 约 5 GB
Nbackup_level_2.hourly - 约 200 MB
每日验证备份 - 约 100 GB
另外，你需要保留 110 GB 以便能够创建下一个备份副本。

总计 - 316 GB。

！第一级或更高级别增量文件的大小取决于自上次运行 nbackup 以来修改的页面数量。这些文件的大小只能通过实验确定，因为数据库中的更改量取决于应用程序。

当然，备份空间的估算应考虑数据库大小可能出现的异常增长，并相应增加可用空间，否则备份过程可能因空间不足而意外中断。

自然，智能备份工具（来自HQbird的FBDataGuard）会注意到备份副本空间不足，并向管理员发送相应消息。

数据库用HDD

SSD可能过于昂贵，或者数据库可能太大，因此您必须使用成本较低的方法。在这种情况下，您应该使用带有SAS接口的HDD。如果不可能，请使用带有nSAS接口的SATA磁盘，或者最便宜的选择–普通SATA磁盘。

为了提高硬盘的速度（以及可靠性–见下文），您应该将它们组合成RAID10。RAID10是镜像（RAID1）和条带（RAID0）块的组合。一个良好且配置得当、带有大缓存的RAID控制器是SSD的不错替代方案。

可靠性与RAID

当然，有必要通过将磁盘组合成RAID来提高磁盘子系统的可靠性，这在上述所有方案中均应如此（专用于临时文件的磁盘除外）。

• 对于SSD，请确保使用RAID1–即同时写入两个镜像磁盘，这使丢失所有数据的可能性大大降低。由SSD组成的RAID 10很可能多余，因为RAID总线会限制吞吐量。例如，6 Gbit/s接口的吞吐量为每秒600兆字节，而现代单个SSD已达到此速度。因此，对于RAID 10，我们也会遇到相同的600 MB/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）。使用缓存的快速方式是回写–在这种情况下，任何更改都会写入缓存控制器，稍后直接写入磁盘。

您可以使用RAID随附的制造商工具来检查电池单元、缓存和模式。

现代RAID控制器还可以微调缓存–可以调整以促进读取或写入。通常，它按50%/50%分配用于读取和写入。

要了解如何精确配置缓存，您还可以使用高级HQbird发行包中的MON$ Logger工具。它显示读写操作之间的比率（从首次连接到服务器时聚合）：

图8. HQbird MON$Logger：读/写比率

如您所见，在此示例中，读操作远多于写操作，因此将RAID控制器配置为80%读操作和20%写操作是有意义的。

SAN与数据库

集成存储近年来变得流行。它们包括灵活可定制的磁盘阵列（所有类型的RAID），具有高级缓存功能。通常，SAN有多个输入/输出控制器，这使得同时服务多个服务器并相当快速地工作成为可能。

许多组织购买SAN并将其用于Firebird数据库的工作中。如果SAN配置正确，是否有可能获得良好的性能。如果您使用SAN，应考虑以下问题：

必须有多个高性能磁盘控制器，提供多通道数据交换
如果设计上提供，必须存在备份电池单元（BBU）。
数据库磁盘必须组合成RAID10。
必须启用缓存，写入模式必须切换到回写。
如果多台计算机连接到SAN，每台计算机必须有自己的控制器。
安装最新的SAN驱动程序。我们遇到过后来提供的驱动程序使性能提高30%的情况。
如果SAN上有多个逻辑磁盘（用于数据库、备份副本、操作系统），它们应有不同的输入/输出通道。尝试将所有磁盘共用一个通道将导致性能降低。
同样，如果多个服务器和数据库同时使用SAN，由于输入/输出控制器带宽增加，性能可能会降低。
经常使用组合方式–操作系统和临时文件存储在本地磁盘上，而数据库和备份文件存储在SAN上。

通常SAN被用作“两台服务器–一个SAN”以创建防故障集群。应注意，此类集群只能解决与其中一台服务器硬件故障相关的问题，方法是立即切换到第二台服务器。如果问题与SAN或数据库本身有关，此解决方案将无济于事。

要构建真正防故障的解决方案，您应该使用在两个数据库实例之间复制数据的解决方案。您可以联系[email protected]以了解Firebird可用的更多解决方案。

简要结论与建议

让我们总结关于Firebird硬件的结论和建议。

必须使用多核CPU来服务大量用户
最少RAM量根据用户数量和数据库配置计算，超出部分的RAM将被操作系统有效用于缓存数据库文件。
为数据库、临时文件和备份文件使用单独的磁盘
数据库最好使用SSD
在SSD上保留至少30%的可用空间。
建议为数据库专门分配一个磁盘。
使用企业级SSD（具有大量写/读周期）。
确保使用RAID。
对于SSD–RAID 1，对于HDD–RAID10，对于备份HDD–RAID1。i. SAS、SATA、nSAS
确保RAID电池存在且已充电
确保已切换到回写模式。
一些RAID控制器已配置了缓存大小，例如，75%用于读取，25%用于写入，或50/50等。因此有必要安装MON$Logger–控制RAID参数的软件，查看读/写比率并更改RAID设置。
使用SAN有利有弊。要充分利用它，您应该正确配置SAN。
要构建防故障解决方案，您需要使用在不同服务器上运行的复制解决方案。

联系方式

IBSurgeon/IBase.ru公司一直为企业开发高级HQbird发行包，提供Firebird的复杂技术支持，开发定制发行包以及解决其他复杂问题。

IBSurgeon 还提供 Firebird 优化服务来提升 Firebird 数据库性能。

联系我们：[email protected]