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: >>> >>> >>> >> >
