Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 22 Apr 2016 13:29:13 +0000 (UTC)
From: "Marcus Eriksson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12960433.1461177203000.8286.1461331753436@Atlassian.JIRA>
In-Reply-To: <JIRA.12960433.1461177203000@Atlassian.JIRA>
References: <JIRA.12960433.1461177203000@Atlassian.JIRA>
 <JIRA.12960433.1461177203958@arcas>
Subject: [jira] [Commented] (CASSANDRA-11623) Compactions w/ Short Rows
 Spending Time in getOnDiskFilePointer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Marcus Eriksson commented on CASSANDRA-11623:
---------------------------------------------

Btw, if the {{getOnDiskFilePointer}} is expensive, we should probably investigate if we can remove that {{seekToChunkStart}} call

> Compactions w/ Short Rows Spending Time in getOnDiskFilePointer
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-11623
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11623
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Tom Petracca
>            Priority: Minor
>         Attachments: compactiontask_profile.png
>
>
> Been doing some performance tuning and profiling of my cassandra cluster and noticed that compaction speeds for my tables that I know to have very short rows were going particularly slowly.  Profiling shows a ton of time being spent in BigTableWriter.getOnDiskFilePointer(), and attaching strace to a CompactionTask shows that a majority of time is being spent lseek (called by getOnDiskFilePointer), and not read or write.
> Going deeper it looks like we call getOnDiskFilePointer each row (sometimes multiple times per row) in order to see if we've reached our expected sstable size and should start a new writer.  This is pretty unnecessary.


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