Firebird性能下降：测试、误区与真相
Alexey Kovyazin，2014年5月16日
您可以以PDF格式下载本文。
最近，我们在IBSurgeon中对Firebird 2.5.2进行了一系列性能测试。Firebird 2.5.2是最流行的Firebird数据库版本，其用户经常遇到与Firebird性能相关的问题。
关于数据库性能，最重要的关注点之一是其性能退化。许多用户声称，当数据库达到某个阈值时，他们的应用程序会出现性能问题：这个阈值可能是3GB、5GB、RAM大小、20GB等。最常见的说法是“数据库大小超过RAM大小”：当Firebird数据库大小达到RAM大小时，据说会变得非常慢……这是真的吗？
我们决定进行一系列测试，以验证是否存在与数据库增长相关的性能退化。我们决定在相同硬件上模拟数据库的长期增长，并使用相同负载运行了11个测试，数据库大小介于9GB到30GB之间：
图1. 测试用数据库大小
测试硬件和Firebird配置
测试硬件具有以下关键特性：
CPU AMD-FX8350，内存16GB，SATA软件RAID1 2x4Tb希捷硬盘，操作系统Windows Server 2008R2（2008R2为64位）。
如您所见，这是一个低端硬件配置；截至当时（2014年5月）购买成本不到1000美元，可视为典型的低端配置–可能除了大容量SATA硬盘之外，但根据制造商报告，1TB和4TB SATA硬盘的速度几乎相同。
由于测试目标是衡量典型系统的性能变化，我们使用了Firebird（64位）SuperServer架构，而非Classic，以完全模拟小公司的情况–他们使用最初安装的版本多年。如您所知，SuperServer仅使用1个CPU核心，因此Classic或SuperClassic（可使用所有CPU核心）可能在性能方面表现更好，但我们的目标不是性能调优。
不过，我们调整了firebird.conf，采用了我们推荐给所有Firebird SuperServer安装的明显更改：将页面缓冲区增加到10000，并增加了排序临时空间。
所有测试数据库均以16384的页面大小创建，以保持一致性。
测试
加载
每个测试包含2个步骤：加载和模拟20个终端执行插入、更新和删除操作。
加载步骤由加载应用程序（load.exe）执行，它将数据插入多个表中。如图2所示，数据以不同速度加载；速度从约35MB/秒到1MB/秒不等。
图2. 数据库加载速度（红色曲线）
这与加载应用程序的设计有关，而非Firebird：加载程序快速插入数据库的70%，然后缓慢填充其余数据，所有大小的数据库均重复此过程。对我们来说重要的是加载程序执行相同的操作，因此我们可以使用其平均速度来衡量加载速度。
需要说明的是，加载程序仅插入数据，索引在加载完成后创建。
让我们查看11个9至30GB数据库加载步骤的结果表：
| # | 数据库大小，GB | 加载时间，秒 | SATA加载速度，MB/秒 |
|---|---|---|---|
| 1 | 9.04 | 2535 | 3.65166075 |
| 2 | 10.80 | 3197 | 3.45924304 |
| 3 | 13.00 | 4057 | 3.281242297 |
| 4 | 15.50 | 4698 | 3.378458919 |
| 5 | 17.30 | 5455 | 3.24751604 |
| 6 | 19.90 | 6037 | 3.375451383 |
| 7 | 21.60 | 6473 | 3.417024564 |
| 8 | 24.20 | 7539 | 3.287014193 |
| 9 | 26.00 | 7779 | 3.422547885 |
| 10 | 28.60 | 8851 | 3.308823862 |
| 11 | 30.30 | 9266 | 3.348499892 |
图3. 加载时间和速度
或者，最好以图4中的图形显示：
图4. 测试结果：加载速度。
如您所见，曲线相当稳定，加载过程的平均速度在3.3-3.4MB/秒左右波动。当数据库大小超过RAM大小后（从第5个数据库开始，大小为17.3GB），也没有加载速度下降的迹象。
性能
加载时间看起来很有希望，那么实际性能结果如何呢？
在查看性能结果之前，让我们快速回顾一下模拟过程。
模拟运行20个线程，每个线程随机执行若干业务操作：创建新订单、处理付款、统计库存产品数量、处理订单交付等（详细信息可查看实际存储过程的SQL文本）。如您所见，这是抽象库存/销售应用程序的常规业务操作集。
测试应用程序测量每秒业务操作数，并报告平均值。当然，这个数字是人为参数，但足以进行比较。
性能测试结果：
| # | 数据库大小，GB | SATA性能 |
|---|---|---|
| 1 | 9.04 | 494.73 |
| 2 | 10.80 | 491.94 |
| 3 | 13.00 | 480.36 |
| 4 | 15.50 | 469.11 |
| 5 | 17.30 | 446.42 |
| 6 | 19.90 | 431.61 |
| 7 | 21.60 | 426.85 |
| 8 | 24.20 | 424.5 |
| 9 | 26.00 | 414.04 |
| 10 | 28.60 | 409.14 |
| 11 | 30.30 | 407.97 |
图5. 性能测试结果表。
或者，以图形方式查看结果更好：
图6. 性能结果图
如您所见，随着数据库大小的增长，性能缓慢下降–数据库越大，运行越慢（在相同硬件上）。当数据库大小超过RAM时，也没有明显的性能骤降。数据库从9GB增长到30GB导致约20%的性能损失。
30GB的Firebird数据库如今随处可见，并且会随着时间的推移不断增长。然而，当数据库变得更大时会发生什么？我们指的是–更大！当数据库变得真正巨大时，性能会发生什么变化？
Mr.Big
为了回答这个问题，我们决定查看测试表的末尾，并在相同硬件、相同设置下对1.7TB（1813GB）数据库进行测试。
加载
因此，我们创建了这样一个数据库：
图7. 数据库大小–现在为1813GB
加载耗时566448秒–157小时，6.55天。这很长，但平均加载速度是……3.28MB/秒！
| # | 数据库大小，GB | 加载时间，秒 | SATA加载速度，MB/秒 |
|---|---|---|---|
| 12 | 1813.969025 | 566448 | 3.279214122 |
图8. 1.7TB Firebird数据库的加载时间和速度
在图上看起来非常好：最后一个点（#12）。因此，Firebird的插入算法表现出色。
图9. 加载速度–第12个点对应1.7TB Firebird数据库
Mr.Big的性能
然后我们运行了相同的性能测试–第12行对应1.7TB数据库。
| # | 数据库大小，GB | SATA性能 |
|---|---|---|
| 1 | 9.04 | 494.73 |
| 2 | 10.80 | 491.94 |
| 3 | 13.00 | 480.36 |
| 4 | 15.50 | 469.11 |
| 5 | 17.30 | 446.42 |
| 6 | 19.90 | 431.61 |
| 7 | 21.60 | 426.85 |
| 8 | 24.20 | 424.5 |
| 9 | 26.00 | 414.04 |
| 10 | 28.60 | 409.14 |
| 11 | 30.30 | 407.97 |
| 12 | 1813.969025 | 169.33 |
图10. 性能测试结果–第12行对应1.7TB数据库
在图表上：
图 11. 性能，第 12 点对应 1.7Tb 数据库
结果证实，Firebird 存在缓慢且稳定的性能下降–当数据库大小增长了 60 倍（从 30Gb 到 1813Gb）时，性能损失为 2.4 倍（从 407 点降至 169 点）。
数据库（在相同的低端硬件上）从 30Gb 增长到 1.7Tb 并不常见，但 Firebird 即使在这种情况也能正常工作。
大型数据库详解
为了更好地理解 1.7Tb 数据库，我们收集了 Mr.Big 数据库的统计信息，并在 IBAnalyst 中进行了分析：
图 12. 1.7Tb 数据库在 IBAnalyst 中的表
如您所见，有两个大表–ORDER_LINE（约 600 Gb）包含 63 亿条记录，以及 STOCK（约 680 Gb）包含 21 亿条记录。
并且，这些表有两个深度为 4 的索引–这意味着每次请求在读取实际数据之前需要读取 4 次索引页。ORDER_LINE_PK 索引大小为 50Gb。
图 13. Firebird 1.7Tb 数据库的索引
尽管记录数量庞大，数据库统计信息看起来良好，因此 Firebird 即使在低端硬件上处理大型数据库也能表现出相当不错的结果，这并不令人意外。
使用 SSD 驱动器测试 Firebird
在低端硬件上完成一系列 Firebird 测试后，我们决定检查数据存储技术另一端的结果，并在同一台服务器上安装了 SSD 驱动器。
我们安装了 Plextor PX-256M M5 Pro SSD 驱动器，并使用相同的设置运行了相同的测试系列（除 1.7Tb 数据库外）。结果已添加到带有 SATA 设备的图表中，请参见下文。
加载
如您所见，SSD 上的加载时间与 SATA 相同。这是预期结果：SATA 和 SSD 驱动器上的顺序写入操作速度几乎相同。
图 14. SSD 和 SATA 上的加载
性能
请查看性能结果：
图 15. SSD 和 SATA 上的性能
如您所见，随机 IO 操作的性能在 SSD 驱动器上显示出约 8 倍的更好结果。我们从客户数据库的经验中知道，SSD 在实际应用中快 30-50%，但 8 倍的提升非常高。
然而，此测试是人为设计的，专门用于模拟高负载 OLTP 操作，包含大量更新/删除，但没有大量数据提取。通常的数据库应用程序不会一直以这种模式运行。这解释了为什么 SSD 在这种特定情况下表现出如此高的结果。
总结
那么，我们从这些测试中学到了什么？
首先–Firebird 的性能不会因某些大小限制而大幅下降。在相同硬件上，性能会随着数据库大小的增长而缓慢下降。这种性能下降可以通过调整 Firebird 配置或智能硬件升级来补偿。
值得一提的是，IBSurgeon 提供 Firebird 性能优化服务–利用我们从此类测试中收集的实验数据，我们可以显著提高 Firebird 和 InterBase 数据库的性能。
其次，我们了解到即使非常大的 Firebird 数据库（1.7 TB）也能在低端硬件上运行，虽然性能损失显著，但仍在可接受范围内。
第三，SSD 确实非常适合 OLTP 应用程序。这可能是目前升级数据库性能最经济的方式。当然，使用 SSD 不会解决糟糕的查询计划和无效索引的问题，但它可以整体提升性能。