将ActiveMQ持久消息传递性能提高25倍

Apache ActiveMQ，JBoss A-MQ和Red Hat

Apache ActiveMQ是一个非常受欢迎的开源消息传递代理，由创建（和工作） Apache Karaf ， Apache Camel ， Apache ServiceMix以及许多其他工具的人提供给您。它拥有一个充满活力的社区，非常灵活，可以部署在高性能和高可用性的场景中。

在Red Hat （我工作的地方），我们支持一种名为JBoss A-MQ的产品，该产品是生产增强，受企业支持的，完全开源的上游ActiveMQ项目版本。红帽完全致力于开源，而我们所有的产品都是开源的（不属于这种开放式核心技术）。我们的客户（特别是使用JBoss A-MQ的客户）在各自领域中名列前茅（零售/ e-零售，政府，航运，医疗服务提供商，金融，电信等），并在非常关键的情况下部署JBoss A-MQ。

由于JBoss A-MQ代码库来自上游ActiveMQ社区，并且我们在Red Hat方面所做的所有错误修复和增强功能都重新融入了社区中，因此，我想与您分享我们最近贡献的增强功能将我们的用例在知名客户上的速度提高了25倍，并且还可能对您的用例有所帮助。已提交的补丁程序位于master分支中，直到5.12社区发行版才可用（尽管比JBoss A-MQ 6.1的补丁程序更早提供，希望本周末或下周初可用）。，尽管我鼓励您每晚检出5.12版SNAPSHOT以早日尝试（夜间快照可以在这里找到）。

我们的问题...

为了设置上下文，我们正在谈论通过代理的持久消息传递。这意味着，在消息已安全存储到持久性存储之前，代理将不承担消息的责任。在这一点上，由经纪人将消息传递给消费者，并且在消费者确认了消息的责任之前，不应丢失消息。

ActiveMQ文档描述了这样的流程：

但是，为了确保消息不会丢失，我们必须假定消息传递存储库具有高可用性。在本文其余部分描述的情况下，我们使用KahaDB Persistence Adapter ，这是开箱即用提供的默认持久性适配器。我们需要将kahadb数据库文件存储在高度可用的存储设备（NAS，SAN等）上。第二个要求是，当我们将消息写入文件系统时，我们必须将数据同步到磁盘（aka，刷新应用程序，操作系统，网络和硬件之间的所有缓冲区），以便可以确保磁盘不会丢失数据。您可以通过不与磁盘同步并允许OS缓冲写操作来获得非常快的“持久性”的折衷，但这会导致失败时丢失消息的可能性。

但是回到我们的故事：在我们的用例中，我们在带有RHEL 6.5的块存储设备上使用了GFS2文件系统。当ActiveMQ将消息写入数据库时，它将要求OS文件描述符“同步”，以便将所有内容安全地存储在磁盘上，并将阻塞写入线程，直到完成为止（还有更多操作正在进行，但是将简化一秒钟）。这种同步非常昂贵，我们注意到它甚至更慢，因为在每次调用时都正在同步数据和同步元数据。（所有这些都在一定程度上因操作系统，文件系统等而异……对于这种特定情况，我们正在谈论RHEL 6.5和GFS2）。

在我们的用例中，我们决定不需要在所有同步调用上都同步元数据，只有操作系统认为必要的那些元数据才能保持一致性。因此，ActiveMQ中有一个未记录的功能（提醒我记录此功能），您可以将其配置为在每个同步调用中不强制元数据同步，并委派给操作系统。为此，请在启动时将此标志传递给JVM：

-Dorg.apache.activemq.kahaDB.files.skipMetadataUpdate=true

这将使操作系统可以决定是否同步元数据。对于某些用例，这可以加快写入磁盘的速度，然后同步数据。

但是，在我们的用例中，事实并非如此。我们每秒收到约76条消息，这对我来说没有通过气味测试。

带有ActiveMQ的DiskBenchmark

因此，我们抽出了一个鲜为人知的磁盘基准测试工具，它与ActiveMQ一起提供（请注意。它进行测试以查看其可以从基础文件系统写入/读取的速度。由于ActiveMQ也是用Java编写的，因此在这种情况下很有用，该DiskBenchmark将使用Java API来完成此任务。因此，您可以将它用作写入速度的一个数据点。您还可以执行其他系统级别的测试来测试存储/文件系统设置的各个部分，但是我很烦恼-这篇文章已经太长了。

要运行磁盘基准测试，请导航到ActiveMQ安装目录并运行以下命令：

