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 8BD7B8B36 for ; Fri, 26 Aug 2011 20:17:26 +0000 (UTC) Received: (qmail 26944 invoked by uid 500); 26 Aug 2011 20:17:24 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 26895 invoked by uid 500); 26 Aug 2011 20:17:24 -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 26887 invoked by uid 99); 26 Aug 2011 20:17:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Aug 2011 20:17:23 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.220.180 as permitted sender) Received: from [209.85.220.180] (HELO mail-vx0-f180.google.com) (209.85.220.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Aug 2011 20:17:17 +0000 Received: by vxh15 with SMTP id 15so4232656vxh.11 for ; Fri, 26 Aug 2011 13:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=chTouZKguP5uTfav2wXQQhAg7qhYB0emGR+l5yyC7aI=; b=YSVVF2UozW0GhzQM2bVpy8UjoM+/x35g3ifl6W7BndmhB45hQq+NF47ShmXJtvMu6t IY3jf9ygyCs3RmlKk9SysIu6GJp+z0JBxypDUCuBgKiOALSU531Or+hG7iJQtHLG3mXi FQbbeZDKOheDKwxAUN78rj1QivlLXO5V/CJII= Received: by 10.52.93.76 with SMTP id cs12mr1492497vdb.503.1314389816107; Fri, 26 Aug 2011 13:16:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.29.1 with HTTP; Fri, 26 Aug 2011 13:16:16 -0700 (PDT) In-Reply-To: References: From: Paul Davis Date: Fri, 26 Aug 2011 15:16:16 -0500 Message-ID: Subject: Re: Emfile error To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org This issue isn't specific to CouchDB. You'll run into this anytime you have a network server. The basic lines of attack in increasing complexity: 1. Make sure and reuse your HTTP connections as much as possible. CouchDB handles persistent connections appropriately. The client just has to make sure that its using them. In the code you outlined above it looks like you're creating an HTTP connection for every request. My guess would be to reuse those HttpClient instances. 2. Increase the file descriptor limits and ephemeral port ranges if you're hitting system limits. 3. Decrease the socket maximum segment lifetime so that sockets don't stay in TIME_WAIT as long (defined as 2*MSL). This has other tricky ramifications that you'd want to understand before tweaking. On Fri, Aug 26, 2011 at 2:32 PM, Dias, Cliff, VF-Group wrote: > I see. So what does this mean for an application which expects a high loa= d ? Do I need to tell couchDB to be keep the connection alive and reuse the= connection ? > > I would be interested in how people have implemented a couchDB high load = application. > > Thanks in advance, > > Kind regards, > Cliff > > > -----Original Message----- > From: Paul Davis [mailto:paul.joseph.davis@gmail.com] > Sent: Fri 8/26/2011 19:44 > To: user@couchdb.apache.org > Subject: Re: Emfile error > > Sockets are files too. Each HTTP connection you make will require a > socket unless you reuse that the client and it has HTTP/1.1 support. > Each socket opened will remain open for a bit before the kernel closes > it which leads to sockets exhausting the serveres file descriptor > limit. > > > On Fri, Aug 26, 2011 at 9:17 AM, Dias, Cliff, VF-Group > wrote: >> Hi, >> I am trying to run a load test on a couch db instance. I am peforming an >> http post to insert the data to the DB, but I get an emfile error. >> >> I have read the FAQ and I understand that I have to increase the file >> descriptor limit. >> >> I would like to understand why I need to do this ? I am writing to a >> single database, so I would expect couch DB to recycle the connection. >> >> Here is the method I use to write. It is a simple method called 10000 >> times. >> >> >> public void doAdd(Data data) throws HttpException, IOException >> =A0 =A0 =A0 =A0{ >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0PostMethod method; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0HttpClient client =3D new HttpClient(); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0String url =3D baseURL; >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0method =3D new PostMethod(url); >> >> >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Gson gson =3D new >> GsonBuilder().setPrettyPrinting().create(); >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0String jsonOutput =3D gson.toJson(data); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0method.setRequestBody(jsonOutput); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0method.setRequestHeader( "content-type", >> "application/json"); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0long t1 =3D System.currentTimeMillis(); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0client.executeMethod(method); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0String response =3D method.getResponseBod= yAsString(); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0long t2 =3D System.currentTimeMillis(); >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.out.println("response =3D " + resp= onse); >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.out.println("Time =3D " + (t2-t1))= ; >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0method.releaseConnection(); >> >> =A0 =A0 =A0 =A0} >> >> >> Kind regards, >> Cliff >> > >