couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Leland Hempton <ghemp...@gmail.com>
Subject Re: View Building Grinds System to Halt
Date Wed, 11 Aug 2010 19:44:18 GMT
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
>



-- 
Gordon L. Hempton
http://componentlab.com
http://hempton.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message