On Wed, Dec 15, 2010 at 11:47 AM, Stanislaw Kogut <sko...@sistyma.net> wrote:
> On Wed, Dec 15, 2010 at 8:08 PM, Bruce Snyder <bruce.sny...@gmail.com>
> wrote:
>>
>> On Wed, Dec 15, 2010 at 10:56 AM, Stanislaw Kogut <sko...@sistyma.net>
>> wrote:
>> > On Wed, Dec 15, 2010 at 7:37 PM, Bruce Snyder
>> > <bruce.sny...@gmail.com>wrote:
>> >
>> >> On Wed, Dec 15, 2010 at 10:32 AM, Stanislaw Kogut <sko...@sistyma.net>
>> >> wrote:
>> >> > I already tried every topic here, with no significant effect.
>> >> > I'm already using KahaDB for peristence (even placing it's data to
>> >> tmpfs).
>> >> > I can't use async send/receive, as I need reliable transport.
>> >> > I'm using transactions (this is a requirement).
>> >>
>> >> How about your KahaDB settings? Try this:
>> >>
>> >> <kahaDB directory="${activemq.base}/data/kahadb"
>> >> enableJournalDiskSyncs="false"
>> >> indexWriteBatchSize="10000"
>> >> indexCacheSize="1000"/>
>> >>
>> >> Already have this in config file.
>> >
>> >
>> >> > What about multiple consumers? Should they use one or many different
>> >> > connection factories or sessions to consume faster?
>> >>
>> >> Creating multiple sessions from a single connection works well.
>> >>
>> >> Ok then.
>> > What about further scalability of queue? It is very probably I will need
>> > to
>> > send more and more messages. Will distributing queue over many brokers
>> > help
>> > with throughput without significant latency impact? Or there is only way
>> > to
>> > scale up with hardware for broker?
>>
>> Please provide your broker config file so we can have a look.
>>
> Attached config file.
I notice that the <systemUsage> element has been completely removed.
You should put this element back in and make sure that you have given
the broker enough memory to use from the JVM so as to maximize
performance and minimize garbage collection. Furthermore, increase the
store usage (holds persistent messages) and the tempUsage (holds
non-persistent messages) limits Without the <systemUsage> element in
the XML config, then the default values are used -- 64mb of memory for
the broker which is quite low and should be increased. More info here:
http://activemq.apache.org/producer-flow-control.html#ProducerFlowControl-Systemusage
>> Another item, have you disabled the dedicated task runner in the
>> ActiveMQ start script?
>
> Disabled after this question, but looks like it didn't help with one
> consumer thread.
Are you still only using one consumer? Because message consumption is
much more costly than message production, the only way to speed up
message consumption is to use multiple consumers concurrently.
>> Also, have you read through this article?:
>>
>>
>> http://fusesource.com/wiki/display/ProdInfo/Understanding+the+Threads+Allocated+in+ActiveMQ
>>
> Looks like it is for vm transport. I'm running (and will run) producer and
> consumer on different machines, so I can't get rid of transport threads, as
> in in-vm transport.
The article does make use of the VM transport, but it also discusses
various options and how they control thread use in the broker.
Bruce
--
perl -e 'print
unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
