Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of
 luismiguelferreirasilva@gmail.com designates 209.85.218.52 as permitted
 sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=references:in-reply-to:mime-version:content-transfer-encoding
         :content-type:message-id:cc:x-mailer:from:subject:date:to;
        b=FCoykkQO6sVglVq71/LBubMpg29RteYSzOsbojs4ibqNX4Ci6iwsvRky+uuTgu2sBB
         L81tFt1nIBm5kpyxn7xzuLa4QlBUlIRr0ifRORwy+JVazua44b/7z/qTGgKSL/IGSvG2
         dz53pi6L/SuesIkIXH36r0CiojCrKaEsUe1kg=
References: <BANLkTikcT-is9AMRRf7=xKOv2M_X0Yyd3g@mail.gmail.com>
 <4D9AD80A.6020904@aol.com> <85412353-A793-48D5-9D63-AF7C98B25030@gmail.com>
 <BANLkTi=4UNJbXZcvx4UnzbeJ_iTC48Q1Wg@mail.gmail.com>
In-Reply-To: <BANLkTi=4UNJbXZcvx4UnzbeJ_iTC48Q1Wg@mail.gmail.com>
Mime-Version: 1.0 (iPhone Mail 8G4)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <2F1E2B3E-7665-491E-81F9-8D2696D657A1@gmail.com>
Cc: "user@couchdb.apache.org" <user@couchdb.apache.org>
From: Luis Miguel Silva <luismiguelferreirasilva@gmail.com>
Subject: Re: CouchDB crashing on me (while doing benchmark with 1 million
 documents)
Date: Tue, 5 Apr 2011 09:14:11 -0600
To: "user@couchdb.apache.org" <user@couchdb.apache.org>

Robert,

Yes, i agree but my company still needed extreme tests to evaluate potential=
 limitations.
Im extremely excited with couchdb but had to report what can we expect from i=
t before adopting it!

Either way, the 1 million bulk wasnt the problem. That just, apparently, sto=
od there and was taking forever to finish (i dont know if it wouldnt be able=
 to recover by itself).
My problem is with the concurrent 1 million docs.

Thanks,
Luis Miguel Silva

On Apr 5, 2011, at 9:08 AM, Robert Newson <robert.newson@gmail.com> wrote:

> One million docs in a single _bulk_docs query? I'm not surprised it
> doesn't work, that's quite a weird thing to try.
>=20
> B.
>=20
> On 5 April 2011 14:59, Luis Miguel Silva
> <luismiguelferreirasilva@gmail.com> wrote:
>> It is version 1.0.1 (i think - i can't connect to my server right now, bu=
t it's basically the latest stable version available for download in the off=
icial web site), and i'm running on CentOS 5.5 x64.
>>=20
>> Do you want the steps i used to reproduce this?
>>=20
>> p.s. i also tried submitting 1 million documents to the bulk_docs API (fr=
om one process) and after 33 minutes the process still hadn't finished so i j=
ust killed it...
>> p.p.s. as for the test that crashed couchdb, i actually tried it two or t=
hree times (after restarting couchDB and starting with a brand new / clean D=
B)...
>>=20
>> Thanks,
>> Luis Miguel Silva
>>=20
>> On Apr 5, 2011, at 2:51 AM, Cliff Williams <cliffywills@aol.com> wrote:
>>=20
>>> Luis,
>>>=20
>>> good morning.
>>>=20
>>> What platform (linux/windows) and version of couchdb are you running??
>>>=20
>>> best regards
>>>=20
>>> Cliff
>>>=20
>>> On 05/04/11 06:49, Luis Miguel Silva wrote:
>>>> Dear all,
>>>>=20
>>>> I'm doing some benchmarks on CouchDB and it seems i'm making it crash
>>>> when i try to create 1 million parallel documents, using 10 processes,
>>>> submitting 100000K documents each (using the bulk_docs API).
>>>> Is there anything i can debug to figure out what is going on? The
>>>> server just dies and the logs do not show anything special...
>>>>=20
>>>> The only thing i see in the client side is that the server just
>>>> unexpectedly closed the connection and did not return anything...
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>> curl: (52) Empty reply from server
>>>>=20
>>>> real    1m20.955s
>>>> user    0m0.180s
>>>> sys     0m0.148s
>>>>=20
>>>> real    1m21.034s
>>>> user    0m0.140s
>>>> sys     0m0.064s
>>>>=20
>>>> real    1m21.036s
>>>> user    0m0.144s
>>>> sys     0m0.088s
>>>>=20
>>>> real    1m21.035s
>>>> user    0m0.192s
>>>> sys     0m0.124s
>>>>=20
>>>> real    1m21.041s
>>>> user    0m0.184s
>>>> sys     0m0.168s
>>>>=20
>>>> real    1m21.040s
>>>> user    0m0.108s
>>>> sys     0m0.136s
>>>>=20
>>>> real    1m21.048s
>>>> user    0m0.136s
>>>> sys     0m0.092s
>>>>=20
>>>> real    1m21.050s
>>>> user    0m0.136s
>>>> sys     0m0.132s
>>>>=20
>>>> real    1m21.049s
>>>> user    0m0.112s
>>>> sys     0m0.116s
>>>>=20
>>>> real    1m21.059s
>>>> user    0m0.132s
>>>> sys     0m0.092s
>>>>=20
>>>> [root@xkitten ~]#
>>>>=20
>>>> Any thoughts?
>>>>=20
>>>> p.s. does anybody else have some interesting benchmarks they can hare w=
ith me?
>>>>=20
>>>> Thank you!
>>>> Luis
>>>>=20
>>=20