Thanks everyone. Using the packet sniffer I was able to determine it only took 300 ms for couch to respond. So now I'm back to the node world to find the culprit.
I wish the couch logs could be more readable and tell me how long a request takes. Only showing the time to the nearest second is quite crude. On Mon, Apr 2, 2012 at 2:25 AM, Robert Newson <[email protected]> wrote: > 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 >
