[jira] [Commented] (COUCHDB-3421) mem3 sync shards WARNING at very low message rate, data doesn't sync

["Michael Pearce (JIRA)" <ji...@apache.org>]

    [ 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 couchdb-3@couchdb-3.couchdb <0.309.0> -------- mem3_sync shards/20000000-3fffffff/test.1495035040 couchdb-2@couchdb-2.couchdb {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)