From user-return-20300-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Apr 2 09:25:27 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3836990E1 for ; Mon, 2 Apr 2012 09:25:27 +0000 (UTC) Received: (qmail 77617 invoked by uid 500); 2 Apr 2012 09:25:25 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 77520 invoked by uid 500); 2 Apr 2012 09:25:25 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 77482 invoked by uid 99); 2 Apr 2012 09:25:23 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2012 09:25:23 +0000 Received: from localhost (HELO mail-iy0-f180.google.com) (127.0.0.1) (smtp-auth username rnewson, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Apr 2012 09:25:23 +0000 Received: by iage36 with SMTP id e36so5517764iag.11 for ; Mon, 02 Apr 2012 02:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.179.104 with SMTP id df8mr4778475igc.11.1333358722802; Mon, 02 Apr 2012 02:25:22 -0700 (PDT) Received: by 10.42.240.135 with HTTP; Mon, 2 Apr 2012 02:25:22 -0700 (PDT) In-Reply-To: References: Date: Mon, 2 Apr 2012 10:25:22 +0100 Message-ID: Subject: Re: how to debug a single PUT that is very slow? From: Robert Newson To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 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. =A0I saw the same num= ber >> in a second test. =A0I'm assuming all of these are update handlers that = I use >> for all updates. >> >> My os_process_limit is 25. =A0 So this shouldn't be a problem, should it= ? >> =A0What is reduce_limit? =A0I noticed reduce_limit in the logs. >> >> Is there a command-line-fu trick for seeing the maximum number of >> concurrent processes spawned? > > > > -- > Iris Couch