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 ericpcarlson@gmail.com
 designates 74.125.82.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:date:from:reply-to:user-agent:mime-version:to
         :subject:references:in-reply-to:content-type
         :content-transfer-encoding;
        b=O9I18f0VC2m37o6W/e0zI0npnV9dk5s6Kd2wasyKYch5+mYDUV1/AWm6KdtrB6uCM4
         v1q/nW5L8GbDNT1d+ndVM5DN10jKGhDn/XnEaP7y+orctZw+SJGypTtcsMVfdTF50ULz
         sIEC8O8SKdtczW3CIFxd9SanPtB5UgFfPP+kM=
Sender: Eric Carlson <ericpcarlson@gmail.com>
Message-ID: <4C632ED0.1030406@ericcarlson.co.uk>
Date: Thu, 12 Aug 2010 00:14:24 +0100
From: Eric Carlson <eric@ericcarlson.co.uk>
Reply-To: eric@ericcarlson.co.uk
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: View Building Grinds System to Halt
References: <AANLkTi=6BmBbPn2fSNdGPRGLWV7cWH6J7sT9_vwHsZJJ@mail.gmail.com>
	<AANLkTi=TW1Wn9E6nNm5-uvpuPc6iM_vi8ZeFLmwm=0NF@mail.gmail.com>
	<AANLkTik54fUOg7cY7aOM+X18ndh4ghLGPE2cTYL+1b1c@mail.gmail.com>
	<AANLkTinWvuJhuuea3wU==cJc9Ugpi-5eZzBWs2YMiaQ3@mail.gmail.com>
 <AANLkTimJ8SF8y5gCKwkUZbg18hkzWeWDkW_2_nfWJ3zC@mail.gmail.com>
In-Reply-To: <AANLkTimJ8SF8y5gCKwkUZbg18hkzWeWDkW_2_nfWJ3zC@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

 Not sure if this will help, but you did say at one point that you built
from source. Have a look in /usr/local/lib/couchdb/erlang/lib to see if
there is more than one couch-xxx folder. Each build adds its own
couch-xxx directory there, where xxx reflects the version number. If
there is more than one such directory, Erlang can become confused and do
some very strange things unless you remove all but the directory that
corresponds to the version of couchdb that you are running . The
simplest solution is to delete everything in
/usr/local/lib/couchdb/erlang/lib and to redo the 'sudo make install',
which will put back only the latest versions of everything. (This
assumes that you haven't added any Erlang files of your own to the
directory, of course.) Like I say, don't know if this is the problem,
but it's worth a look.

Although it is unrelated to your view problems, I would be remiss if I
didn't mention that if you are indeed using v1.0.0, you should read
http://couchdb.apache.org/notice/1.0.1.html.

Eric

On 11/08/10 20:44, Gordon Leland Hempton wrote:
> For what it's worth, the only way I was able to fix this was to delete the
> database and recreate all of the documents.
>
> On Fri, Aug 6, 2010 at 10:45 AM, Gordon Leland Hempton
> <ghempton@gmail.com>wrote:
>
>> Thanks for your responses!
>>
>> The design document for this database is trivial. There is only the single
>> view which emits a single property as the key:
>>
>> {
>>    "_id": "_design/Trademark",
>>    "_rev": "6-ecab7bf9158e188ab2c39d37c4a1fb4d",
>>    "views": {
>>        "by_filingDate": {
>>            "map": "function(doc) { emit(doc.filingDate, null); }"
>>        }
>>    }
>> }
>>
>>
>> This exact same setup works on a smaller scale of data on our development boxes.
>>
>>
>> I have also ensured that ldconfig was run. I am actually using the script provided on the wiki to update the xulrunner version. Futhermore, before I fixed xulrunner, NONE of my views were working, however now views are working fine on all databases exect ones of large size.
>>
>>
>> Thanks,
>>
>> Gordon
>>
>>
>> On Thu, Aug 5, 2010 at 1:25 PM, David Caylor <dcaylor@fh.org> wrote:
>>
>> Did you run ldconfig after you set the xulrunner settings?  I did that to
>>> myself last time I updated a Ubuntu box where I'd installed couchdb from
>>> source.  I updated the xulrunner.conf, but forgot to run ldconfig, and got
>>> pretty much what you are describing.
>>>
>>> David Caylor
>>>
>>>
>>> On Wed, Aug 4, 2010 at 4:07 PM, Gordon Leland Hempton <ghempton@gmail.com
>>>> wrote:
>>>> After looking at the logs, it looks pretty bad:
>>>>
>>>> [Wed, 04 Aug 2010 22:57:28 GMT] [info] [<0.12883.0>] 127.0.0.1 - - 'GET'
>>>>
>>>>
>>> /trademark/_design/Trademark/_view/by_filingDate?limit=10&stale=ok&descending=true&include_docs=true
>>>> 200
>>>>
>>>> [Wed, 04 Aug 2010 22:57:52 GMT] [error] [emulator] Error in process
>>>> <0.12957.0> with exit value:
>>> {badarg,[{erlang,binary_to_term,[<<1885695232
>>>>
>>> bytes>>]},{couch_file,pread_term,2},{couch_db,make_doc,5},{couch_db,open_doc_int,3},{couch_view_updater,load_doc,5},{couch_view_updater,'-update/2-fun-2-',8},{couch_btree,stream_kv_node2,8...
>>>> Anyone know where to start?
>>>>
>>>> I am running Ubuntu 10.04 server with couchdb 1.0 installed from source.
>>> I
>>>> have made sure the xulrunner settings are correct.
>>>>
>>>> Thanks,
>>>>
>>>> On Wed, Aug 4, 2010 at 12:18 PM, Gordon Leland Hempton
>>>> <ghempton@gmail.com>wrote:
>>>>
>>>>> I am working with a database of ~10 mil docs and 30GB size. I am
>>> trying
>>>> to
>>>>> build a view consisting of a single field as the key and a null
>>> document.
>>>>> After creating the view and trying to access it, the couchdb beam.smp
>>>>> command eventually goes up to 12.3GB virtual memory and uses 3.7GB of
>>>>> physical memory. Memory is clearly the bottleneck as the CPU usage is
>>>> around
>>>>> 5-15%. My system only has 4GB of memory so naturally all this paging
>>> is
>>>>> slowing everything down to a crawl.
>>>>>
>>>>> After a few minutes this usage will go back down, but it will get to
>>> the
>>>>> same levels every time I access the view (which is still building and
>>> has
>>>>> been for 12 hours).
>>>>>
>>>>> Is this normal? How can I improve this?
>>>>>
>>>>> --
>>>>> Gordon L. Hempton
>>>>> http://componentlab.com
>>>>> http://hempton.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Gordon L. Hempton
>>>> http://componentlab.com
>>>> http://hempton.com
>>>>
>>
>>
>> --
>> Gordon L. Hempton
>> http://componentlab.com
>> http://hempton.com
>>
>
>