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 DF9BE17E87 for ; Fri, 9 Jan 2015 08:51:53 +0000 (UTC) Received: (qmail 34271 invoked by uid 500); 9 Jan 2015 08:51:52 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 34233 invoked by uid 500); 9 Jan 2015 08:51:52 -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 34222 invoked by uid 99); 9 Jan 2015 08:51:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jan 2015 08:51:52 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of doanduyhai@gmail.com designates 209.85.218.51 as permitted sender) Received: from [209.85.218.51] (HELO mail-oi0-f51.google.com) (209.85.218.51) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Jan 2015 08:51:26 +0000 Received: by mail-oi0-f51.google.com with SMTP id h136so11036533oig.10 for ; Fri, 09 Jan 2015 00:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZCDxB328AbUFI+Oo8iw+GiYGIPAZwdyhBPMGM0HPCaE=; b=ajHCCINNlRv3dSjDvvpOB4Pk3OCY/pukmwara5bKkND3YRKq4okwWwI24dCdFP6bwz YfCKnz/P9j4Pt0RsXl2bYAxh0wbCdJ6MlJXc0Wg2sQpB8fYCraiprKuTO9wIvpF/hfkY TLbe+k0pssskg2KyTnSg3I55Xn/Z+oA37eU5qmyU8u6UQxm3yrgv0hFQLlgHHikw7LFB l09FZtCgGSjpJXhxhJHNDv3eOeu/8Gwn0mEIMILTE7ZiB5RqMCmEwX8kSI9PparO1lpu Dl6AWSL4bbZbELmBS+U7vCshywfrBwLLtlc5wIh5LsIWAGAS/E099C/B9COWrao6wWm8 XdJw== MIME-Version: 1.0 X-Received: by 10.182.51.165 with SMTP id l5mr8577935obo.56.1420793439672; Fri, 09 Jan 2015 00:50:39 -0800 (PST) Received: by 10.76.56.202 with HTTP; Fri, 9 Jan 2015 00:50:39 -0800 (PST) In-Reply-To: <045D8FD556C73347A47F956EE65F822018574E27@S11MAILD013N2.sh11.lan> References: <045D8FD556C73347A47F956EE65F822018574E27@S11MAILD013N2.sh11.lan> Date: Fri, 9 Jan 2015 09:50:39 +0100 Message-ID: Subject: Re: C* throws OOM error despite use of automatic paging From: DuyHai Doan To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=089e0158ab3c455ff7050c3440f7 X-Virus-Checked: Checked by ClamAV on apache.org --089e0158ab3c455ff7050c3440f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What is the data size of the column family you're trying to fetch with paging ? Are you storing big blob or just primitive values ? On Fri, Jan 9, 2015 at 8:33 AM, Mohammed Guller wrote: > Hi =E2=80=93 > > > > We have an ETL application that reads all rows from Cassandra (2.1.2), > filters them and stores a small subset in an RDBMS. Our application is > using Datastax=E2=80=99s Java driver (2.1.4) to fetch data from the C* no= des. Since > the Java driver supports automatic paging, I was under the impression tha= t > SELECT queries should not cause an OOM error on the C* nodes. However, ev= en > with just 16GB data on each nodes, the C* nodes start throwing OOM error = as > soon as the application starts iterating through the rows of a table. > > > > The application code looks something like this: > > > > Statement stmt =3D new SimpleStatement("SELECT x,y,z FROM > cf").setFetchSize(5000); > > ResultSet rs =3D session.execute(stmt); > > while (!rs.isExhausted()){ > > row =3D rs.one() > > process(row) > > } > > > > Even after we reduced the page size to 1000, the C* nodes still crash. C* > is running on M3.xlarge machines (4-cores, 15GB). We manually increased t= he > heap size to 8GB just to see how much heap C* consumes. With 10-15 minute= s, > the heap usage climbs up to 7.6GB. That does not make sense. Either > automatic paging is not working or we are missing something. > > > > Does anybody have insights as to what could be happening? Thanks. > > > > Mohammed > > > > > --089e0158ab3c455ff7050c3440f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What is the data size of the column family you're tryi= ng to fetch with paging ? Are you storing big blob or just primitive values= ?

On Fri, J= an 9, 2015 at 8:33 AM, Mohammed Guller <mohammed@glassbeam.com>= ; wrote:

Hi =E2=80=93

=C2=A0

We have an ETL application that reads all rows from = Cassandra (2.1.2), filters them and stores a small subset in an RDBMS. Our = application is using Datastax=E2=80=99s Java driver (2.1.4) to fetch data f= rom the C* nodes. Since the Java driver supports automatic paging, I was under the impression that SELECT queries should no= t cause an OOM error on the C* nodes. However, even with just 16GB data on = each nodes, the C* nodes start throwing OOM error as soon as the applicatio= n starts iterating through the rows of a table.

=C2=A0

The application code looks something like this:

=C2=A0

Statement stmt =3D new SimpleStatement("SELECT = x,y,z FROM cf").setFetchSize(5000);

ResultSet rs =3D session.execute(stmt);

while (!rs.isExhausted()){

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 row =3D rs.one()

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 process(row)

}

=C2=A0

Even after we reduced the page size to 1000, the C* = nodes still crash. C* is running on M3.xlarge machines (4-cores, 15GB). We = manually increased the heap size to 8GB just to see how much heap C* consum= es. With 10-15 minutes, the heap usage climbs up to 7.6GB. That does not make sense. Either automatic paging is n= ot working or we are missing something.

=C2=A0

Does anybody have insights as to what could be happe= ning? Thanks.<= /font>

=C2=A0

Mohammed

=C2=A0

=C2=A0


--089e0158ab3c455ff7050c3440f7--