couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <>
Subject Re: how to debug a single PUT that is very slow?
Date Mon, 02 Apr 2012 09:25:22 GMT
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.


On 2 April 2012 09:57, Jason Smith <> 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 <> 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

View raw message