incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
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.

B.

On 2 April 2012 09:57, Jason Smith <jhs@iriscouch.com> 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 <mark@hahnca.com> 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

Mime
View raw message