Updater?  Mildly confused....  (sorry 'bout that - terminology incomprehension on my part...)

Mahesh Paolini-Subramanya | CTO | mahesh@aptela.com | 703.386.1500 Ext. 9100
2250 Corporate Park Drive | Suite 150 | Herndon, VA | www.aptela.com
Check out our Blog | Follow us on Twitter | Refer a Friend 

On Jan 2, 2011, at 5:10 PM, Adam Kocoloski wrote:

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,


On Jan 2, 2011, at 12:25 PM, Mahesh Paolini-Subramanya wrote:

Sorry - apologies - hit Send by accident :-(

Wow - wierdness here.  I'm running 1.0.1, and have noticed the same thing
happening.  The specific (and very replicable - for me at least) scenario is
as follows
- I've got around a thousand dbs, each with around 50K documents, and each
with about 5 (javascript) design documents.
- I clobber all the views, and remotely (LWP::UserAgent) compact the view
- THe compaction of the design document results in the design exactly being
generate (this is good_
- The compaction also leave a couchjs process just lying around (this would
be bad)
- After a few thousand couchjs processes, couchdb just chokes.

Any ideas? This related in any way to the process issues in BigCouch (Jira


On Mon, Sep 7, 2009 at 12:18 AM, Paul Davis <paul.joseph.davis@gmail.com>wrote:

Another random thought, after your clients have been running a bit, an
easy way to check why type of stuff is going on with sockets is:

$ netstat -ap tcp

If your apps have periods of high turnover, check the sockets to see
if you have lots of them in TIME_WAIT state.


On Sun, Sep 6, 2009 at 11:39 PM, Arun Thampi<arun.thampi@gmail.com> wrote:
Thanks Paul for the quick response. I'll poke around further to see if
is anything amiss and will keep the list posted.

On Mon, Sep 7, 2009 at 11:24 AM, Paul Davis <paul.joseph.davis@gmail.com

The algorithm for CouchDB's use of OS processes is pretty simple:

"Give me an os process plz"

If none are available, then it creates a new one. A large number of OS
processes would suggest to me that something isn't releasing OS
processes correctly. My first guess would be to look at _list and
_show as those both require an OS process, but are also at the mercy
of client connection semantics. I might be reaching a bit, but I
wonder if CouchRest is failing to close sockets properly. Its not much
more than a random finger pointing, but there have been other errors
recently that also suggest CouchRest isn't doing proper socket

The other possibility is there's something weird with killing
processes, but couchspawnkillable should've fixed that.

Paul Davis

On Sun, Sep 6, 2009 at 11:18 PM, Arun Thampi<arun.thampi@gmail.com>
Hi guys - Been running CouchDB trunk(r804727) in production for about
weeks now and one thing I've noticed is that the number of couchjs
keeps increasing to a large amount. Is this normal? Does CouchDB
these processes and eventually kill inactive couchjs processes?
Just FYI I'm using CouchRest as part of a Rails app to query two
views in my db.

Thanks in advance.


It's better to be a pirate than join the Navy - Steve Jobs

It's better to be a pirate than join the Navy - Steve Jobs

Mahesh Paolini-Subramanya | CTO | mahesh@aptela.com | 703.386.1500 Ext. 9100
13454 Sunrise Valley Drive | Suite 500 | Herndon, VA