Beam.smp proccess is saturing my cpu usage

[Victor Fernandez]

Hi, I have a Couchbase Server 2.2.0 running in an Amazon Linux EC2 instance. The problem that I actually having is that i have two proccess that are using a lot of the CPU Percentage.

I restart the couchbase server, and when it started again automatically the process beam.smp have been triggered using the 100% of my CPU, then this use have been reduced to 50%. Despite

of this, 50% is a lot of usage. I want to know if someone have this problem before and have any suggestions.

The other process that use a lot of percentage is the process memcached.

Any help will be appreciated!

[ashwini ahire]

Hi,

I had same problem ...

Its known bug with couchbase 2.2 , If you can upgrade your couchbase with latest version.

I think it will solve your problem.

Just Install new couchbase version and replicate data to new CB.

Regards,

Ashwini Ahire

--
You received this message because you are subscribed to the Google Groups "Couchbase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to couchbase+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marc Trudel]

I don't mind too much doing this, but I would love to understand what causes the issue in the first place, if possible. 

P.S. Latest == 3.x?

--

	Marc Trudel-Belisle Chief Technology Officer | Wizcorp Inc. TECH . GAMING . OPEN-SOURCE WIZARDS
+ 81 3-4550-1448|Website|Twitter|Facebook|LinkedIn

[Jed Coronado]

Hi,

This happened to us before, on the same Couchbase version. We've been at 99% CPU usage even with a very light load.

We finally were able to pinpoint this to one of our view's reduce function. There's a limit to the reduce output - I'm not sure if this has been fixed in the latest version - but when we modified the view's reduce code, everything went back to normal.

My guess is that with the erroneous view in place, we weren't getting errors when the view was emitting a small set of data, but became a problem when the data being returned became huge.

You might want to check your views' reduce function, and see if there lies the culprit.

For more details, see the link below.

http://www.couchbase.com/issues/browse/DOC-26

Regards,

Jed

[Marc Trudel]

To clarify, I have no views, no data, no nothing. It's a brand new single-machine cluster.

[Aliaksey Kandratsenka]

Hi.

In general even under light load couchbase can eat quite a lot of cpu. Due to the way persistence (and xdcr and views) work. It has to do with smaller batches and coordination between memcached and beam.smp (less so in 3.0 due to internally famous "death of mccouch").

If completely idle box eats close to 100% of cpu that's suspicious. In general, we do eat a bit of cpu even idle for things like stats gathering, heartbeats (yes even with single node cluster), autocompaction checks (yes, it's still periodic rather than tied to actual mutations). But that normally eats low single digits of CPU.

In order to investigate the case where idle couchbase eats close to 100% of cpu we need more evidence. The recommended procedure is as usual. Grab collectinfos, file jira ticket and attach collectinfos to ticket. Note that it looks like our jira doesn't like larger attachments. But you can still upload somewhere else (e.g. google drive, dropbox, etc) and post link. With cbcollectinfo there is great chance that we'll be able to spot specific reason of high cpu load in specific case(s).