問題タブ [kahadb]

db-xx.logがジャーナルファイルで、db.redoが参照ファイルであることを知っていますか？

db-xx.logは、まだ消費されていないメッセージを格納します。これらのメッセージは、消費された後、db-xx.logから削除されます。db.redoは、メッセージID（db-xx.logに保管されている）の参照をメッセージIDで保管します。

1. しかし、db.dataとdb.freeとは何ですか？
2. それらの機能は何ですか？

私の理解では、ブローカーは最初にメッセージをキャッシュ（揮発性メモリ）に保存し、チェックポイントまたはキャッシュサイズがいっぱいになると、それらのメッセージはdb-xx.logに移動（追加）されます。

1. あれは正しいですか？

ありがとう

多数の永続キュー (250) 1000 永続 TextMessages 10 KB で ActiveMQ を使用すると問題が発生します。

シナリオでは、これらのメッセージが消費されるまで、長期間 (数日) にわたってストレージに保持する必要があります (大量のデータが多数のコンシューマーに配布するためにステージングされ、数日間オフラインになる可能性があります)。

Persistence Store がこれらのメッセージでいっぱいになった後、ブローカーの再起動 後、30 秒後に #checkpoint が呼び出されるまで、いくつかのキューを参照/消費できます。

この呼び出しにより、ブローカは使用可能なすべてのメモリを使用し、キューの参照/消費などの他のタスクのためにメモリを解放することはありません。内部的に、MessageCursor はメモリが不足していると判断したようで、ブラウザ/コンシューマへのキュー コンテンツの配信を停止します。

=> 構成によってこの動作を回避する方法はありますか、それともバグですか?

期待されるのは、すべての状況で任意のキューを消費/参照できることです。

以下の設定は現在しばらくの間本番環境にあり、ActiveMQ のドキュメントに記載されているいくつかの推奨事項が適用されています (宛先ポリシー、systemUsage、永続ストア オプションなど)。

• 動作は ActiveMQ: 5.11.2、5.13.0、および 5.5.1 でテストされています。
• メモリ設定: Xmx=1024m
• Java: 1.8 または 1.7
• OS: Windows、MacOS、Linux
• PersistenceAdapter: KahaDB または LevelDB
• ディスク: 十分な空き容量 (200 GB) と物理メモリ (最大 16 GB)。

上記の設定に加えて、ブローカーには次の設定を使用します (ちなみに、memoryLimit を 1mb のような低い値に変更しても状況は変わりません)。

memoryUsage と利用可能なヒープ領域の違いに応じて、 destinationPolicy のcursorMemoryHighWaterMarkを150または600などのより高い値に設定すると、回避策として状況が少し緩和されますが、これは実際には本番システムのオプションではありません。見る。

メモリから決して解放されない ActiveMQTextMessage インスタンスを示す Oracle Mission Control からの情報を含む画面:

http://goo.gl/EjEixV

ActiveMQ KahaDB または LevelDB ストアのディスク容量が徐々に増加していることに気付いた人はいますか?

以下を使用しています：

• Windows Server 2008 SP1 (展開用) および Windows 7 SP1 (開発用)
• Java 1.7
• ActiveMQ 5.11.1 および 5.13.2 (KahaDB と LevelDB の両方を試しました)
• ServiceMix 5.4.0、その Karaf サーバーが Camel ベースの Java アプリケーション Bean をホストし、その ActiveMQ サーバーが未使用
• メッセージ率 = 1 秒あたり 200 個の XML メッセージが着信し、ほぼ同じ量のメッセージが発信されます (Java アプリケーション Bean によって JSON に変換されます)。
• キューの数 = 上記のメッセージを共有する約 50 のキュー。特に 2 つのキューはトラフィックの半分まで処理しています
• すべてのメッセージの設定:
  • 配信の持続性 = false
  • 生存時間 (TTL) = 1 分または 2 分 (最大)

カハDB

KahaDB で ActiveMQ を使用している場合、db*.log ファイルが最初に db-1.log から db-2.log に、次に db-3.log に、古い db* で "leap-frog" するのを見てきました。 .log ファイルは期待どおりにクリーンアップ (削除) されています。それから 10 時間後のある時点で、古い db*.log ファイルのクリーンアップが停止します。新しい db*.log ファイルが表示され、KahaDB は 1 日あたり約 4 GB で拡張し始めます。そして最終的に構成された 50 GB の上限に達すると、サーバーはもちろん動作を停止します。

ごく少数のメッセージが (TTL が与えられているにもかかわらず) 期限切れにならず、通常のクリーンアップがブロックされているようです。古い db*.log ファイルを手動で削除しようとしましたが、これらのファイルがまだ使用されているという警告が表示されてブロックされました。

KahaDB db*.log ファイルは、テキスト エディターで「半読み取り可能」(!) です。つまり、アプリケーション メッセージは認識できますが、実際に何が起こったのかについてはあまりわかりません。

レベルDB

私は最近、ActiveMQ 5.13.2 で LevelDB を使用してみましたが、ストアはまだかなりゆっくりではありますが (1 日あたり約 200 MB) 拡大しているように見えます。

LevelDB データ ストアは圧縮を使用していると思います。ほとんどのファイルはバイナリのように見えるため、適切なリーダー/ブラウザーがないと非常に不透明です。

KahaDB または LevelDB メッセージ ストアの非永続メッセージを読み取り/閲覧するためのツールを見つけた、または実装した人はいますか?

私たちの構成

以下は、私たちのactivemq.xmlが通常どのように見えるかです:

私は、db-*.log ファイルがクリアされない理由を調査する任務を負っています。

大規模な検索で見つけたものから、すべてがメッセージがまだキューにあることを示しています。構成されたすべてのトピックのキューで hawtio を調べましたが、キューのサイズはゼロです。

私の理解では、理論的にはエンキュー サイズとデキュー サイズは同じであるはずですが、そうではありません。私のデキューサイズは0のようです。

トピックを見てきましたが、それらをパージする操作はありません。

kahadb ログが消えるように、すべてのメッセージを消去できるようにしたいと思います。