Replies: 2 comments
-
A few major changes in 3.x compared to 2.x is there is an automatic background index builder and the compactor is different too. Also the default sharing parameter Q was lowed down to 2 so perhaps that might make a difference especially if the data was replicated through (as opposed to the cluster upgraded in place). |
Beta Was this translation helpful? Give feedback.
-
This sounds somewhat similar to #3217 - are you possibly running on a cloud instance with a fixed IOPS budget in the underlying storage volume? It seems CouchDB 3.x might be more greedy on the IOPS front than 2.x, and this can result in higher latencies for interactive processing and a reduction in CPU utilization (because more processes are stuck waiting on I/O). |
Beta Was this translation helpful? Give feedback.
-
Description
Hello, we have one installation of CouchDB, using a couple of Ubuntu 18.0.4 servers, with continous replication.
The database was originally built on 2.3.1 version. Last January we moved to version 3.1.
To do this we have added an other VM with the same characteristics of the previous, and we populated the database through replication (on 3.1 we created a non partitioned DB).
The perfomance, with medium load, are worse with 3.1 than with 2.3, the VM seems to use just a part of the resources.
Downgrading to 2.3 the service is faster.
Is there something we could look at?
Your Environment
Ubuntu 18.0.4 LTS server. 4 or 8 CPU per server.
Database with about 1.5 milion docs, 23GB. There are many small attachments in the DB-
Beta Was this translation helpful? Give feedback.
All reactions