activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "anselme dewavrin (JIRA)" <>
Subject [jira] [Commented] (AMQ-4987) io wait on replicated levelDB slaves
Date Thu, 23 Jan 2014 09:53:38 GMT


anselme dewavrin commented on AMQ-4987:

Dear All,

The iowait and huge disk activity is due to frequent fsyncs on the slaves. I demonstrated
this by preloading a library that disables fsyncs (with a With
this trick the iowait disappear.

I think the leveldb replicated stores is in itself secure enough without fsync-ing each update,
because of the synchronous replication (sync=quorum_mem) on different machines that should
fail within the same seconds. This is why the many fsyncs on the slaves are not useful, in
my opinion.

For my purpose I will live with the LD_PRELOAD, but it could be profitable for the community
to make the levelDB replicated store evolve.


> io wait on replicated levelDB slaves
> ------------------------------------
>                 Key: AMQ-4987
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Test
>          Components: activemq-leveldb-store
>    Affects Versions: 5.9.0
>         Environment: debian VM 2.6.32-5-amd64, jdk7
>            Reporter: anselme dewavrin
>            Priority: Minor
> Dear all,
> I set up a 3-nodes replicatedLevelDB activeMQ cluster as explained on the activemq site.
> I made a message injector using the php stomp client described here :
> Then I injected persistent messages as fast as possible (giving about 600 messages/s).
> Everything works fine, then I measured the servers' activity with "vmstat 1". I saw no
iowait on the master node, but  20% on both slaves. This would impeach scalabitity I suppose.
And the iowait is justified by 3000 bo/s (blocks out) in the vmstat report.
> The machines are not swapping (paging).
> Here is what I tried, without success :
> -specify explicitly sync="quorum_mem"
> -JNI implementation of the leveldb store (and verified it is used)
> -setting flushDelay to 2000
> Does anyone have an idea that I could try ? Why is the leveldb slaves writing so much
to disk ?
> Many thanks in advance
> Yours,
> Anselme

This message was sent by Atlassian JIRA

View raw message