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 1AE3B7C07 for ; Wed, 7 Dec 2011 21:11:23 +0000 (UTC) Received: (qmail 24253 invoked by uid 500); 7 Dec 2011 21:11:21 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 24214 invoked by uid 500); 7 Dec 2011 21:11:21 -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 24206 invoked by uid 99); 7 Dec 2011 21:11:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 21:11:21 +0000 X-ASF-Spam-Status: No, hits=0.4 required=5.0 tests=FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cgsmcmlxxv@gmail.com designates 74.125.82.54 as permitted sender) Received: from [74.125.82.54] (HELO mail-ww0-f54.google.com) (74.125.82.54) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Dec 2011 21:11:13 +0000 Received: by wgbdt13 with SMTP id dt13so1718697wgb.23 for ; Wed, 07 Dec 2011 13:10:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Wz5htY8t9GCafaXYt8kEOSAYTFGm3f3mbNjWryc3exI=; b=DC+oG+MYWyYRJJE5Vx5V3/VJCJvf+rHxMe5YrbsfpT7T+f3h/3TUIKjpRV45l8yY4h rLoquhTCkPxHBjd4LYbUBsDFnxA+U5ZekduMXmpokTS3iSjZ9Ywma/UFu5qcBaPThkyO GY9cBrS7JGVImEXKwmtRx4Q+uf54H1zIfYOVY= Received: by 10.227.197.147 with SMTP id ek19mr197788wbb.3.1323292251828; Wed, 07 Dec 2011 13:10:51 -0800 (PST) Received: from [192.168.1.100] (dynamic-78-8-7-251.ssp.dialog.net.pl. [78.8.7.251]) by mx.google.com with ESMTPS id fw16sm5031875wbb.13.2011.12.07.13.10.50 (version=SSLv3 cipher=OTHER); Wed, 07 Dec 2011 13:10:50 -0800 (PST) Message-ID: <4EDFD65A.2000202@gmail.com> Date: Wed, 07 Dec 2011 22:10:50 +0100 From: CGS User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: User authentication failures References: <4EDF2612.6040303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I tested on 2 GB RAM increasing every time by one order of magnitude at the time. At 10M it no longer started, complaining about not being able to allocate resources. I don't know exactly if it is the RAM or my linux file descriptors (CentOS 6.0). So, I remained at 1M. As far as I know, Windows 7 supports at maximum 16M file descriptors, so, you may try to raise it up to that limit for the test. Another test which I've done was if I can really have 1M spawned threads which can interact with the OS (Erlang process in which I started 1M processes in parallel which each should have brought something with cURL). The answer was no (the OS stopped increasing the number of cURL instances, invoking lack of resources). The full memory was occupied and so I couldn't determine if I reached the OS limit or I was starving my processes. In case the RAM is the problem, I suppose your 8 GB can bring up a lot of threads, but if the OS is imposing the limit, then you may want to leave some file descriptors for other processes as well. I would be interested at what numbers you reach. :) CGS On 12/07/2011 08:39 PM, Pete Vander Giessen wrote: > On Wed, Dec 7, 2011 at 12:38 AM, CGS wrote: >> It looks like Erlang reached the 1024 processes default limit. That should >> be solved by increasing ERL_MAX_PORTS ... To be noted that >> Erlang checks for the working memory availability for each thread, so, the >> maximum ports cannot be insanely high. > Thank you for that piece of info. How high would you say would be > "insanely" high for, say, a server w/ 8GB of RAM? > > Broader question: if I start a continuous replication, will that hold > a thread open for the (theoretically unlimited) duration of the > replication? > > They key thing is that I'm trying to figure out how we hit that limit > without doing anything _too_ mean to the server. Increasing the thread > limit sounds like it might be part of the solution, but I'd like to > understand the problem a bit more, and I'm doing a bit of blind > flailing at the moment ... > > ~ PeteVG