You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by neillott <ne...@yahoo.com> on 2009/12/01 17:56:29 UTC
Slow KahaDB access
Hi,
I know this question was posted earlier, but can anyone help here?
http://old.nabble.com/slow-KahaDB-access-td26172918.html#a26216649
I'm seeing this in my activemq log:
2009-12-01 09:29:08,690 | INFO | Slow KahaDB access: cleanup took 9789 |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
Checkpoint Worker
2009-12-01 09:30:36,376 | INFO | Slow KahaDB access: cleanup took 1298 |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
Checkpoint Worker
2009-12-01 09:47:18,871 | INFO | Slow KahaDB access: cleanup took 14058 |
org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
Checkpoint Worker
When I benchmark the box I'm seeing this:
[myserver] /usr/local/neil/activemq > java -classpath lib/kahadb-5.3.0.jar
org.apache.kahadb.util.DiskBenchmark
Benchmarking: /usr/local/neil/activemq/disk-benchmark.dat
Writes:
128000 writes of size 4096 written in 18.521 seconds.
6911.0737 writes/second.
26.996382 megs/second.
Sync Writes:
57936 writes of size 4096 written in 10.001 seconds.
5793.0205 writes/second.
22.628986 megs/second.
Reads:
1960651 reads of size 4096 read in 10.001 seconds.
196045.5 writes/second.
765.80273 megs/second.
What exactly do I need to do to get rid of the slow kahadb access messages?
Thanks,
Neil
--
View this message in context: http://old.nabble.com/Slow-KahaDB-access-tp26594249p26594249.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Slow KahaDB access
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi,
FWIW, I just documented how to configure the threshold on which the message
will be logged
http://cwiki.apache.org/confluence/display/ACTIVEMQ/KahaDB#KahaDB-SlowKahaDBaccesslogmessages
Cheers
--
Dejan Bosanac - http://twitter.com/dejanb
Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Tue, Dec 1, 2009 at 5:56 PM, neillott <ne...@yahoo.com> wrote:
>
> Hi,
>
> I know this question was posted earlier, but can anyone help here?
>
> http://old.nabble.com/slow-KahaDB-access-td26172918.html#a26216649
>
> I'm seeing this in my activemq log:
>
> 2009-12-01 09:29:08,690 | INFO | Slow KahaDB access: cleanup took 9789 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
> 2009-12-01 09:30:36,376 | INFO | Slow KahaDB access: cleanup took 1298 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
> 2009-12-01 09:47:18,871 | INFO | Slow KahaDB access: cleanup took 14058 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
>
> When I benchmark the box I'm seeing this:
>
> [myserver] /usr/local/neil/activemq > java -classpath lib/kahadb-5.3.0.jar
> org.apache.kahadb.util.DiskBenchmark
> Benchmarking: /usr/local/neil/activemq/disk-benchmark.dat
> Writes:
> 128000 writes of size 4096 written in 18.521 seconds.
> 6911.0737 writes/second.
> 26.996382 megs/second.
>
> Sync Writes:
> 57936 writes of size 4096 written in 10.001 seconds.
> 5793.0205 writes/second.
> 22.628986 megs/second.
>
> Reads:
> 1960651 reads of size 4096 read in 10.001 seconds.
> 196045.5 writes/second.
> 765.80273 megs/second.
>
>
> What exactly do I need to do to get rid of the slow kahadb access messages?
>
> Thanks,
>
> Neil
> --
> View this message in context:
> http://old.nabble.com/Slow-KahaDB-access-tp26594249p26594249.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
Re: Slow KahaDB access
Posted by neillott <ne...@yahoo.com>.
>Are you noticing delays in producers or consumers or just a little worried
>about the INFO message?
My main concern was about the message. I haven't seen any delays.
--
View this message in context: http://old.nabble.com/Slow-KahaDB-access-tp26594249p26617441.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Slow KahaDB access
Posted by Gary Tully <ga...@gmail.com>.
If your message volume is such that all message reference can reside in
memory and your consumers can keep up with your producers then there is no
need for persistence. If you want to be able to spool/cursor message
references to disk when memory is exhausted, then persistence is necessary.
2009/12/3 neillott <ne...@yahoo.com>
>
> Thanks for the clarification.
>
> Then my next question is what is the advantage to having persistence turned
> on for a broker in activemq if none of the topics or queues are durable and
> the producers of messages are not asking for delivery persistence and all
> the messages are asynchronous.
> --
> View this message in context:
> http://old.nabble.com/Slow-KahaDB-access-tp26594249p26629348.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: Slow KahaDB access
Posted by neillott <ne...@yahoo.com>.
Thanks for the clarification.
Then my next question is what is the advantage to having persistence turned
on for a broker in activemq if none of the topics or queues are durable and
the producers of messages are not asking for delivery persistence and all
the messages are asynchronous.
--
View this message in context: http://old.nabble.com/Slow-KahaDB-access-tp26594249p26629348.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Slow KahaDB access
Posted by Gary Tully <ga...@gmail.com>.
The problem is that they cannot be interpreted by the end user and even if
they could here is no clear corresponding lever to tweak at this time. It
makes sense to leave them in but with a default threshold of 0, such that
they must be enabled, by a knowledgeable user, with a limit that makes sense
for a given application environment.
2009/12/2 Fredrik Jonson <fr...@jonson.org>
> Gary Tully wrote:
>
> > Those log messages are developer debug aids that were added early on in
> the
> > dev cycle and possibly should now be removed.
>
> If those messages can be interpreted by end user why not leave them in?
> Right
> now I agree that they might be of little use, because we haven't got any
> yard
> stick to measure against. It could become useful if someone could say,
> "well
> anything below 500 ms is nothing to worry" - or - "well, once you go above
> five
> seconds you really need to consider the configuration and the hardware".
>
> I understand that it all depends on the load, even so lets start somewhere.
> As I've seen mentioned that anything below 500 ms will be filtered ouy in
> the
> future, can we assume that's a "safe" level? And if so, where is a first
> rough
> upper bound where you would start to monitor the situation? 3 s? 5? 10? 30?
>
> Thanks
> --
> Fredrik Jonson
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com
Re: Slow KahaDB access
Posted by Fredrik Jonson <fr...@jonson.org>.
Gary Tully wrote:
> Those log messages are developer debug aids that were added early on in the
> dev cycle and possibly should now be removed.
If those messages can be interpreted by end user why not leave them in? Right
now I agree that they might be of little use, because we haven't got any yard
stick to measure against. It could become useful if someone could say, "well
anything below 500 ms is nothing to worry" - or - "well, once you go above five
seconds you really need to consider the configuration and the hardware".
I understand that it all depends on the load, even so lets start somewhere.
As I've seen mentioned that anything below 500 ms will be filtered ouy in the
future, can we assume that's a "safe" level? And if so, where is a first rough
upper bound where you would start to monitor the situation? 3 s? 5? 10? 30?
Thanks
--
Fredrik Jonson
Re: Slow KahaDB access
Posted by Gary Tully <ga...@gmail.com>.
Those log messages are developer debug aids that were added early on in the
dev cycle and possibly should now be removed.
In addition, this one is a little misleading as the cleanup duration is
including the wait time to get exclusive access to the index, and not just
the index cleanup operation duration while it has the lock as it should be.
Are you noticing delays in producers or consumers or just a little worried
about the INFO message?
2009/12/1 neillott <ne...@yahoo.com>
>
> Hi,
>
> I know this question was posted earlier, but can anyone help here?
>
> http://old.nabble.com/slow-KahaDB-access-td26172918.html#a26216649
>
> I'm seeing this in my activemq log:
>
> 2009-12-01 09:29:08,690 | INFO | Slow KahaDB access: cleanup took 9789 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
> 2009-12-01 09:30:36,376 | INFO | Slow KahaDB access: cleanup took 1298 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
> 2009-12-01 09:47:18,871 | INFO | Slow KahaDB access: cleanup took 14058 |
> org.apache.activemq.store.kahadb.MessageDatabase | ActiveMQ Journal
> Checkpoint Worker
>
> When I benchmark the box I'm seeing this:
>
> [myserver] /usr/local/neil/activemq > java -classpath lib/kahadb-5.3.0.jar
> org.apache.kahadb.util.DiskBenchmark
> Benchmarking: /usr/local/neil/activemq/disk-benchmark.dat
> Writes:
> 128000 writes of size 4096 written in 18.521 seconds.
> 6911.0737 writes/second.
> 26.996382 megs/second.
>
> Sync Writes:
> 57936 writes of size 4096 written in 10.001 seconds.
> 5793.0205 writes/second.
> 22.628986 megs/second.
>
> Reads:
> 1960651 reads of size 4096 read in 10.001 seconds.
> 196045.5 writes/second.
> 765.80273 megs/second.
>
>
> What exactly do I need to do to get rid of the slow kahadb access messages?
>
> Thanks,
>
> Neil
> --
> View this message in context:
> http://old.nabble.com/Slow-KahaDB-access-tp26594249p26594249.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
--
http://blog.garytully.com
Open Source Integration
http://fusesource.com