couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kimber <mkim...@kana.com>
Subject RE: BigCouch - Replication failing with Cannot Allocate memory
Date Thu, 12 Apr 2012 17:22:57 GMT
Ah, thought there had to be some reason; the response on the couch mailing list is always excellent.

Mike 

-----Original Message-----
From: Robert Newson [mailto:rnewson@apache.org] 
Sent: 12 April 2012 17:24
To: user@couchdb.apache.org
Subject: Re: BigCouch - Replication failing with Cannot Allocate memory

Unfortunately your request for help coincided with the two day CouchDB
Summit. #cloudant and the Issues tab on cloudant/bigcouch are other
ways to get bigcouch support, but we happily answer queries here too,
when not at the Model UN of CouchDB. :D

B.

On 12 April 2012 17:10, Mike Kimber <mkimber@kana.com> wrote:
> Looks like this isn't the right place based on the responses so far. Shame I hoped this
was going to help solve our index/view rebuild times etc.
>
> Mike
>
> -----Original Message-----
> From: Mike Kimber [mailto:mkimber@kana.com]
> Sent: 10 April 2012 09:20
> To: user@couchdb.apache.org
> Subject: BigCouch - Replication failing with Cannot Allocate memory
>
> I'm not sure if this is the correct place to raise an issue I am having with replicating
a standalone couchdb 1.1.1 to a 3 node BigCouch cluster? If this is not the correct place
please point me in the right direction if it is then any one have any ideas why I keep getting
the following error message when I kick of a replication;
>
> eheap_alloc: Cannot allocate 1459620480 bytes of memory (of type "heap").
>
> My set-up is:
>
> Standalone couchdb 1.1.1 running on Centos 5.7
>
> 3 Node BigCouch cluster running on Centos 5.8 with the following local.ini overrides
pulling from the Standalone couchdb (78K documents)
>
> [httpd]
> bind_address = XXX.XX.X.XX
>
> [cluster]
> ; number of shards for a new database
> q = 9
> ; number of copies of each shard
> n = 1
>
> [couchdb]
> database_dir = /other/bigcouch/database
> view_index_dir = /other/bigcouch/view
>
> The error is always generate on the third node in the cluster and the server basically
max's out on memory before hand. The other nodes seem to be doing very little, but are getting
data i.e. the shard sizes are growing. I've put the copies per shard down to 1 as currently
I'm not interested in resilience.
>
> Any help would be greatly appreciated.
>
> Mike
>

Mime
View raw message