お問い合わせ
IBSurgeon
このページは機械翻訳されています。英語の原文をお読みください。 English

IBSurgeon ライブラリ

Firebirdハードウェアガイド

_by Alexey Kovyazin、最終更新日：2015年11月30日

Firebirdのテクニカルサポートグループでは、「Firebird DBMSに最適なハードウェアは何か？」という質問をよく見かけます。このトピックは、ハードウェアの要件がタスクによって異なり、ハードウェア自体も時代とともに変化するため、常に人気があります。

私たちは、Firebirdデータベースのために本当に効果的なハードウェアを選びたいすべての人に必要な知識を提供するために、このガイドを書くことにしました。そのためには、Firebird、オペレーティングシステム、そしてもちろんハードウェアがどのように機能するかについて、いくつかの基本的な詳細を学ぶ必要があります。

少し理論的な話

Firebirdデータベースに最適なハードウェアを見つけるには、FirebirdがCPU、RAM、HDD/SSDといったコンポーネントをどのように使用し、これらのコンポーネントがオペレーティングシステム（たとえばファイルキャッシュ）とどのように相互作用するかを理解する必要があります。

Firebirdサーバーの機能モジュール

まず、図1を使ってFirebirdの機能モジュールを見てみましょう：

図1. Firebirdのモジュール

Firebirdには、以下の主要な機能モジュールが含まれています：

  1. メタデータオブジェクト：ビュー、テーブル、インデックス、トリガー、ストアドプロシージャ、その他のデータベースオブジェクト。メタデータオブジェクトは、Firebirdプロセス（fbserver、fb_inet_server、またはfirebird.exe）のアドレス空間に配置されます。

  2. ページバッファのキャッシュには、ディスクから読み取られたデータベースページが含まれ、サーバープロセスのアドレス空間に配置されます。ページのキャッシュメカニズムはかなり複雑なので、Firebirdが最も頻繁に使用されるデータベースページをキャッシュすることだけを述べておきます。

  3. Firebirdは、すべての同時ソート操作に使用されるメモリ量がTempCacheLimitパラメータ（firebird.conf）で設定された制限に達するまで、レコードをメモリ内（サーバープロセスのアドレス空間）でソートします。この制限を超えると、一時ファイル（対応するオペレーティングシステムフラグ付き）が一時ファイル用フォルダに作成され、ソートに使用されます。システムに空きRAMがある場合、ソートファイルはオペレーティングシステムによってキャッシュされ、ソートはメモリ内で実行されます。

  4. グローバル一時テーブル（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に関連する進歩にもかかわらず、ディスクは依然として最も遅いハードウェアコンポーネントだからです。

これは、パフォーマンスを最適化する方法の1つにつながります。それは完全にハードウェアに関連するもので、すべての読み書き操作を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へのデータ転送とその逆の転送は、最も時間のかかる操作です。これにより、2つのデータフローが作成されます：データベースファイルからのデータページの読み取り/書き込みと、ソートファイルの読み取り/書き込みです。ソートファイルは複数存在する可能性があり、かなり大きくなる可能性があるため、ディスクにかなりの負荷がかかる可能性があります。したがって、これらの入出力フローを異なるディスクに振り向けることをお勧めします。

バックアップ

Firebirdは、gbakユーティリティを使用した検証済みバックアップと、nbackupユーティリティを使用した未検証の増分バックアップという2つのバックアップ方法を提供します。

これらのバックアップ方法を組み合わせることをお勧めします：nbackupを頻繁に実行し（たとえば、毎時間、毎日、毎週）、gbakを使用して毎晩検証済みのバックアップコピーを作成します。

どのバックアップ方法を使用しても、データベースファイル（全体または一部）が読み取られ、バックアップコピー（完全または増分）が書き込まれます。バックアッププロセス中は書き込み操作が順次実行されるため、SATAインターフェイスの通常の安価なハードドライブ（HDD SATA）は、順次書き込みがかなり高速であるため、バックアップに適しています。

