Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bneijt@gmail.com designates
 209.85.216.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=jPUjY1dKzj/UJNvhRKiusK95TReQl6lDiabqJf6EN7x1s7qKqITJrwAtkaQwlVBQik
         eSf1oNEEEhCbC2QVcFkAwtS3OItvz6LfV65XDTUcPZ6vPyGR/SSZXH/9UQqwn/gA8kkY
         xR1XGzmgFh7Sh+NOXC6OpNBBq2rXu8x1nzocg=
MIME-Version: 1.0
In-Reply-To: <20101116165649.6tbx1v0n40g4sosc@webmail.bath.ac.uk>
References: <20101116130051.noatxco6osk0kcs8@webmail.bath.ac.uk>
	<CE80F508-9859-4C13-B0B7-73782F657B49@apache.org>
	<20101116165649.6tbx1v0n40g4sosc@webmail.bath.ac.uk>
Date: Mon, 22 Nov 2010 15:03:49 +0100
Message-ID: <AANLkTimvrQuE83JWfFrgoj_rROVT+0gY36Rm4kso+6kd@mail.gmail.com>
Subject: Re: Large attachments
From: Bram Neijt <bneijt@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I can reproduce this problem: if I upload a 500 MB and start 10
concurrent curl commands, memory usage increase dramatically with the
following environment:
Description:	Ubuntu 10.10
Release:	10.10
Codename:	maverick
{"couchdb":"Welcome","version":"1.0.1"}

Bram

On Tue, Nov 16, 2010 at 5:56 PM,  <evxdo@bath.ac.uk> wrote:
> Well, I'm just doing a GET directly to the document_id + attachment:
> http://localhost:5984/database/doc_id/attachment
>
> Clicking on the attachment in Futon would have the same effect.
>
> David
>
> Quoting Jan Lehnardt <jan@apache.org>:
>
>> Hi David,
>>
>> On 16 Nov 2010, at 14:00, evxdo@bath.ac.uk wrote:
>>
>>> Hi everyone,
>>>
>>> I'm trying to work with some large attachments (around 1.5 GB). =A0When=
 I
>>> go to download these (as a standalone attachment) the =A0CouchDB proces=
s grows
>>> in size by at least the size of the =A0attachment before the download s=
tarts.
>>> This implies that the =A0attachment is being loaded into memory entirel=
y
>>> before being sent =A0to the client. Has anyone else seen this behaviour=
? Is
>>> this a bug, =A0or is there a configuration change I can make to resolve=
 this?
>>>
>>> I've tried disabling compression on attachments in case it's the
>>> =A0compression that's causing the problem.
>>>
>>> I'm using 1.0.1.
>>
>> What does your request look like?
>>
>> The standalone attachment API does not buffer.
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>
>
>
>