@Robert Thanks a lot for the advice, I will check it. On 10 December 2017 at 18:11, Robert Samuel Newson <[email protected]> wrote:
> fs-manager is not part of couchdb. You should check that you've not been > hacked. See https://justi.cz/security/2017/11/14/couchdb-rce-npm.html < > https://justi.cz/security/2017/11/14/couchdb-rce-npm.html>. > > I've seen another case where a user's couchdb installation was compromised > and a bitcoin mining tool installed. This would (obviously) use all your > cpu, and I think fs-manager was part of that. > > B. > > > On 10 Dec 2017, at 17:07, Sinan Gabel <[email protected]> wrote: > > > > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > wrote: > >>>> > >>>> > >>>> > >>> > >> > >
