ActiveMQ - файлы журнала Kahadb не будут очищены
Мне было поручено выяснить, почему файлы журнала db-*. Не очищаются.
Из того, что я обнаружил в результате обширного поиска, все указывает на то, что сообщения все еще находятся в очереди. Я посмотрел hawtio на очереди по всем настроенным темам, и размер очереди равен нулю.
Из моего понимания размер Enqueue и размер Dequeue в теории должны быть одинаковыми, но это не так. Кажется, мой размер Dequeue равен 0.
Я посмотрел на темы, и нет никакой операции, чтобы очистить их.
Я хотел бы иметь возможность очистить все сообщения, чтобы журналы kahadb исчезли.
3 ответа
Я думаю, что вы указываете на одну слабость самого ActiveMQ: он не может гарантировать, что потребители действительно строгие при потреблении сообщений.
У нас аналогичные проблемы с нашим ActiveMQ (5.10.7), потому что кажется, что KahaDB создает "фрагментацию диска", и мы заметили, что это может быть связано как минимум с двумя проблемами с потребителями:
Случай 1: медленный потребитель
В нашей системе есть потребитель, который не может потреблять много сообщений одновременно. если на странице kahaDB остается только одно неиспользованное сообщение, оно сохранит всю страницу целиком (со всеми остальными сообщениями, которые уже использованы и подтверждены). Чтобы предотвратить сохранение хранилища KahaDB до 100% (что замедлит работу производителей), мы передаем сообщения во временную очередь другого экземпляра ActiveMQ, например:
from("activemqPROD:queue:BIG_QUEUE_UNCONSUMED")
.to("activemqTEMP:queue:TEMP_BIG_QUEUE");
затем отталкивая их назад:
from("activemqTEMP:queue:TEMP_BIG_QUEUE")
.to("activemqPROD:queue:BIG_QUEUE_UNCONSUMED");
Альтернативный вариант - сохранить их в файловой системе, а затем перезагрузить, но вы потеряете заголовки JMS (и пользовательские). С решением временной очереди вы сохраняете все заголовки.
Случай 2: Потребитель, который никогда не дает подтверждения
Иногда, даже если мы выполняем предыдущую операцию, даже все неиспользованные очереди пусты, хранилище остается выше 0%. Просматривая файл KahaDB, мы видим, что все еще присутствуют страницы с событиями, больше нет сообщений во всех QUEUES. Для ТЕМ мы перестали использовать долговременные подписки, тогда хранилище также должно оставаться на уровне 0%.
Потенциальная причина (это предположение, но с большой уверенностью) заключается в том, что некоторые из использованных сообщений никогда не были acknowledged должным образом. Причина, по которой мы думаем, что это причина, заключается в том, что в журналах мы все еще можем видеть сообщения
"not removing data file: 12345 as contained ack(s) refer to referenced file: [12344, 12345]"
Это может произойти, например, когда потребитель прерывает соединение (он потребляет некоторые сообщения, но отключается перед отправкой ack)
В нашем случае сообщения никогда не истекает, то это также может быть потенциальной проблемой для этого случая. Однако неясно, может ли установка срока действия уничтожить "непроверенные" сообщения. Поскольку мы не хотим потерять какое-либо событие, у этих конкретных очередей нет срока действия.
По вашему вопросу, похоже, вы во втором случае, тогда наше решение:
- Убедитесь, что больше никто не подключается к ActiveMQ.
- Убедитесь, что все очереди и длительные темы пусты
- Удалить все файлы в хранилище KahaDB (из файловой системы)
- Перезапустите ActiveMQ (свежий)
К сожалению, мы не нашли лучшего способа справиться с этими случаями, если у кого-то еще есть лучшая альтернатива, мы будем рады узнать это.
Эта статья также может дать вам решение (например, установить политику истечения срока действия для очереди ActiveMQ.DLQ).
Добавьте эту конфигурацию журнала в log4j.properties. Тогда вы можете увидеть, что именно содержит файлы kahadb в kahadb.log.
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
В качестве альтернативы: как только вы выяснили, какая очередь вызывает существование журнала, вы можете сопоставить его с собственной KahaDB, как описано здесь http://activemq.apache.org/kahadb.html