You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Sharath <sh...@gmail.com> on 2015/07/04 00:08:58 UTC
Uncaught error in HTTP request
Hi All,
Been running couchdb 1.6.1 for 6 months without any problems.
I've been getting the following error since yesterday:
[Fri, 03 Jul 2015 21:56:59 GMT] [error] [<0.26167.4>] Uncaught error in
HTTP request: {error,
{badmatch,
{error,
corrupted_data}}}
[Fri, 03 Jul 2015 21:56:59 GMT] [info] [<0.26167.4>] Stacktrace:
[{couch_compress,decompress,1,
[{file,"couch_compress.erl"},{line,68}]},
{couch_file,pread_term,2,
[{file,"couch_file.erl"},{line,135}]},
{couch_btree,get_node,2,
[{file,"couch_btree.erl"},{line,349}]},
{couch_btree,stream_node,7,
[{file,"couch_btree.erl"},{line,623}]},
{couch_btree,stream_kp_node,7,
[{file,"couch_btree.erl"},{line,637}]},
{couch_btree,stream_kp_node,8,
[{file,"couch_btree.erl"},{line,679}]},
{couch_btree,fold,4,
[{file,"couch_btree.erl"},{line,159}]},
{couch_mrview_util,fold,4,
[{file,"src/couch_mrview_util.erl"},
{line,293}]}]
Coincidentally, I upgraded my OS X to 10.10.4 yesterday.
However, If I send the same http request after a little while, I do not get
the error.
I'm thinking maybe this is a related to the underlying networking code.
I've seen a bug closed earlier as it cannot be reproduced:
https://leap.se/code/issues/3521
Any pointers? Ill try downgrading to 10.10.3 as a last resort (or) ignoring
the error.
any precautions before I take the latter approach?
-Sharath
Fwd: A big Thumbs Up for CouchDB!
Posted by Jan Lehnardt <ja...@apache.org>.
Heya dev@,
this came in on user@ and I wanted to make sure you saw this :)
Best
Jan
--
> Begin forwarded message:
>
> From: Kiril Stankov <ki...@open-net.biz>
> Subject: A big Thumbs Up for CouchDB!
> Date: 25 Jul 2015 01:32:12 CEST
> To: user@couchdb.apache.org
> Reply-To: user@couchdb.apache.org
>
> Hi all,
>
> I am working on a pretty complex project for the last 7 months.
> Since the beginning I was researching a lot what DB to use. NoSQL was obvious choice, but I wondered between several options, MongoDB and CouchDB being the obvious leaders.
> Now, half an year later, I am very glad for choosing CouchDB!
>
> It is an incredible product. Replication and views are the best features! My app is a distributed one and I use CouchDB for the back-end synchronization of data. My server is node.js and 'follow' gives me a perfect way to monitor for changes.
>
> For now, CouchDB is very stable, fast and reliable. It is the heart of a complex solution and there are no bad surprises until now. Updates to the DB are very intensive and we have more than 1000 documents inserted per day. Replication works great across continents and two operating systems. HTTP API's make it so easy to monitor it and to offload part of the load from node.js and retrieve data directly from Couch. We do use a lot of List and Reduce functions to make life easier.
>
> Another great think about Couch is the community. I found so many useful posts and articles. I got a lot of help from people on this list. Thank you.
>
> Well, there are still some issues, but there are not that important and I am sure they'll be solved soon. Unfortunately I didn't have the time to check v2.0, but I'll surely do so, once it is released officially.
>
> Finally, a big THANK YOU to all developers and supporters of CouchDB. I think that with every open source project this is the least we, the users, can do to cheer up the people behind such a great software!
>
> Regards and Relax,
>
> Kiril.
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Fwd: A big Thumbs Up for CouchDB!
Posted by Jan Lehnardt <ja...@apache.org>.
Heya dev@,
this came in on user@ and I wanted to make sure you saw this :)
Best
Jan
--
> Begin forwarded message:
>
> From: Kiril Stankov <ki...@open-net.biz>
> Subject: A big Thumbs Up for CouchDB!
> Date: 25 Jul 2015 01:32:12 CEST
> To: user@couchdb.apache.org
> Reply-To: user@couchdb.apache.org
>
> Hi all,
>
> I am working on a pretty complex project for the last 7 months.
> Since the beginning I was researching a lot what DB to use. NoSQL was obvious choice, but I wondered between several options, MongoDB and CouchDB being the obvious leaders.
> Now, half an year later, I am very glad for choosing CouchDB!
>
> It is an incredible product. Replication and views are the best features! My app is a distributed one and I use CouchDB for the back-end synchronization of data. My server is node.js and 'follow' gives me a perfect way to monitor for changes.
>
> For now, CouchDB is very stable, fast and reliable. It is the heart of a complex solution and there are no bad surprises until now. Updates to the DB are very intensive and we have more than 1000 documents inserted per day. Replication works great across continents and two operating systems. HTTP API's make it so easy to monitor it and to offload part of the load from node.js and retrieve data directly from Couch. We do use a lot of List and Reduce functions to make life easier.
>
> Another great think about Couch is the community. I found so many useful posts and articles. I got a lot of help from people on this list. Thank you.
>
> Well, there are still some issues, but there are not that important and I am sure they'll be solved soon. Unfortunately I didn't have the time to check v2.0, but I'll surely do so, once it is released officially.
>
> Finally, a big THANK YOU to all developers and supporters of CouchDB. I think that with every open source project this is the least we, the users, can do to cheer up the people behind such a great software!
>
> Regards and Relax,
>
> Kiril.
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: A big Thumbs Up for CouchDB!
Posted by Robert Kowalski <ro...@kowalski.gd>.
Wow that's great to hear!
Keep us posted how your project evolves! :)
On Sat, Jul 25, 2015 at 1:32 AM, Kiril Stankov <ki...@open-net.biz> wrote:
> Hi all,
>
> I am working on a pretty complex project for the last 7 months.
> Since the beginning I was researching a lot what DB to use. NoSQL was
> obvious choice, but I wondered between several options, MongoDB and CouchDB
> being the obvious leaders.
> Now, half an year later, I am very glad for choosing CouchDB!
>
> It is an incredible product. Replication and views are the best features! My
> app is a distributed one and I use CouchDB for the back-end synchronization
> of data. My server is node.js and 'follow' gives me a perfect way to monitor
> for changes.
>
> For now, CouchDB is very stable, fast and reliable. It is the heart of a
> complex solution and there are no bad surprises until now. Updates to the DB
> are very intensive and we have more than 1000 documents inserted per day.
> Replication works great across continents and two operating systems. HTTP
> API's make it so easy to monitor it and to offload part of the load from
> node.js and retrieve data directly from Couch. We do use a lot of List and
> Reduce functions to make life easier.
>
> Another great think about Couch is the community. I found so many useful
> posts and articles. I got a lot of help from people on this list. Thank you.
>
> Well, there are still some issues, but there are not that important and I am
> sure they'll be solved soon. Unfortunately I didn't have the time to check
> v2.0, but I'll surely do so, once it is released officially.
>
> Finally, a big THANK YOU to all developers and supporters of CouchDB. I
> think that with every open source project this is the least we, the users,
> can do to cheer up the people behind such a great software!
>
> Regards and Relax,
>
> Kiril.
Re: A big Thumbs Up for CouchDB!
Posted by Jan Lehnardt <ja...@apache.org>.
Thank you Kiril! You email made my day and I’m happy CouchDB is working so well for you :)
Best
Jan
--
> On 25 Jul 2015, at 01:32, Kiril Stankov <ki...@open-net.biz> wrote:
>
> Hi all,
>
> I am working on a pretty complex project for the last 7 months.
> Since the beginning I was researching a lot what DB to use. NoSQL was obvious choice, but I wondered between several options, MongoDB and CouchDB being the obvious leaders.
> Now, half an year later, I am very glad for choosing CouchDB!
>
> It is an incredible product. Replication and views are the best features! My app is a distributed one and I use CouchDB for the back-end synchronization of data. My server is node.js and 'follow' gives me a perfect way to monitor for changes.
>
> For now, CouchDB is very stable, fast and reliable. It is the heart of a complex solution and there are no bad surprises until now. Updates to the DB are very intensive and we have more than 1000 documents inserted per day. Replication works great across continents and two operating systems. HTTP API's make it so easy to monitor it and to offload part of the load from node.js and retrieve data directly from Couch. We do use a lot of List and Reduce functions to make life easier.
>
> Another great think about Couch is the community. I found so many useful posts and articles. I got a lot of help from people on this list. Thank you.
>
> Well, there are still some issues, but there are not that important and I am sure they'll be solved soon. Unfortunately I didn't have the time to check v2.0, but I'll surely do so, once it is released officially.
>
> Finally, a big THANK YOU to all developers and supporters of CouchDB. I think that with every open source project this is the least we, the users, can do to cheer up the people behind such a great software!
>
> Regards and Relax,
>
> Kiril.
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
A big Thumbs Up for CouchDB!
Posted by Kiril Stankov <ki...@open-net.biz>.
Hi all,
I am working on a pretty complex project for the last 7 months.
Since the beginning I was researching a lot what DB to use. NoSQL was
obvious choice, but I wondered between several options, MongoDB and
CouchDB being the obvious leaders.
Now, half an year later, I am very glad for choosing CouchDB!
It is an incredible product. Replication and views are the best
features! My app is a distributed one and I use CouchDB for the back-end
synchronization of data. My server is node.js and 'follow' gives me a
perfect way to monitor for changes.
For now, CouchDB is very stable, fast and reliable. It is the heart of a
complex solution and there are no bad surprises until now. Updates to
the DB are very intensive and we have more than 1000 documents inserted
per day. Replication works great across continents and two operating
systems. HTTP API's make it so easy to monitor it and to offload part of
the load from node.js and retrieve data directly from Couch. We do use a
lot of List and Reduce functions to make life easier.
Another great think about Couch is the community. I found so many useful
posts and articles. I got a lot of help from people on this list. Thank
you.
Well, there are still some issues, but there are not that important and
I am sure they'll be solved soon. Unfortunately I didn't have the time
to check v2.0, but I'll surely do so, once it is released officially.
Finally, a big THANK YOU to all developers and supporters of CouchDB. I
think that with every open source project this is the least we, the
users, can do to cheer up the people behind such a great software!
Regards and Relax,
Kiril.
Re: High CPU after loading 15K documents
Posted by Alexander Shorin <kx...@gmail.com>.
On Tue, Jul 21, 2015 at 1:36 PM, Alexander Shorin <kx...@gmail.com> wrote:
> 1. Enable Erlang node by adding "-name couchdb@localhost -setcookie 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"
Fixed. Not sure how I wrote that.
--
,,,^..^,,,
Re: High CPU after loading 15K documents
Posted by Alexander Shorin <kx...@gmail.com>.
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 <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
>>>>
>>
>
Re: Crash on replication
Posted by Alexander Shorin <kx...@gmail.com>.
Hi Kiril,
The answer is in the error:
"Target database out of sync. Try to increase max_dbs_open at the
target's server."
This happens when[1] instance_start_time value for Target db had
changed during replication. CouchDB monitors it in order to detect
server restart, but it's also happens when max_dbs_open is lower when
actual number of active databases on server: in this case CouchDB
closes fd for some dbs in order to be able to work with the other
following by inner lru cache.
The reason why replication get shutdown is that this situation also
falls under the edge case when Target (and Source too) database could
be changed in the middle of replication (cleared by DELETE with
following PUT, or restored from backup with server instance restart).
In this case CouchDB won't continue replication, but starts it over
again to make sure that all the documents will be replicated
correctly..
[1]: https://github.com/apache/couchdb-couch-replicator/blob/master/src/couch_replicator.erl#L784-L786
--
,,,^..^,,,
On Fri, Aug 7, 2015 at 12:09 PM, Kiril Stankov <ki...@open-net.biz> wrote:
> Hi all,
>
> I see few errors like the one below.
> Any idea what the reason can be?
> Why a replication issue should lead to shutdown?
>
> Thanks in advance.
>
>
> [Fri, 07 Aug 2015 08:05:52 GMT] [error] [<0.91.0>] {error_report,<0.31.0>,
> {<0.91.0>,supervisor_report,
> [{supervisor,{local,couch_replicator_job_sup}},
> {errorContext,child_terminated},
> {reason,
> {checkpoint_commit_failure,
> <<"Target database out of sync. Try to
> increase max_dbs_open at the target's server.">>}},
> {offender,
> [{pid,<0.199.0>},
> {name,
> "848c572641fd68bf9084a2f465f4d8ba+continuous+create_target"},
> {mfargs,{gen_server,start_link,undefined}},
> {restart_type,temporary},
> {shutdown,250},
> {child_type,worker}]}]}}
Crash on replication
Posted by Kiril Stankov <ki...@open-net.biz>.
Hi all,
I see few errors like the one below.
Any idea what the reason can be?
Why a replication issue should lead to shutdown?
Thanks in advance.
[Fri, 07 Aug 2015 08:05:52 GMT] [error] [<0.91.0>] {error_report,<0.31.0>,
{<0.91.0>,supervisor_report,
[{supervisor,{local,couch_replicator_job_sup}},
{errorContext,child_terminated},
{reason,
{checkpoint_commit_failure,
<<"Target database out of sync. Try to
increase max_dbs_open at the target's server.">>}},
{offender,
[{pid,<0.199.0>},
{name,
"848c572641fd68bf9084a2f465f4d8ba+continuous+create_target"},
{mfargs,{gen_server,start_link,undefined}},
{restart_type,temporary},
{shutdown,250},
{child_type,worker}]}]}}
Error and crash after changing reduce function
Posted by Kiril Stankov <ki...@open-net.biz>.
Hi all,
I had several crashes today.
Here is what I got in the log after changing a reduce function:
[Thu, 06 Aug 2015 08:06:56 GMT] [error] [<0.4332.11>] Uncaught error in
HTTP request: {exit,
{shutdown,
{gen_server,call,
[<0.4340.11>,
{pread_iolist,
19405854},
infinity]}}}
[Thu, 06 Aug 2015 08:06:56 GMT] [error] [<0.4296.11>] httpd 500 error
response:
{"error":"shutdown","reason":"{gen_server,call,[<0.4340.11>,{pread_iolist,19405854},infinity]}"}
Any idea?
The change I made was from
if(rereduce==true) {...}
to
if(rereduce) {...}
Thanks.
Re: Limiting id's to ascii.
Posted by Alexander Shorin <kx...@gmail.com>.
Use validate_doc_update function that verifies document`s _id field.
--
,,,^..^,,,
On Wed, Jul 29, 2015 at 8:55 PM, Kiril Stankov <ki...@open-net.biz> wrote:
> Hi,
> I wonder if there is way to limit document id's only to ascii compatible characters.
> Some sort of validation or configuration?
> Thanks.
> --
> Regards,
>
> Kiril Stankov,
> OpenNet Software ltd.
Limiting id's to ascii.
Posted by Kiril Stankov <ki...@open-net.biz>.
Hi,
I wonder if there is way to limit document id's only to ascii compatible characters.
Some sort of validation or configuration?
Thanks.
--
Regards,
Kiril Stankov,
OpenNet Software ltd.
Re: High CPU after loading 15K documents
Posted by Jan Lehnardt <ja...@apache.org>.
Do you see anything in /_active_tasks?
> On 21 Jul 2015, at 12:37, Kiril Stankov <ki...@open-net.biz> wrote:
>
> It is constantly high, not some peak moments.
> I am monitoring htop with interval 1 sec and the CPU is above 12-15% with most of this taken by erlang.
> ------------------------------------------------------------------------
> *With best regards,*
> Kiril Stankov,
> CEO
>
>
> This Email disclaimer
> <http://open-net.biz/emailsignature.html> is integral part
> of this message.
>
> On 21-Jul-15 12:49 PM, Jan Lehnardt wrote:
>> Do you see anything in /_active_tasks while the CPU is up?
>>
>> Best
>> Jan
>> --
>>
>>> On 21 Jul 2015, at 10:36, Kiril Stankov <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
>>>>>>
>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: High CPU after loading 15K documents
Posted by Kiril Stankov <ki...@open-net.biz>.
It is constantly high, not some peak moments.
I am monitoring htop with interval 1 sec and the CPU is above 12-15%
with most of this taken by erlang.
------------------------------------------------------------------------
*With best regards,*
Kiril Stankov,
CEO
This Email disclaimer
<http://open-net.biz/emailsignature.html> is integral part
of this message.
On 21-Jul-15 12:49 PM, Jan Lehnardt wrote:
> Do you see anything in /_active_tasks while the CPU is up?
>
> Best
> Jan
> --
>
>> On 21 Jul 2015, at 10:36, Kiril Stankov <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
>>>>>
Re: High CPU after loading 15K documents
Posted by Jan Lehnardt <ja...@apache.org>.
Do you see anything in /_active_tasks while the CPU is up?
Best
Jan
--
> On 21 Jul 2015, at 10:36, Kiril Stankov <ki...@open-net.biz> 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 <ki...@open-net.biz> 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.
>>>>
>>
>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: High CPU after loading 15K documents
Posted by Kiril Stankov <ki...@open-net.biz>.
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 <ki...@open-net.biz> 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.
>>>
>
Re: High CPU after loading 15K documents
Posted by Kiril Stankov <ki...@open-net.biz>.
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 <ki...@open-net.biz> 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.
>>
Re: High CPU after loading 15K documents
Posted by Adam Kocoloski <ko...@apache.org>.
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 <ki...@open-net.biz> 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.
>
High CPU after loading 15K documents
Posted by Kiril Stankov <ki...@open-net.biz>.
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.