Hi Kiril, It's hard to say for sure, but worth to take a step into Erlang land and do the following actions:
1. Enable Erlang node by adding "-name couchdb -cookie monster" to ERL_START_OPTIONS in /usr/bin/couchdb like: ERL_START_OPTIONS="$ERL_OS_MON_OPTIONS -sasl errlog_type error +K true +A 4 -name couchdb@localhost -setcookie monster" 2. Restart CouchDB 3. Create a script etop with the following content (copy-paste of mine one): #!/bin/sh erl -name etop-`date +%s` -hidden -s etop -s erlang halt \ -output text -sname etop -node $1 -setcookie $2 \ -tracing on -sort runtime -interval 5 -lines 20 4. Run it as ./etop couchdb@localhost monster Sort, lines number and interval period configure by your taste. You should see source of the top activity. Please share what you'll found. More info about options you can find here: http://www.erlang.org/doc/man/etop.html Hope this could help. -- ,,,^..^,,, On Tue, Jul 21, 2015 at 11:36 AM, Kiril Stankov <[email protected]> wrote: > Hi, > > I am monitoring CouchDB all the time and the CPU keeps around 10-12% all the > time from the erlang processes. > I do not think this is normal. > A new document is added to the DB each 5-6 minutes, but what takes CPU time > when the DB is idle? > There are very few read requests, may be 1 each 1-2 minutes or so. > > Here is a screenshot from htop: > http://pho.to/9aTTK > > Any ideas how can I understand what goes on? > ------------------------------------------------------------------------ > *With best regards,* > Kiril Stankov, > CEO > > > This Email disclaimer > <http://open-net.biz/emailsignature.html> is integral part > of this message. > > > On 08-Jul-15 12:35 AM, Kiril Stankov wrote: >> >> Hi, >> >> sorry, I saw the couchdb user, mistaking it for a process. Actually what >> takes most of the cpu is beam.smp. >> Yes, I do have some reduce functions, 90% of them are simply _count. >> On the Futon status screen I see only replication jobs, which are 100% >> completed. >> There is nothing special in the couch.log, either. >> Database sizes are very small, few Mb. >> Now, it's midnight here, there is no activity whatsoever in the >> application and beam.smp swings between 3 and 15% cpu. >> For the last 10 hours it has 8+ hours TIME in 'top'. >> Host is latest Ubuntu, Couch version is 1.6.1. >> >> On 07-Jul-15 10:08 PM, Adam Kocoloski wrote: >>> >>> Hi Kiril, no it’s not normal. Did you mean `couchjs` when you said >>> `couchdb`? If so it’s likely related to indexing. Do your views have custom >>> reduce functions? A poorly-behaved custom reduce function (e.g. one that >>> doesn’t really “reduce” its output) could yield very slow indexing. Does the >>> dashboard indicate any indexing jobs ongoing? >>> >>> Adam >>> >>>> On Jul 7, 2015, at 1:42 PM, Kiril Stankov <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> I've loaded 15K docs to a single DB, with 7 views, which do not emit >>>> docs (just id's). >>>> Since then (4 hours now) the CPU is constantly high (~15-20%) with most >>>> of it divided between couchdb and beam.smp. >>>> In addition couch became significantly slower than before (when there >>>> were ~ 3K docs). >>>> Is that normal? Can it be related to indexing? How long can it take? >>>> >>>> Thanks in advance. >>>> >>>> Kiril. >>>> >> >
