You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Jean-Yves Moulin <jy...@baaz.fr> on 2013/08/20 14:49:50 UTC

replication slow down

Hi CouchDB users,

I'm trying to replicate a big database: 35 millions documents. Average doc size is 500 bytes.

When replication starts, from server A to server B (from server B in pull mode), we got replicate at 1100 documents per second. Then, after some thousands of documents replicated, replication slowly decelerates until 100 doc/sec.

If I restart the couchdb daemon on server B, replication restarts at 1100 doc/sec. And then slow down again. At 100 doc/sec I need multiple weeks to replicate the full database.. :-(

Obviously, the two servers are far from their performances limits: one half CPU used (on 16), 10GB of RAM used (on 64GB), and very small I/O (on 24 disks + 2 ssd for cache).

You can see here: http://jym.eileo.net/couchdb_req.png , A small graph showing the http requests on server A (almost all GET requests come from server B). The restart of server B is clearly visible at 10:30.

I already try to change worker_batch_size, worker_processes and http_connections but this doesn't change anything.

Do you know if this is a know bug or how can I improve the situation ?


Thank you very much.

best,
jym

Re: replication slow down

Posted by Jan Lehnardt <ja...@apache.org>.
On Aug 20, 2013, at 18:25 , Jean-Yves Moulin <jy...@baaz.fr> wrote:

> Hi,
> 
> 
> On 20 Aug 2013, at 15:16 , Adam Kocoloski <ko...@apache.org> wrote:
> 
>> Did you specify "continuous": true in the replication spec?  If you did, do you see the same slowdown if you omit that flag?
> 
> Yes, I was using "continuous": true.
> 
> You're right: When disabling "continuous", replication seems more stable and efficient (1200 doc/sec). Thank you !
> 
> Is there a PR open on this, or should I open one ?

Joan opened https://issues.apache.org/jira/browse/COUCHDB-1874 in the meantime. Thanks for the report! :)

Best
Jan
--


Re: replication slow down

Posted by Jean-Yves Moulin <jy...@baaz.fr>.
Hi,


On 20 Aug 2013, at 15:16 , Adam Kocoloski <ko...@apache.org> wrote:

> Did you specify "continuous": true in the replication spec?  If you did, do you see the same slowdown if you omit that flag?

Yes, I was using "continuous": true.

You're right: When disabling "continuous", replication seems more stable and efficient (1200 doc/sec). Thank you !

Is there a PR open on this, or should I open one ?


best,
jym

Re: replication slow down

Posted by Adam Kocoloski <ko...@apache.org>.
Did you specify "continuous": true in the replication spec?  If you did, do you see the same slowdown if you omit that flag?

This sounds rather similar to a bug we encountered in early builds of BigCouch, but I don't remember the history of the codebase well enough to say whether the bug might be latent in Apache CouchDB.

Adam

On Aug 20, 2013, at 8:49 AM, Jean-Yves Moulin <jy...@baaz.fr> wrote:

> Hi CouchDB users,
> 
> I'm trying to replicate a big database: 35 millions documents. Average doc size is 500 bytes.
> 
> When replication starts, from server A to server B (from server B in pull mode), we got replicate at 1100 documents per second. Then, after some thousands of documents replicated, replication slowly decelerates until 100 doc/sec.
> 
> If I restart the couchdb daemon on server B, replication restarts at 1100 doc/sec. And then slow down again. At 100 doc/sec I need multiple weeks to replicate the full database.. :-(
> 
> Obviously, the two servers are far from their performances limits: one half CPU used (on 16), 10GB of RAM used (on 64GB), and very small I/O (on 24 disks + 2 ssd for cache).
> 
> You can see here: http://jym.eileo.net/couchdb_req.png , A small graph showing the http requests on server A (almost all GET requests come from server B). The restart of server B is clearly visible at 10:30.
> 
> I already try to change worker_batch_size, worker_processes and http_connections but this doesn't change anything.
> 
> Do you know if this is a know bug or how can I improve the situation ?
> 
> 
> Thank you very much.
> 
> best,
> jym