Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 27 Feb 2017 22:06:45 +0000 (UTC)
From: "Jeff Jirsa (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13044733.1487661682000.10725.1488233205438@Atlassian.JIRA>
In-Reply-To: <JIRA.13044733.1487661682000@Atlassian.JIRA>
References: <JIRA.13044733.1487661682000@Atlassian.JIRA> <JIRA.13044733.1487661682851@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13241) Lower default
 chunk_length_in_kb from 64kb to 4kb
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 27 Feb 2017 22:06:53 -0000


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

Jeff Jirsa commented on CASSANDRA-13241:
----------------------------------------

{quote}
Can the increased offheap requirements be expressed in a formula?
{quote}

[8 bytes per compression chunk|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/io/compress/CompressionMetadata.java#L172-L205]. 4x as many chunks = 4x as much offheap required to store them. AFAIK, it's a naive encoding. [~aweisberg] suggested in IRC that a more efficient encoding may make such a tradeoff much more tolerable. 


> Lower default chunk_length_in_kb from 64kb to 4kb
> -------------------------------------------------
>
>                 Key: CASSANDRA-13241
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13241
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Benjamin Roth
>
> Having a too low chunk size may result in some wasted disk space. A too high chunk size may lead to massive overreads and may have a critical impact on overall system performance.
> In my case, the default chunk size lead to peak read IOs of up to 1GB/s and avg reads of 200MB/s. After lowering chunksize (of course aligned with read ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s.
> The risk of (physical) overreads is increasing with lower (page cache size) / (total data size) ratio.
> High chunk sizes are mostly appropriate for bigger payloads pre request but if the model consists rather of small rows or small resultsets, the read overhead with 64kb chunk size is insanely high. This applies for example for (small) skinny rows.
> Please also see here:
> https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY
> To give you some insights what a difference it can make (460GB data, 128GB RAM):
> - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L
> - Disk throughput: https://cl.ly/2a0Z250S1M3c
> - This shows, that the request distribution remained the same, so no "dynamic snitch magic": https://cl.ly/3E0t1T1z2c0J


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)