couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sinan Gabel <sinan.ga...@gmail.com>
Subject Re: 100% CPU on only a single node because of couchjs processes
Date Sun, 10 Dec 2017 17:07:18 GMT
Same problem with latest couchdb clustered version. What is the process "
*/.fs-manager*" doing?

Googling it returned something about a python package called "fs-manager"!?

For now I have killed the *couchdb fs-manager* process, and couchdb still
seems to be working fine.

On 10 December 2017 at 16:50, Sinan Gabel <sinan.gabel@gmail.com> wrote:

> PS I have just now upgraded to latest couchdb clustered version, I will
> see if that solves the 100% CPU usage problem.
>
> On 10 December 2017 at 15:28, Sinan Gabel <sinan.gabel@gmail.com> wrote:
>
>> Hi,
>>
>> I do not have a solution but also experiencing the 100% CPU usage. Here's
>> a .png screen shot of the processes running (my case):
>>
>>
>> On 10 December 2017 at 02:00, Geoffrey Cox <redgeoff@gmail.com> wrote:
>>
>>> Well, I'm back at this and here is the latest info and I think it may be
>>> related to writes and the _global_changes database:
>>>
>>>    1. I run my production env and one of my nodes becomes the "workhorse"
>>>    node with 100% CPU
>>>    2. I stop all my production code from generating any more CouchDB
>>>    requests and eventually the workhorse node goes back to 0% CPU
>>>    3. I can then issue writes on a single database (really any database
>>> and
>>>    ANY node--not just the workhorse node) and the workhorse node will
>>> kick
>>>    back up to 100% CPU. If I stop the writes, the workhorse node will
>>> return
>>>    to 0% CPU.
>>>    4. And now the punch line: if I delete the _global_changes database,
>>> the
>>>    CPU drops down to 0% even if I am issuing writes! Pure cray cray
>>>
>>> Any thoughts?
>>>
>>> (Sorry, still working on a reproducible env for everyone)
>>>
>>> On Wed, Dec 6, 2017 at 6:56 AM Geoffrey Cox <redgeoff@gmail.com> wrote:
>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message