[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035455#comment-16035455
]
Michael Pearce commented on COUCHDB-3421:
-----------------------------------------
So, it seems like increasing the batch_size will definitely increase
throughput, but perhaps at the cost losing a larger amount of data in the case
of a crash mid-batch (please correct me if I'm wrong about that
interpretation). Increasing batch_count may slightly reduce overhead, but
mostly it will reduce the frequency of the warning messages. It would be really
nice to hear about what impact these changes may have.
But, I'm really more concerned by the fact that under this relatively light
load, the system is CPU bound – not IO bound. The Erlang VM seems to be using
100% of as many cores as you can give it. What can it possibly be doing?
Shouldn't it be spending most of its time waiting on IO?
> mem3 sync shards WARNING at very low message rate, data doesn't sync
> --------------------------------------------------------------------
>
> Key: COUCHDB-3421
> URL: https://issues.apache.org/jira/browse/COUCHDB-3421
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Reporter: Scott Kaul
> Priority: Minor
>
> Sending couch messages, as low as 100 messages a second, results in couch
> falling behind on its replication with other nodes. In cluster configuration
> n, w, and r are all set to 2. While sending these messages, the following
> warning is observed:
> May 17 15:56:54 coreosnode2 docker[26520]: [warning]
> 2017-05-17T15:56:54.753466Z [email protected] <0.309.0> --------
> mem3_sync shards/20000000-3fffffff/test.1495035040
> [email protected] {pending_changes,151}
> Likewise after the message loader is stopped (jmeter) it takes couch a period
> of time (minutes) to complete replication before the WARNINGs are no longer
> received and couchDB CPU goes down.
> I'm happy to provide a jmx file for jmeter as well as a couple curl commands
> to delete/create the DB used.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
