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

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的将ActiveMQ持久消息传递性能提高25倍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。