This doesn’t seem very efficient, is this normal? It’s also interesting that it’s evenly spread across all four cores on the server. It seems nonsensical for XDCR to consume 1/5 of the clusters compute power while idle.
Also it’s interesting to look at the historical CPU numbers. For a long time it sat around 10% CPU on average, and likely starting around our upgrade to 4.6.2 in August, it jumped up to 20% and it’s been there ever since;
How many buckets are you replicating through XDCR @jeffhoward001 ? According to the Couchbase documentation you will need 1-2 extra core per bucket only to support XDCR replication. Maybe this is your problem.
We’re aware of that requirement, but that is a good reminder. Overall I was hoping for someone from the engineering side at Couchbase to chime in on exactly “what” it’s doing to consume 20% CPU when we’re not actually mutating any documents that would trigger an XDCR event.
If it was consuming high CPU whilst incoming document writes were high, then I would be inclined to increase our CPU power. But the fact that it’s consuming CPU whilst literally -nothing- is happening on the server (no reads, no writes) seems like a software issue.
Not always, but traditionally high CPU usages for idle processes is a sign that something is wrong.