Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 8 Apr 2016 05:17:25 +0000 (UTC)
From: "Mattias W (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12957018.1460063447000.171467.1460092645443@Atlassian.JIRA>
In-Reply-To: <JIRA.12957018.1460063447000@Atlassian.JIRA>
References: <JIRA.12957018.1460063447000@Atlassian.JIRA>
 <JIRA.12957018.1460063447227@arcas>
Subject: [jira] [Updated] (CASSANDRA-11528) Server Crash when select returns
 more than a few hundred rows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-11528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mattias W updated CASSANDRA-11528:
----------------------------------
    Description: 
While implementing a dump procedure, which did "select * from" from one table at a row, I instantly kill the server. A simple 
{noformat}select count(*) from {noformat} 
also kills it. For a while, I thought the size of blobs were the cause

I also try to only have a unique id as partition key, I was afraid a single partition got too big or so, but that didn't change anything

It happens every time, both from Java/Clojure and from DevCenter.

I looked at the logs at C:\Program Files\DataStax-DDC\logs, but the crash is so quick, so nothing is recorded there.

There is a Java-out-of-memory in the logs, but that isn't from the time of the crash.

It only happens for one table, it only has 15000 entries, but there are blobs and byte[] stored there, size between 100kb - 4Mb. Total size for that table is about 6.5 GB on disk.

I made a workaround by doing many small selects instead, each only fetching 100 rows.

Is there a setting a can set to make the system log more eagerly, in order to at least get a stacktrace or similar, that might help you.

It is the prun_srv that dies. Restarting the NT service makes Cassandra run again

  was:
While implementing a dump procedure, which did "select * from" from one table at a row, I instantly kill the server. A simple "select count(*) from"  also kills it. For a while, I thought the size of blobs were the cause

I also try to only have a unique id as partition key, I was afraid a single partition got too big or so, but that didn't change anything

It happens every time, both from Java/Clojure and from DevCenter.

I looked at the logs at C:\Program Files\DataStax-DDC\logs, but the crash is so quick, so nothing is recorded there.

There is a Java-out-of-memory in the logs, but that isn't from the time of the crash.

It only happens for one table, it only has 15000 entries, but there are blobs and byte[] stored there, size between 100kb - 4Mb. Total size for that table is about 6.5 GB on disk.

I made a workaround by doing many small selects instead, each only fetching 100 rows.

Is there a setting a can set to make the system log more eagerly, in order to at least get a stacktrace or similar, that might help you.

It is the prun_srv that dies. Restarting the NT service makes Cassandra run again


> Server Crash when select returns more than a few hundred rows
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-11528
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11528
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: windows 7, 8 GB machine
>            Reporter: Mattias W
>             Fix For: 3.3
>
>         Attachments: datastax_ddc_server-stdout.2016-04-07.log
>
>
> While implementing a dump procedure, which did "select * from" from one table at a row, I instantly kill the server. A simple 
> {noformat}select count(*) from {noformat} 
> also kills it. For a while, I thought the size of blobs were the cause
> I also try to only have a unique id as partition key, I was afraid a single partition got too big or so, but that didn't change anything
> It happens every time, both from Java/Clojure and from DevCenter.
> I looked at the logs at C:\Program Files\DataStax-DDC\logs, but the crash is so quick, so nothing is recorded there.
> There is a Java-out-of-memory in the logs, but that isn't from the time of the crash.
> It only happens for one table, it only has 15000 entries, but there are blobs and byte[] stored there, size between 100kb - 4Mb. Total size for that table is about 6.5 GB on disk.
> I made a workaround by doing many small selects instead, each only fetching 100 rows.
> Is there a setting a can set to make the system log more eagerly, in order to at least get a stacktrace or similar, that might help you.
> It is the prun_srv that dies. Restarting the NT service makes Cassandra run again


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)