Hello,
Erlang is used internally to manage and monitor all the persistence. So Couchbase Server is monitoring data files in order to see whether data fles are compacted and compact files when necessary; same with the view/indexes.
So this explains some CPU cycles of the erlang engine.
Remember that if you have installed the samples buckets (beer-sample, game-sample) contain some views.
Regards
Thanks for the reply.
My laptop is a retina macbook with an ivy bridge quad core in it. There is only 1 data bucket, with no documents in it and no indexes and views. I disabled everything that does anything with couchbase.
Still erl.exe takes up 5 - 10% of the CPU (after a fresh reboot of my laptop) and takes a whopping 334 MB for what? Also memcached.exe takes up 162 mb. That is around 500MB without any documents.
I’m sorry, I have no experience with couchbase but I can’t believe this is normal?
Hi,
Couchbase is a great product, got it up and running and working nicely. I also tried out the balancing/replication thing and this works like a charm.
The only thing that sets me back is the idle cpu usage. Even when I restart my laptop (on which I got it running), as soon as the couchbase service starts running I can see erl.exe taking up 10% - 30% of my cpu with intervals (some seconds 0% some seconds between 15 and 30%)
I have no buckets but the default installed, no indexes/views, just a clean install.
What is couchbase doing?
Alright, I deleted the bucket and created a memcached one. Now the memory and cpu of erl.exe and memcached.exe are more of what i’d expect (low).
Still would like to know how a few couchbase buckets will be doing on an production environment.
Like I said, I’m new to couchbase so most likely I’m wrong but if 3 of my servers (which aren’t that new) are busy compacting all the time this would be a huge hit on my server resources.
I can confirm this. On a clean installation with one empty couchbase bucket, after idling for 7 days, the erl.exe process has accumulated more than 50 hours of CPU time, which is equivalent to 30% of one CPU. For comparison, my own python.exe process has accumulated 10 seconds of CPU time.
Yes this is known issue. We’re improving things. 2.0.1 is already better than 2.0.0 and 2.0.2 is going to be even better.
What it’s doing 30% of time? Stats gathering, background checks etc. Yes we know it’s suboptimal. And we’re working on that.
Let me also note that even with that idle cpu consumption we’re still leaving enough CPU for our k-v layer to be very competitive performance-wise.
Hi,
5.0 is here with the same issue… and same wording even - relatively fresh JIRA issue https://issues.couchbase.com/browse/MB-27274?focusedCommentId=262301&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-262301
CPU is wasted on a very inefficient process of persisting metrics into compressed files on the file system at different time scales. Does anybody know how to decrease this interval at least?
Found it.
In etc/couchbase/static_config add this:
{grab_stats_every_n_ticks, 15}.
(changes statistics collection interval from 1 to 15 seconds.
I want to point out that the little dot “.” at the end is very important. otherwise you will end up with an error after startup like this:
Failed to read static config: ["/opt/couchbase/etc/couchbase/static_config"]. It must be a readable file with list of pairs.
Just to save you from searching the needle in the haystack… like me 
Hi @synesty,
In our newest 7.X releases the CPU usage in what is considered an idle system is much lower. Although he processing overhead is still not zero the recurring CPU used for coordination between processes and monitoring is greatly reduced. In past release the CPU overhead was associated with the number of buckets, however the introduction of collections allows the equivalent of a 1,000 lightweight buckets (in a bucket.scope.collection organization) refer to What’s New in Version 7.0? | Couchbase Docs.
To give some concrete information on the improvements for a tiny three node cluster (3x AWS t3.small which is not even recommended for couchbase) loading 6 buckets with 50K docs each and creating an index in each bucket the idle CPU utilization has dropped from 19% down to 8%. But better yet using collections in a single bucket you can support 40+ collections in the same bucket with an idle CPU utilization of just 8%.
Note that statistics are now processed by prometheus as such the prior advice on changing static_config is no longer applicable in 7.X (and most like no necessary). Thus different parameters control the frequency of collection in prometheus DM me directly is you need directions using the REST API to alter the prometheus scrape intervals.
Best
Jon Strabala
Principal Product Manager - Server‌
@jon.strabala , thanks for the note.
You have mentioned “idle CPU utilization” at 2 places, perhaps you intended to write “CPU utilization”