选择适合的硬件

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

有时特定数据库的实际统计数据会强烈影响硬件组件的选择，因此我们将使用 HQbird（IBSurgeon 出品的 Firebird 专业发行包）中的工具来获取这些统计数据。您可以在 http://hqbird.com/en/hqbird/ 下载 HQbird 的试用版。

CPU

在选择 CPU 时，您应该考虑以下三件事：

  1. 应用程序中以哪种查询为主，
  2. 平均和峰值负载下数据库的活动连接数，
  3. 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 时，您应注意两件事：

  1. 内存模块必须具有纠错码（ECC RAM）
  2. RAM 容量必须正确计算

ECC RAM

ECC RAM 能显著减少内存工作过程中出现的错误数量，强烈建议在工业系统中使用。

所需 RAM 容量计算

要计算内存容量，我们需要了解各种 Firebird 架构的特性。Firebird 2.5 Classic 和 Firebird 3.0 Classic 为每个连接运行一个独立进程，SuperClassic 为每个连接运行一个独立线程，但内存消耗结构实际上相同–每个连接都有自己独立的页缓存。

Firebird SuperServer 运行一个进程，为所有连接提供一个页缓存。

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

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

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

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

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

计算所需 RAM 容量的公式

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

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

Classic 的估算：

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

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

  1. ((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、OS、ストレージ

しかし、単に見ただけでは、オペレーティングシステムはファイルキャッシュに割り当てられたメモリを使用中として表示しません。たとえば、Firebirdサーバーが実行されているときのメモリ配分の典型的な状況をタスクマネージャーで示すと次のようになります:

図5. タスクマネージャーはファイルキャッシュの使用量を表示しない

16 GBのうち6.3 GBしか使用されていないように見えます。

しかし、RAMMapツール（MicrosoftのSysInternals製）を使用すると、すべてがはるかに論理的に見えます:

図6. RAMMapはメモリ使用量の詳細を表示: マップされたファイルはキャッシュされたデータベース

データベースファイル（dbw350.fb252x64.fdbおよびdbw250.fb252x64.fdb）はオペレーティングシステムによってキャッシュされ、タスクマネージャーが空きとして宣言したメモリ全体を占有します:

図7. RAMMap: ファイルキャッシュ使用量の詳細

したがって、オペレーティングシステムは利用可能なメモリ全体を効果的に使用してデータベースをキャッシュし、データベースを完全にメモリにロードすることまで行うと結論付けます。

ディスクサブシステム

ディスクサブシステムの正しい構成は、Firebird用のハードウェアの選択と構成において重要な役割を果たします。このステップでのミスは、修正が困難な重大な障害につながるためです。

すべてに別々のディスク

データベースファイルの操作間でのディスク入出力の競合を減らし、データベースとバックアップの同時損失の可能性を減らすために、3つの異なるディスク（またはRAIDアレイ）を持つことをお勧めします: 1つはデータベース用、1つは一時ファイル用、1つはバックアップコピーの作成と保存用です。

「別々のディスク」と言う場合、データフローが異なる入出力チャネルを通過する必要があることを意味します。1つの物理ディスク上に3つの論理ディスクを作成しても、パフォーマンスは向上しません。ただし、マルチチャネルコントローラーを備えたデータストレージデバイス上に3つの論理ディスクを配置すると、デバイスがコントローラー間でデータフローを分散できるため、パフォーマンスが向上する可能性が高くなります。オペレーティングシステムファイルとオペレーティングシステムのスワップファイルの保存に専用のディスクを割り当てると、パフォーマンスが向上すると言われることもあります。

データベース用SSD

SSDは、並列入出力時の優れたスケーリングを保証するため、データベースの操作に最適な選択肢です。読み取り/書き込みサイクル数が増加したエンタープライズディスクを使用することが必須です。そうしないと、SSDの障害によりデータを失う可能性が非常に高くなります。

少し前まで、SSDはディスクに空き領域がほとんどない場合（30%未満）、摩耗が増加する傾向がありました。簡単に言えば、SSD上の各変更は新しい空きセルに書き込まれるため、空き領域の不足は残りの空きセルの摩耗を増加させ、ディスクの寿命を短くしました。

最新のSSDコントローラーのメーカーは、この問題は静的データの予防的な移動によって解決され、現在はセルの摩耗がほぼ平準化されていると宣言しています。ただし、SSDの正確な仕様と動作アルゴリズムはメーカーによって秘密にされているため、SSDに30%の空き領域を残すこと、および期待寿命を短く見積もって3年に1回以上は交換を計画することを引き続きお勧めします。

データベースの現在のサイズが100 GBで、毎月1 GB増加するとします。この場合、最小サイズのSSD（120 GB）を購入してはならず、製品ラインの次のデバイス（250 GB）を選択する方が良いでしょう。同時に、512 GBのSSDを購入することはお金の無駄になります。ディスクは3年で交換することをお勧めするためです。

最善の方法は、データベースの操作専用にSSDを割り当てることです。入出力操作はディスクの寿命を縮めるためです。

一時ファイル用ディスク

一時ファイルはRAMが十分にない場合にのみディスク上に現れるため、もちろん最善の方法はこの状況を完全に回避することです。本番システムでの一時ファイルの数とサイズを評価するには、一時ファイルのあるフォルダーを監視することによってのみ可能です。HQbirdディストリビューションパッケージのFBDataGuardがこの種の監視を行います。ディスク上に作成される一時ソートファイルの数と作成時期がわかれば、RAMの量を増やし、firebird.confの構成を変更できるようになります。

いずれの場合も、Firebirdでは一時ファイルが保存されるフォルダーを指定する必要があります。通常、デフォルトは変更されず、オペレーティングシステムの一時ファイル用フォルダーが使用されます。空きRAMが十分であれば、これは良い選択です。

ただし、ディスク上の一時ファイルの場所に関するもう1つの重要な問題があります。それは、検証済みのバックアップコピー（gbakユーティリティで作成されたもの）を復元するときのインデックス作成です。インデックスが作成されると、このインデックスのすべてのキーを含む一時ファイルも作成されます。データベースがかなり大きい場合、大きなテーブルのインデックスのサイズもかなり大きくなる可能性があります。たとえば、1テラバイトのデータベースで32億レコードを含む最大のテーブルのインデックスは29 GBですが、このインデックスの作成には180 GBの空き領域が必要でした:

システムディスクの空き領域不足を防ぐために、firebird.confで追加の予約領域として別のディスクを指定することができます:

TempDirectories =C:\temp; H:\Temp

最初のディスクに空き領域がない場合、Firebirdは一時ファイル用に2番目のディスクを使用し続けます。

バックアップ用HDD

SATAまたはnSASインターフェースを備えた通常のHDDは、バックアップコピーの作成と保存に適しています。バックアップファイルの高速なシーケンシャル書き込みおよび読み取り操作を保証し、サイズを節約せずに複数のバックアップコピーを保持できるほど安価です。

バックアップコピー用のディスクには常に追加の空き領域を残しておく必要があります: 最新のバックアップコピーのサイズ+ 10%。この場合、新しいバックアップコピーを作成し、バックアッププロセスが正常に完了したことを確認して（このプロセスは数テラバイトのサイズのデータベースでは数時間かかる場合があります）、その後で前のバックアップコピーを削除することができます。

新しいバックアップコピーが作成される前に前のバックアップコピーを削除すると、新しいバックアップコピーが作成されず、古いコピーがすでに削除され、データベースが破損する可能性があります。たとえば、ディスク障害が原因です。

上記で推奨したバックアップ方法（3レベルの増分バックアップと1日1回の検証済みバックアップの組み合わせで最新のコピーのみを1つ保存）を使用する場合は、次の式を使用してバックアップの最小領域を計算します:

Database_size*3+0.2.Database_size

バックアップに必要な領域のサンプル計算を考えてみましょう:

100 GBのデータベースがあり、3レベルの増分バックアップ（週-日-時 - 各1コピー）と1日1回の検証済みバックアップの1コピーを保存するとします。この場合、バックアップコピーは次の領域を占有します:

  • Nbackup_level_0.weekly - 100 GB
  • Nbackup_level_1.daily - 約5 GB
  • Nbackup_level_2.hourly - 約200 MB
  • 日次検証済みバックアップ - 約100 GB
  • さらに、次のバックアップコピーを作成できるように110 GBの予約領域が必要です。

合計 - 316 GB。

! 第1レベル以上の増分ファイルのサイズは、nbackupが最後に実行されてから変更されたページ数によって異なります。これらのファイルのサイズは、データベースの変更量がアプリケーションに依存するため、実験的にのみ決定できます。

もちろん、バックアップ用のスペースを見積もる際には、データベースサイズが異常に増加する可能性を考慮し、それに応じて空き容量を増やすべきです。そうしないと、スペース不足によりバックアッププロセスが予期せず中断される可能性があります。

当然ながら、スマートなバックアップツール（HQbird の FBDataGuard）はバックアップコピー用のスペース不足に気づき、管理者に該当するメッセージを送信します。

データベース用のHDD

SSDは高価すぎる解決策になる場合や、データベースが大きすぎてより安価な方法を使用せざるを得ない場合があります。この場合、SASインターフェースのHDDを使用する必要があります。それが不可能な場合は、nSASインターフェースのSATAディスク、または最も安価なオプションである通常のSATAディスクを使用してください。

ハードディスクの速度（および信頼性 - 後述参照）を向上させるには、RAID10に組み合わせる必要があります。RAID10は、ミラーリング（RAID1）とストライピング（RAID0）のブロックを組み合わせたものです。適切に設定された大容量キャッシュを備えた高性能RAIDコントローラーは、SSDの優れた代替手段となります。

信頼性とRAID

もちろん、上記のすべてのバリアント（一時ファイル専用に割り当てられたディスクを除く）において、ディスクをRAIDに組み合わせることでディスクサブシステムの信頼性を高める必要があります。

• SSDの場合は、RAID1を使用してください - つまり、2つのミラーリングされたディスクに変更が同時に書き込まれ、データを失う可能性が大幅に低くなります。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 があります。キャッシュを高速に動作させる方法は write back です。この場合、変更はキャッシュコントローラーに書き込まれ、しばらくしてから直接ディスクに書き込まれます。

RAIDに付属のメーカーのツールを使用して、バッテリーユニット、キャッシュ、モードを確認できます。

最新のRAIDコントローラーはキャッシュを微調整することもできます - 読み取りまたは書き込みを容易にするように調整できます。通常、読み取りと書き込みで50%/50%に分割されます。

キャッシュを正確に設定する方法を見つけるには、高度なHQbirdディストリビューションパッケージのMON$ Loggerツールを使用することもできます。これは、読み取り操作と書き込み操作の比率（サーバーへの最初の接続時から集計）を表示します：

図 8. HQbird MON$Logger: 読み取り/書き込み比率

ご覧のとおり、この例では書き込み操作よりも読み取り操作の方がはるかに多いため、RAIDコントローラーを読み取り操作80%、書き込み操作20%に設定するのが理にかなっています。

SAN とデータベース

統合ストレージは最近人気が高まっています。これらには、高度なキャッシュ機能を備えた柔軟にカスタマイズ可能なディスクアレイ（すべてのタイプのRAID）が含まれます。通常、SANには複数の入出力コントローラーがあり、複数のサーバーを同時に処理し、かなり高速に動作することが可能です。

多くの組織がSANを購入し、Firebirdデータベースでの作業に使用しています。SANが正しく設定されていれば、優れたパフォーマンスを達成することが可能です。SANを使用する場合は、以下の点を考慮する必要があります：

  1. マルチチャネルデータ交換を提供する複数の高性能ディスクコントローラーが利用可能でなければなりません
  2. 設計上提供されている場合は、バックアップバッテリーユニット（BBU）が存在する必要があります。
  3. データベースディスクはRAID10に組み合わせる必要があります。
  4. キャッシュを有効にし、書き込みモードを write back に切り替える必要があります。
  5. 複数のコンピューターがSANに接続されている場合、それぞれに独自のコントローラーが必要です。
  6. 最新のSANドライバーがインストールされていること。後から提供されたドライバーでパフォーマンスが30%向上したケースに遭遇したことがあります。
  7. SAN上に複数の論理ディスク（データベース用、バックアップコピー用、オペレーティングシステム用）がある場合、それらは異なる入出力チャネルを持ちます。すべてのディスクに1つのチャネルを使用しようとすると、パフォーマンスが低下します。
  8. 同様に、複数のサーバーとデータベースが同時にSANを使用する場合、入出力コントローラーの帯域幅が増加するため、パフォーマンスが低下する可能性があります。
  9. 組み合わせた方法がよく使用されます - オペレーティングシステムと一時ファイルはローカルディスクに保存し、データベースとバックアップファイルはSANに保存します。

多くの場合、SANは「2台のサーバー - 1つのSAN」として、障害に強いクラスターを作成するために使用されます。このようなクラスターは、一方のサーバーのハードウェア障害に関連する問題のみを、即座に2番目のサーバーに切り替えることで解決できることに注意してください。問題がSANまたはデータベース自体に関連する場合、この解決策は役に立ちません。

実際に障害に強いソリューションを構築するには、2つのデータベースインスタンス間でデータをレプリケートするソリューションを使用する必要があります。Firebirdで利用可能なその他のソリューションについては、[email protected] にお問い合わせください。

簡単な結論と推奨事項

Firebirdに関するハードウェアについての結論と推奨事項をまとめましょう。

  1. 多数のユーザーに対応するには、マルチコアCPUを使用する必要があります
  2. 最小RAM容量は、ユーザー数とデータベース構成に基づいて計算され、超過分のRAMはオペレーティングシステムがデータベースファイルのキャッシュに効果的に使用します。
  3. データベース、一時ファイル、バックアップファイルには別々のディスクを使用します
  4. データベースにはむしろSSDを使用します
  5. SSDには少なくとも30%の空き容量を確保します。
  6. データベース専用のディスクを割り当てることをお勧めします。
  7. エンタープライズSSD（書き込み/読み取りサイクルが多い）を使用します。
  8. RAIDを使用することを確認します。
  9. SSDの場合はRAID 1、HDDの場合はRAID10、バックアップ用HDDの場合はRAID1。i. SAS、SATA、nSAS
  10. RAIDバッテリーが存在し、充電されていることを確認します
  11. write back に切り替えられていることを確認します。
  12. 一部のRAIDコントローラーはキャッシュサイズがすでに設定されています。たとえば、読み取り75%、書き込み25%、または50/50などです。したがって、MON$Logger - RAIDパラメータを制御するソフトウェアをインストールし、読み取り/書き込み比率を確認してRAID設定を変更する必要があります。
  13. SANの使用には長所と短所があります。最大限に活用するには、SANを正しく設定する必要があります。
  14. 障害に強いソリューションを構築するには、異なるサーバーで実行されるレプリカを使用したソリューションを使用する必要があります。

連絡先

IBSurgeon/IBase.ru 社は、企業向けの高度なHQbirdディストリビューションパッケージを開発し、Firebirdの複雑なテクニカルサポートを提供し、カスタマイズされたディストリビューションパッケージの開発や、その他の複雑な問題の解決も行っています。

IBSurgeonは、Firebirdデータベースのパフォーマンスを向上させるためのFirebird最適化サービスも提供しています。

お問い合わせ先: [email protected]