/opt/couchbase/bin/goxdcr always consuming 20% CPU

We’ve noticed this for the past few months, but I finally have some bandwidth to look into it. XDCR consumes 20% CPU on every node in our cluster, even when the Ops Per Second are (or near) zero;

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;

Something doesn’t seem right about that. Is this a known issue with smaller cluster nodes? We’re using 4-core 14GB DS-v2 VMs in Azure.


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.

Reference: https://developer.couchbase.com/documentation/server/4.6/xdcr/xdcr-create.html

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.

1 Like