Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BE83E984E for ; Wed, 11 Apr 2012 18:33:52 +0000 (UTC) Received: (qmail 84224 invoked by uid 500); 11 Apr 2012 18:33:50 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 84199 invoked by uid 500); 11 Apr 2012 18:33:50 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 84191 invoked by uid 99); 11 Apr 2012 18:33:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 18:33:50 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a58.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 18:33:42 +0000 Received: from homiemail-a58.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTP id BB41F7D806C for ; Wed, 11 Apr 2012 11:33:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; q=dns; s=thelastpickle.com; b=K+DTQcsxpy FgocEEzoQ0Rh4rw/ptN7UiD87DT3a1vjhhwN1TYlJ9x6KQJQd0QjWwhzIG6Jn5Yr 1Hf14DbcvYXpBFUXXMQtql/4Nh6giUvNaWW5roQC+RpRG+LdkVUsl2qJ3drnusWF wV8Ur0I88sr9Zzjn8sBVf5KElmaxxLBQc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :mime-version:content-type:subject:date:in-reply-to:to :references:message-id; s=thelastpickle.com; bh=VKhmZsbUjOncOgmi P/Z2fbeCtzk=; b=06pvR6/c8Ih2UBiJBlBLVYe1FEPyTxABxyJg8ijqNISst396 98iY6A3bij0nG7iigdbRM6supJw+kUN8yf0IOU30Z7Q7onkL/zoaA8F/ExmCO+eu MklzN+C/tb3fDFje3+cCOdRh95ckDm3/IVTFNKAGGbyEc5sVj349yLGF70Y= Received: from [172.16.1.3] (125-236-193-159.adsl.xtra.co.nz [125.236.193.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a58.g.dreamhost.com (Postfix) with ESMTPSA id BB8F57D805B for ; Wed, 11 Apr 2012 11:33:18 -0700 (PDT) From: aaron morton Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_F11FE407-2407-4D06-97BF-1AE57919EF36" Subject: Re: Cassandra running out of memory? Date: Thu, 12 Apr 2012 06:33:14 +1200 In-Reply-To: To: user@cassandra.apache.org References: Message-Id: X-Mailer: Apple Mail (2.1257) --Apple-Mail=_F11FE407-2407-4D06-97BF-1AE57919EF36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > 'system_memory_in_mb' (3760) and the 'system_cpu_cores' (1) according = to our nodes' specification. We also changed the 'MAX_HEAP_SIZE' to 2G = and the 'HEAP_NEWSIZE' to 200M (we think the second is related to the = Garbage Collection).=20 It's best to leave the default settings unless you know what you are = doing here.=20 > In case you find this useful, swap is off and unevictable memory seems = to be very high on all 3 servers (2.3GB, we usually observe the amount = of unevictable memory on other Linux servers of around 0-16KB) Cassandra locks the java memory so it cannot be swapped out.=20 > The problem is that the node we hit from our thrift interface dies = regularly (approximately after we store 2-2.5G of data). Error message: = OutOfMemoryError: Java Heap Space and according to the log it in fact = used all of the allocated memory. The easiest solution will be to use a larger EC2 instance.=20 People normally use an m1.xlarge with 16Gb of ram (you would also try an = m1.large). If you are still experimenting I would suggest using the larger = instances so you can make some progress. Once you have a feel for how = things work you can then try to match the instances to your budget. Hope that helps.=20 ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 11/04/2012, at 1:54 AM, Vasileios Vlachos wrote: > Hello, >=20 > We are experimenting a bit with Cassandra lately (version 1.0.7) and = we seem to have some problems with memory. We use EC2 as our test = environment and we have three nodes with 3.7G of memory and 1 core @ = 2.4G, all running Ubuntu server 11.10.=20 >=20 > The problem is that the node we hit from our thrift interface dies = regularly (approximately after we store 2-2.5G of data). Error message: = OutOfMemoryError: Java Heap Space and according to the log it in fact = used all of the allocated memory. >=20 > The nodes are under relatively constant load and store about 2000-4000 = row keys a minute, which are batched through the Trift interface in = 10-30 row keys at once (with about 50 columns each). The number of reads = is very low with around 1000-2000 a day and only requesting the data of = a single row key. The is currently only one used column family. >=20 > The initial thought was that something was wrong in the = cassandra-env.sh file. So, we specified the variables = 'system_memory_in_mb' (3760) and the 'system_cpu_cores' (1) according to = our nodes' specification. We also changed the 'MAX_HEAP_SIZE' to 2G and = the 'HEAP_NEWSIZE' to 200M (we think the second is related to the = Garbage Collection). Unfortunately, that did not solve the issue and the = node we hit via thrift keeps on dying regularly. >=20 > In case you find this useful, swap is off and unevictable memory seems = to be very high on all 3 servers (2.3GB, we usually observe the amount = of unevictable memory on other Linux servers of around 0-16KB) (We are = not quite sure how the unevictable memory ties into Cassandra, its just = something we observed while looking into the problem). The CPU is pretty = much idle the entire time. The heap memory is clearly being reduced once = in a while according to nodetool, but obviously grows over the limit as = time goes by. >=20 > Any ideas? Thanks in advance. >=20 > Bill --Apple-Mail=_F11FE407-2407-4D06-97BF-1AE57919EF36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
'system_memory_in_mb' (3760) and the = 'system_cpu_cores' (1) according to our nodes' specification. We also = changed the 'MAX_HEAP_SIZE' to 2G and the 'HEAP_NEWSIZE' to 200M (we = think the second is related to the Garbage = Collection). 
It's best to leave the default = settings unless you know what you are doing = here. 

In case you find this useful, swap is off and unevictable = memory seems to be very high on all 3 servers (2.3GB, we usually observe = the amount of unevictable memory on other Linux servers of around = 0-16KB)
Cassandra locks the java memory so it cannot = be swapped out. 

The problem is that the node we hit from = our thrift interface dies regularly (approximately after we store 2-2.5G = of data). Error message: OutOfMemoryError: Java Heap Space and according = to the log it in fact used all of the allocated = memory.
The easiest solution will be to use a larger = EC2 instance. 

People normally use an = m1.xlarge with 16Gb of ram (you would also try an = m1.large).

If you are still experimenting I = would suggest using the larger instances so you can make some progress. = Once you have a feel for how things work you can then try to match the = instances to your budget.

Hope that = helps. 

http://www.thelastpickle.com

On 11/04/2012, at 1:54 AM, Vasileios Vlachos = wrote:

Hello,

We = are experimenting a bit with Cassandra lately (version 1.0.7) and we = seem to have some problems with memory. We use EC2 as our test = environment and we have three nodes with 3.7G of memory and 1 core @ = 2.4G, all running Ubuntu server 11.10.

The problem is that the node we hit from our thrift interface = dies regularly (approximately after we store 2-2.5G of data). Error = message: OutOfMemoryError: Java Heap Space and according to the log it = in fact used all of the allocated memory.

The nodes are under relatively constant load and store about = 2000-4000 row keys a minute, which are batched through the Trift = interface in 10-30 row keys at once (with about 50 columns each). The = number of reads is very low with around 1000-2000 a day and only = requesting the data of a single row key. The is currently only one used = column family.

The initial thought was that something was wrong in the = cassandra-env.sh file. So, we specified the variables = 'system_memory_in_mb' (3760) and the 'system_cpu_cores' (1) according to = our nodes' specification. We also changed the 'MAX_HEAP_SIZE' to 2G and = the 'HEAP_NEWSIZE' to 200M (we think the second is related to the = Garbage Collection). Unfortunately, that did not solve the issue and the = node we hit via thrift keeps on dying regularly.

In case you find this useful, swap is off and unevictable memory = seems to be very high on all 3 servers (2.3GB, we usually observe the = amount of unevictable memory on other Linux servers of around 0-16KB) = (We are not quite sure how the unevictable memory ties into Cassandra, = its just something we observed while looking into the problem). The CPU = is pretty much idle the entire time. The heap memory is clearly being = reduced once in a while according to nodetool, but obviously grows over = the limit as time goes by.

Any ideas? Thanks in = advance.

Bill

= --Apple-Mail=_F11FE407-2407-4D06-97BF-1AE57919EF36--