Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 5 Aug 2015 21:21:08 +0000 (UTC)
From: "Ariel Weisberg (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12834736.1433264647000.382136.1438809668672@Atlassian.JIRA>
In-Reply-To: <JIRA.12834736.1433264647000@Atlassian.JIRA>
References: <JIRA.12834736.1433264647000@Atlassian.JIRA>
 <JIRA.12834736.1433264647052@arcas>
Subject: [jira] [Commented] (CASSANDRA-9533) Make batch commitlog mode
 easier to tune
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ariel Weisberg commented on CASSANDRA-9533:
-------------------------------------------

OK round #2. This just means that if there is work waiting to sync it starts syncing immediately as long as there is stuff pending sync. So you get smart batching?

Sounds reasonable for a proper setup, but if you point this at a consumer SSD is it just going to chew through erase blocks all day long as writes trickle in?

I am +1 on this. I am just probing for a corner case where it is undesirable.

> Make batch commitlog mode easier to tune
> ----------------------------------------
>
>                 Key: CASSANDRA-9533
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9533
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Benedict
>             Fix For: 3.x
>
>
> As discussed in CASSANDRA-9504, 2.1 changed commitlog_sync_batch_window_in_ms from a maximum time to wait between fsync to the minimum time, so one must be very careful to keep it small enough that most writers aren't kept waiting.


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