couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Kimber <>
Subject RE: BigCouch - Replication failing with Cannot Allocate memory
Date Thu, 12 Apr 2012 17:24:12 GMT
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


-----Original Message-----
From: Robert Newson [] 
Sent: 12 April 2012 17:25
Subject: Re: BigCouch - Replication failing with Cannot Allocate memory

Could you show your vm.args file?

On 12 April 2012 17:23, Robert Newson <> 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 <> 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 []
>> Sent: 10 April 2012 09:20
>> To:
>> 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

View raw message