@Geoffrey Thanks Geoffrey, I will start by checking out the advice of @Robert and see what that brings. I understand now that ./fs-manager has nothing to do with couchdb but it is running as user: couchdb so hacking could be the issue in my case.
On 10 December 2017 at 18:14, Geoffrey Cox <[email protected]> wrote: > Hi Sinan, I don’t believe we are encountering the same problem as my > CouchDB instances run fine with almost no CPU usage until I introduce some > activity. And this is fine except the issue is that with a 2-node cluster, > the majority of the activity is focused on just one of the nodes. > > Perhaps in your situation you just need to add some more CPU or memory > capacity? > On Sun, Dec 10, 2017 at 9:07 AM 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: > > >>> > > >>> > > >>> > > >> > > > > > >
