Count the number of sockets in TIME_WAIT. Perhaps you're periodically exhausting the ephemeral port range. The kernel would then block waiting for one to leave TIME_WAIT.
B. On 2 April 2012 09:57, Jason Smith <[email protected]> wrote: > I think that pretty definitively rules out that problem. On a lark you > could double your os_process_limit but as I said in the followup > email, I didn't realize that your problem is a direct attachment (no > _update). > > By the way, when I asked about validate_doc_update, that includes > *all* design docs in the database, not just the one with your _update > functions. (Another longshot.) > > On Mon, Apr 2, 2012 at 8:06 AM, Mark Hahn <[email protected]> wrote: >>> It would be interesting to see how many `couchjs` processes you `beam` >> (or `beam.smp`) process has spawned. >> >> I did a "ps aux" and saw eleven couchjs processes. I saw the same number >> in a second test. I'm assuming all of these are update handlers that I use >> for all updates. >> >> My os_process_limit is 25. So this shouldn't be a problem, should it? >> What is reduce_limit? I noticed reduce_limit in the logs. >> >> Is there a command-line-fu trick for seeing the maximum number of >> concurrent processes spawned? > > > > -- > Iris Couch