java -classpath "lib/*" \
org.apache.activemq.store.kahadb.disk.util.DiskBenchmark

这将运行一个基准并吐出结果。考虑到硬件，我们在这种情况下的结果看起来不错

Benchmarking: /mnt/gfs2/disk-benchmark.dat
Writes:                                                                                                          639996 writes of size 4096 written in 10.569 seconds.                                                          60554.074 writes/second.                                                                                       236.53935 megs/second.                                                                                         Sync Writes:                                                                                                     23720 writes of size 4096 written in 10.001 seconds.                                                           2371.763 writes/second.                                                                                        9.264699 megs/second.                                                                                          Reads:                                                                                                           3738602 reads of size 4096 read in 10.001 seconds.                                                             373822.8 writes/second.                                                                                        1460.2454 megs/second.

将块大小增加到4MB（这是ActiveMQ的默认最大块大小）：

java -classpath "lib/*" \
org.apache.activemq.store.kahadb.disk.util.DiskBenchmark \
--bs=4194304Benchmarking: /mnt/gfs2/disk-benchmark.dat
Writes:                                                                                                          621 writes of size 4194304 written in 10.235 seconds.                                                          60.674156 writes/second.                                                                                       242.69662 megs/second.                                                                                         Sync Writes:                                                                                                     561 writes of size 4194304 written in 10.017 seconds.                                                          56.00479 writes/second.                                                                                        224.01917 megs/second.                                                                                         Reads:                                                                                                           2280 reads of size 4194304 read in 10.004 seconds.                                                             227.90884 writes/second.                                                                                       911.6354 megs/second.

那些9.x megs / sec和224.x megs / sec的同步写入并没有达到我们的76 msg / s，因此我们进行了更深入的研究。

非常感谢Red Hat的存储团队的Robert Peterson。。。在筛选strace并依靠Bob对文件系统/存储的了解之后，我们能够看到，由于文件大小随着每次写入而不断增长，因此操作系统确实也会同步元数据，因此不会使用该JVM标志加快写入速度以跳过元数据更新。鲍勃建议我们预分配要写入的文件，然后让我大吃一惊.. duh ..这就是Disk Benchmark实用程序正在做的事情！

因此，在编写了用于预分配日志文件的补丁程序之后，我们看到性能数字从76 TPS上升到大约2000 TPS。我在其他文件系统上进行了一些快速测试，似乎在那里产生了显着影响，尽管我不能肯定地说，如果不进行更全面的基准测试。

因此，现在有了该补丁，我们可以将KahaDB配置为“预分配”日志文件。开箱即用，它将文件预分配为稀疏文件。此类文件可能不足或不足以满足您的调优需求，因此请首先试用。对于我们来说，这还不够—我们需要预分配块/结构，因此我们使用零进行了预分配：

<kahaDB directory="/mnt/gfs2/kahadb" \
enableJournalDiskSyncs="true" preallocationStrategy="zeros" />

这使我们能够进行数据的同步/同步，并保存元数据更新，并减少了必须分配这些块的文件系统负载。这导致性能显着提高。

注意，有三种预分配策略：

sprase_file默认，开箱即用
zeros -ActiveMQ通过将零（0×00）写入这些块来预分配文件
os_kernel_copy — ActiveMQ将分配委托给操作系统

测试哪个更适合您。我还在制作一个补丁，以批量或整个文件方式进行预分配。

请参阅文档以获取有关KahaDB和预分配的更多信息

最终结果

经过一些快速的场景测试之后，我注意到用于此特定用例的不同文件系统的性能有所提高。当然，您的测试/硬件/场景/ OS /网络/配置/文件系统等可能与此测试中使用的有所不同，因此在开始将产品投入生产之前，请先询问计算机。尽管如此，我们在较新的，令人兴奋的硬件上针对该用例的数量：

| strategy         |Local storage | GFS2     | NFSv4
|------------------|--------------|----------|---------
| `sparse_file`    | 64 m/s       | 76 m/s   | 522 m/s |
| `zeros`          | 163 m/s      | 2072 m/s | 613 m/s |
| `os_kernel_copy` | 162 m/s      | BUG      | 623 m/s |------------------------------------------------------

注意！！！！

只需注意，对于os_kernel_copy选项，如果在RHEL 6.x / 7.x上运行并使用GFS2，它可能会失败，因此请远离该选项，直到修复内核错误为止：）

翻译自: https://www.javacodegeeks.com/2015/03/speeding-up-activemq-persistent-messaging-performance-by-25x.html