[
https://issues.apache.org/jira/browse/AMQ-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16740358#comment-16740358
]
Christopher L. Shannon edited comment on AMQ-7132 at 1/11/19 1:00 PM:
----------------------------------------------------------------------
[~alanprot] - nice patch...I initial added these statistics to help with
monitoring store at runtime quickly by keeping these stats in memory but I
wasn't too worried about the recovery speed as most of the brokers I use don't
have index files as large as that so the impact wasn't as noticeable. However
for large stores I can definitely see the issue with recovery and how it would
take quite a while.
Also, there's statistics for durable subscriptions that require iterating over
the order index to recovery message size for each sub which would cause a
performance hit but this feature is turned off by default precisely because of
the potential performance issues with turning it on. I use this feature a lot
but many others who don't care about metrics may not which is why I left it
off. I wonder if this is something else we should add to the index since we
are bumping the version but maybe it isn't worth it because most people
probably don't use it anyways. Looking at it though I do notice that I could
probably rewrite the recovery to only iterate over the order index once topic
(instead of once per subscription)
See
https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L1056
was (Author: christopher.l.shannon):
[~alanprot] - nice patch...I initial added these statistics to help with
monitoring store at runtime quickly by keeping these stats in memory but I
wasn't too worried about the recovery speed as most of the brokers I use don't
have index files as large as that so the impact wasn't as noticeable. However
for large stores I can definitely see the issue with recovery and how it would
take quite a while.
Also, there's statistics for durable subscriptions that require iterating over
the order index to recovery message size for each sub which would cause a
performance hit but this feature is turned off by default precisely because of
the potential performance issues with turning it on. I use this feature a lot
but many others who don't care about metrics may not which is why I left it
off. I wonder if this is something else we should add to the index since we
are bumping the version but maybe it isn't worth it because most people
probably don't use it anyways. Looking at it though I do notice that I could
probably rewrite the recovery to only iterate over the order index once topic
(instead of once per subscription)
> ActiveMQ reads lots of index pages upon startup (after a graceful or
> ungraceful shutdown)
> -----------------------------------------------------------------------------------------
>
> Key: AMQ-7132
> URL: https://issues.apache.org/jira/browse/AMQ-7132
> Project: ActiveMQ
> Issue Type: Test
> Components: KahaDB
> Affects Versions: 5.15.8
> Reporter: Alan Protasio
> Priority: Major
> Fix For: 5.16.0, 5.15.9
>
>
> Hi.
> We noticed that ActiveMQ reads lots of pages in the index file when is
> starting up to recover the destinations statistics:
> [https://github.com/apache/activemq/blob/master/activemq-kahadb-store/src/main/java/org/apache/activemq/store/kahadb/KahaDBStore.java#L819]
> Nowadays, in order to do that, activemq traverse the
> storedDestination.locationIndex to get the messageCount and totalMessageSize
> of each destination. For destinations with lots of messages this process can
> take a while making the startup process take long time.
> In a case of a master-slave broker, this prevent the broker to fast failover
> and does not meet what is stated on
> [http://activemq.apache.org/shared-file-system-master-slave.html.]
> {quote}If you have a SAN or shared file system it can be used to provide
> _high availability_ such that if a broker is killed, another broker can take
> over immediately.
> {quote}
> One solution for this is keep track of the destination statistics summary in
> the index file and doing so, we dont need to read all the locationIndex on
> the start up.
> The code change proposed is backward compatible but need a bump on the kahadb
> version. If this information is not in the index, the broker will fall back
> to the current implementation, which means that the first time people upgrade
> to the new version, it will still have to read the locationIndex, but
> subsequent restarts will be fast.
> This change should have a negligible performance impact during normal
> activemq operation, as this change introduce a few more bytes of data to the
> index and this information will be on checkpoints. Also, this new information
> is synchronized with the locationIndex as they are update at the same
> transaction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
