Could you show your vm.args file?
On 12 April 2012 17:23, Robert Newson <[email protected]> wrote: > 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 >>
