Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 31 Jul 2015 15:54:05 +0000 (UTC)
From: "Joshua McKenzie (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12850472.1438303981000.341001.1438358045400@Atlassian.JIRA>
In-Reply-To: <JIRA.12850472.1438303981000@Atlassian.JIRA>
References: <JIRA.12850472.1438303981000@Atlassian.JIRA>
 <JIRA.12850472.1438303981334@arcas>
Subject: [jira] [Commented] (CASSANDRA-9946) use ioprio_set on compaction
 threads by default instead of manually throttling
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Joshua McKenzie commented on CASSANDRA-9946:
--------------------------------------------

I think the right Windows analog would be [SetThreadPriority|https://msdn.microsoft.com/en-us/library/windows/desktop/ms686277(v=vs.85).aspx], specifically using THREAD_MODE_BACKGROUND_BEGIN. I'm assuming we can use something like [GetCurrentThread|https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx] via jna and use the HANDLE from there but I'd have to tinker with it to see how it behaves; for some reason I have a recollection of getting tid's being dicey w/regards to java's internal threading model.

> use ioprio_set on compaction threads by default instead of manually throttling
> ------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9946
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9946
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Ariel Weisberg
>             Fix For: 3.x
>
>
> Compaction throttling works as designed, but it has two drawbacks:
> * it requires manual tuning to choose the "right" value for a given machine
> * it does not allow compaction to "burst" above its limit if there is additional i/o capacity available while there are less application requests to serve
> Using ioprio_set instead solves both of these problems.


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