Var.args looks like (its the default): # Each node in the system must have a unique name. A name can be short # (specified using -sname) or it can by fully qualified (-name). There can be # no communication between nodes running with the -sname flag and those running # with the -name flag. -name bigcouch
# All nodes must share the same magic cookie for distributed Erlang to work. # Comment out this line if you synchronized the cookies by other means (using # the ~/.erlang.cookie file, for example). -setcookie monster # Tell SASL not to log progress reports -sasl errlog_type error # Use kernel poll functionality if supported by emulator +K true # Start a pool of asynchronous IO threads +A 16 # Comment this line out to enable the interactive Erlang shell on startup +Bd -noinput Mike -----Original Message----- From: Robert Newson [mailto:[email protected]] Sent: 12 April 2012 17:25 To: [email protected] Subject: Re: BigCouch - Replication failing with Cannot Allocate memory 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 >>
