Alexey Kovyazin，2014年7月14日

正如您从我们之前的文章中所记得的，我们调查了关于Firebird性能下降的传言（/zh/articles/firebird-performance-degradation-tests-myths-and-truth/），其中我们创建了几个从9Gb到30Gb的数据库，还测试了非常大的Firebird数据库（1.7 TB）(/zh/articles/more-details-about-1-7-terabyte-firebird-sql-database/）。

所有测试都在相同的硬件上进行，这是一种低预算配置：CPU AMD-FX8350，内存16GB，SATA软件RAID1 2x4Tb希捷硬盘，操作系统Windows Server 2008R2（2008R2为64位），并使用相同的Firebird配置：Firebird 2.5.2 64位，SuperServer，增加了页面缓冲区和TempCacheSize。您可以从此位置免费下载此SuperServer配置文件：/zh/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 TB数据库的性能标记–数据库大小增长了60倍（从30Gb到1813Gb），性能损失为2.4倍（从407分降至169分）。

那么，问题是：我们能否通过配置调优在相同硬件上提高Firebird性能？

答案是：能！

为FirebirdSQL注入动力

如您所记得的，在此测试中我们运行了20个并发连接，执行密集的INSERT操作和较不密集的UPDATE操作。

所有SELECT都是简短且定义明确的，具有有效的SQL执行计划，因此这是一个典型的OLTP（在线事务处理）应用程序。对于此类应用程序，性能最关键的是并行处理。Firebird SuperServer 2.5.2不太适合多线程处理–它每个数据库仅有效使用1个核心，这一事实使得SuperServer对于OLTP应用程序来说不是很好的选择。

因此，我们需要将Firebird架构更改为Classic或SuperClassic，它们支持多线程处理并利用CPU的多个核心（AMD-FX8350 CPU中有8个核心）。

然后，需要进行一些调优，因为Firebird的默认配置对我们的测试系统来说不是最优的。

firebird.conf中的调优参数

页面缓存

因此，为了提高OLTP性能，我们决定尝试Classic和SuperClassic架构。Classic和SuperClassic的关键参数之一是缓存中的页面缓冲区数量。与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和其他资源方面代价高昂，因为它是通过内存重映射执行的。因此我们将其设置为7Mb，以节省一些时间和CPU资源。

测试运行

我们使用不同的页面缓存值进行了多次测试运行，结果如下：

页面缓冲区	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 TB数据库的测试结果

您可以看到最佳性能（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配置文件集：/zh/optimized-firebird-configuration/

欢迎随时提问：[email protected]

下一步是什么？

我们正在开展一项全面测试，将比较Firebird 2.5和Firebird 3.0的性能，模拟真实世界的负载和大量连接。敬请期待！