Adam Kocoloski <kocolosk@...> writes: > > Mahesh, do you by chance have an updater running for the view group when the view compaction completes? > > On Jan 2, 2011, at 4:53 PM, Adam Kocoloski wrote: > > > These reports do sound suspiciously like the problems described in COUCHDB-901 that caused us to rewrite > the OS process management in BigCouch. Mahesh, yours is the first report I've heard that specifically > implicated view compaction. That's significant. I didn't understand what you meant by "clobber all the > views", though. > > > > I'll poke around and see if I can devise a scenario where the OS process would not be released after view > compaction. In my experience the internal ets tables maintained in CouchDB to track OS processes got > out-of-sync - one table would report 1000 available processes, while another table would claim only 2. Best, > > > > Adam
Any updates on this?, We seem to be having similar issues. I would estimate that we accumulate about 150 couchjs processes over a 24 hour period. As far as I can tell these processes are doing nothing but consuming memory. Each one holds about 56meg of VIRT ant 5meg of RES. We are running couchdb on a system with no swap, and if left unchecked eventually these processes consume all available memory, thus starving couchdb. I dont remember having this issue before we added a view_updater to the [update_notification] section. We are using the 'view_updater.rb' provided in the example on http://wiki.apache.org/couchdb/Regenerating_views_on_update Thanks, James
