Alexey Kovyazin、2014年7月14日

以前の記事でお伝えしたように、私たちはFirebirdのパフォーマンス低下に関する神話を調査しました（ /ja/articles/firebird-performance-degradation-tests-myths-and-truth/）。そこでは9Gbから30Gbまでの複数のデータベースを作成し、さらに非常に大きなFirebirdデータベース（1.7テラバイト）もテストしました（(/ja/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構成ファイルは、以下の場所から無料でダウンロードできます： /ja/optimized-firebird-configuration/

その結果、データベースのパフォーマンスは次のような状況になりました：

![Firebirdパフォーマンス 1813Gb（1.7Tb）](/images/performance/perf7_performance_with 1800Gb_Firebird_database.png)

図1. 9Gbから30Gb、および1.7Tbまでのパフォーマンス低下

ポイント#11は30Gbデータベースのパフォーマンスマークで、#12は1.7テラバイトデータベースのものです - データベースサイズは60倍（30Gbから1813Gbへ）に成長し、パフォーマンス損失は2.4倍（407から169ポイントへ）でした。

では、同じハードウェアで構成チューニングによってFirebirdのパフォーマンスを向上させることができるでしょうか？

その答えは：はい！

FirebirdSQLのスーパーチャージ

ご存知のとおり、このテストでは20の同時接続を実行し、集中的なINSERTと、それほど集中的ではないUPDATEを実行しました。

すべての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の主要なパラメータの1つは、キャッシュ内のページバッファ数です。SuperServerとは異なり、ClassicおよびSuperClassicは接続ごとにページキャッシュを割り当てます。

2.5のFirebirdアーキテクチャの詳細については、この表を確認できます：http://www.firebirdsql.org/file/fb25.architecture_comparison.pdf

異なるFirebirdアーキテクチャのページキャッシュメモリ使用量を計算する簡単な式があります：

1. SuperServer - データベースごとに単一のページキャッシュ。デフォルトのページキャッシュサイズは2048ページで、一般的な推奨は10000バッファです。私たちの場合、キャッシュは16k（ページサイズ）x 10000 ~= 160Mbでした。これはすべての接続に対してです。
1. 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データベースで得られた結果に近いものです！

結果は次のグラフで確認するのが良いでしょう：

Firebirdパフォーマンス 1813Gb（1.7Tb）

図2. 1.7テラバイトデータベースのテスト結果

ClassicとSuperClassicの両方で最高のパフォーマンスは接続あたり1500ページのときであることがわかります。つまり、接続あたりのページキャッシュサイズは：

1500x16k ~= 23,4Mb

接続あたり2000ページではパフォーマンスが大幅に低下しました。1500〜2000ページあたりのどこかで、キャッシュの利点が、各サーバープロセスのキャッシュ内のページを同期するためのプロセス間のロックテーブル相互作用によるオーバーヘッドよりも小さくなったようです。明らかに、接続数が多いほどこれは早く発生するため、Classic/SuperClassicサーバーは通常256〜512ページのような数値で構成されます。

また、Classicのパフォーマンスは768〜1000ページキャッシュあたりで低下しています - なぜこれが発生したのかはわかりません。

まとめ

私たちの実験は、Firebirdアーキテクチャ（SuperServer、Classic、SuperClassic）の正しい選択と、特定のアーキテクチャに適したいくつかの重要なパラメータの適切なチューニングによって、Firebirdのパフォーマンスを向上させることができることを確認しています。

その結果、巨大な1.7 TbのFirebird SQLデータベースは、ローエンドのハードウェアでも十分なパフォーマンスで動作させることができます。これらのテストの実用的な成果として、すべてのFirebirdバージョンとすべてのアーキテクチャ向けの複数の構成ファイルを作成しました。もちろん、これらは特定のアプリケーションやハードウェアに合わせてチューニングされているわけではありませんが、非常に控えめな負荷向けに作られたデフォルトの構成ファイルよりは優れています。

最適化されたFirebird構成ファイルの完全なセット： /ja/optimized-firebird-configuration/

ご質問があればお気軽にどうぞ： [email protected]

次は？

私たちは、Firebird 2.5とFirebird 3.0のパフォーマンスを比較する包括的なテストに取り組んでいます。実世界の負荷シミュレーションと多数の接続を使用します。お楽しみに！