Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <438905.386511282016665765.JavaMail.jira@thor>
Date: Mon, 16 Aug 2010 23:44:25 -0400 (EDT)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-1214) Force linux to not swap the JVM
In-Reply-To: <18782334.103051277068944262.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899260#action_12899260 ] 

Jonathan Ellis commented on CASSANDRA-1214:
-------------------------------------------

Ugh, that's a pain.  (JFFI is also LGPL.)

It's not a deal breaker for us since we'd like to use it for basically optimizations... ASF says "LGPL v2.1-licensed works must not be included in Apache products, although they may be listed as system requirements or distributed elsewhere as optional works" so that would be workable if sub-optimal.

Curious if Peter things we're going to have to go raw JNI for fadvise on compactions.  If we're going to have to bite that bullet anyway then JNA gets less interesting.

> Force linux to not swap the JVM
> -------------------------------
>
>                 Key: CASSANDRA-1214
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1214
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: James Golick
>             Fix For: 0.6.5
>
>         Attachments: mlockall-jna.patch.txt, Read Throughput with mmap.jpg, trunk-1214.txt
>
>
> The way mmap()'d IO is handled in cassandra is dangerous. It allocates potentially massive buffers without any care for bounding the total size of the program's buffers. As the node's dataset grows, this *will* lead to swapping and instability.
> This is a dangerous and wrong default for a couple of reasons.
> 1) People are likely to test cassandra with the default settings. This issue is insidious because it only appears when you have sufficient data in a certain node, there is absolutely no way to control it, and it doesn't at all respect the memory limits that you give to the JVM.
> That can all be ascertained by reading the code, and people should certainly do their homework, but nevertheless, cassandra should ship with sane defaults that don't break down when you cross some magic unknown threshold.
> 2) It's deceptive. Unless you are extremely careful with capacity planning, you will get bit by this. Most people won't really be able to use this in production, so why get them excited about performance that they can't actually have?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.