[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026910#comment-16026910
]
Larry Peterson commented on COUCHDB-3421:
-----------------------------------------
Update to this issue:
We modified the mem3_sync.erl to allow setting of the batch_size and
batch_count in the config file (see below). The default values were 1 and 100
and after we were able to configure these settings we were able to get much
better throughput (with same high cpu - no change to cpu usage) and without the
"mem3 sync shards" warning message Scott described. We tried various values and
it seems increasing the batch_size (and to a lesser extent) batch_count
improves throughput. With batch_count=50 and batch_size=5000 we observe about
double the throughput with no warnings. We ran some low throughput tests and
did not observe any issues with latency on lower write rates with these
settings.
Are there any adverse side effects introduced by adjusting these values? Is it
safe to adjust these settings? If so, would it be beneficial to submit a pull
request?
{code:title=mem3_sync.erl - start_push_replication}
start_push_replication(#job{name=Name, node=Node, pid=From}) ->
if From =/= nil -> gen_server:reply(From, ok); true -> ok end,
spawn_link(fun() ->
Goopts = [{batch_size,list_to_integer(config:get("mem3", "batch_size",
"100"))},
{batch_count,list_to_integer(config:get("mem3", "batch_count",
"1"))}],
case mem3_rep:go(Name, maybe_redirect(Node),Goopts) of
{ok, Pending} when Pending > 0 ->
exit({pending_changes, Pending});
_ ->
ok
end
end).
{code}
> 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)
