為什麼清理後 KahaDB 日誌檔仍然存在

未被參照的 KahaDB 日誌檔 data-<id>.log 的清理預設每 30 秒執行一次。如果資料檔正在使用中，則不會被清理。

資料檔可能正在使用中，因為

它包含目的地或持久主題訂閱的待處理訊息
它包含一個正在使用中的資料檔中的訊息的 ACK - 無法刪除 ACK，因為恢復時會將訊息標記為重新傳遞
日誌參照待處理的交易
它是一個日誌檔，可能會有待處理的寫入

org.apache.activemq.store.kahadb.MessageDatabase 類的 TRACE 級別記錄，可以深入了解清理過程，並允許您確定為什麼特定的資料檔被視為正在使用中，因此不是清理的候選。

要進行除錯，請將以下內容（或類似內容）新增至您的 log4j.properties 檔案（如果需要）

log4j.appender.kahadb=org.apache.log4j.RollingFileAppender log4j.appender.kahadb.file=${activemq.base}/data/kahadb.log log4j.appender.kahadb.maxFileSize=1024KB log4j.appender.kahadb.maxBackupIndex=5 log4j.appender.kahadb.append=true log4j.appender.kahadb.layout=org.apache.log4j.PatternLayout log4j.appender.kahadb.layout.ConversionPattern=%d [%-15.15t] %-5p %-30.30c{1} - %m%n log4j.logger.org.apache.activemq.store.kahadb.MessageDatabase=TRACE, kahadb

重新啟動 ActiveMQ Classic 並讓清理程序執行（例如，給它一兩分鐘），或者通過 JMX 將此記錄配置應用於正在執行的訊息代理。 Broker MBean 在 JMX 中公開一個名為 reloadLog4jProperties 的操作，可用於告訴訊息代理重新載入其 log4j.properties。通常，應用此記錄配置 2-5 分鐘，然後分析訊息代理的日誌檔就足夠了。

檢查日誌檔並查找資料檔的清理。該過程從已知的完整資料檔集開始，並按每個目的地的基礎查詢索引以修剪此列表。剩下的任何內容都是清理的候選。追蹤記錄給出了目的地和日誌檔編號，這些編號在它遍歷索引時仍然是刪除的候選。

在某些時候，您會遇到一個目的地，並且資料檔 ID 的數量會突然下降，因為該目的地會參照它們。它可能是 DLQ 或離線持久訂閱者。在任何情況下，記錄都將幫助您精確定位佔用磁碟空間的目的地。

這是一個快速範例

TRACE	上次更新：164:41712，完整 gc 候選集：[86, 87, 163, 164]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	第一次交易後 gc 候選：164:41712，[86, 87, 163]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:A 之後 gc 候選，[86, 87, 163]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：1:B 之後 gc 候選，[86, 87, 163]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:D 之後 gc 候選，[86, 87, 163]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:E 之後 gc 候選，[86, 87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:H 之後 gc 候選，[86, 87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:I 之後 gc 候選，[86, 87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	目的地：0:J 之後 gc 候選，[87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
TRACE	gc 候選：[87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒
DEBUG	清理正在移除的資料檔：[87]	org.apache.activemq.store.kahadb.MessageDatabase	ActiveMQ 日誌檢查點工作執行緒

我們從現有的日誌資料檔集 [86, 87, 163, 164] 中取得一個候選，data-87.log。目前有一個交易正在使用 164，目的地（名為 E 的佇列）'**0:E**' 在 163 中有一些訊息，目的地 '**0:I**' 在 86 中有訊息，而 87 未被參照。在這種情況下，目的地 '**0:I**' 上肯定有一些長期未確認的訊息或速度非常慢的消費者。

前綴 '**0:**' 是佇列的簡寫，'**1:**' 是主題的簡寫。範例：dest:1:B 指的是名為 B 的主題。

非持久性訊息

對於未儲存在您設定的 KahaDB 持久性介面卡中，但一旦超過訊息代理設定的 memoryUsage 限制就會交換到暫存儲存的非持久性訊息也類似。類似的記錄配置可以顯示暫存儲存清理的詳細資訊。

請注意，以上記錄配置的最後一行會停用 KahaDB 清理工作的詳細記錄。如果刪除該行，KahaDB 和暫存儲存的清理詳細資訊將記錄到同一個檔案中，但您需要小心不要混合記錄輸出。