[
https://issues.apache.org/jira/browse/COUCHDB-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016744#comment-16016744
]
Scott Kaul commented on COUCHDB-3421:
-------------------------------------
Hi Joan,
900 messages a second are each simple REST calls to perform an add to a newly
created DB. This is using jmeter.
All 3 instances are on their own G9.
All requests are going to a single instance--I can easily update this to hit
all 3.
On previous tests we have checked iostat and we had low utilization but I will
run the tests again to verify that is still the case for this test.
It is just beam.smp at about 750% CPU. We do have views running in our
production environment, however, for this simple test (to isolate the things we
have added), we have just a base DB.
As an aside, we ran our normal full test where we have views and what not in
the Debian set up as well and the performance/symptoms were indistinguishable
from when we were running those instances in docker with dedicated CPUs.
Is there any way we can monitor the backlog of messages that need to replicate?
(couch stats, etc.) Also, are there any good techniques for determining what
beam.smp is doing while it is gobbling up all those CPU cycles?
Thanks again for all your help.
> 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)
