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 <[email protected]> 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:[email protected]] > Sent: 10 April 2012 09:20 > To: [email protected] > 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 >
