cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-5863) In process (uncompressed) page cache
Date Sun, 24 Apr 2016 08:54:13 GMT

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

Benedict edited comment on CASSANDRA-5863 at 4/24/16 8:54 AM:
--------------------------------------------------------------

bq. I've double checked with multiple familiar people that most of the modern/popular filesystems
(NTFS, ext*, xfs etc.) already have support for that

It's worth double checking what that support entails - in XFS (since I happen to have recently
read the spec), such a gap would be represented by introducing a b+-tree, rather than a single-continuous
allocation (on the assumption contiguous space was available on disk in the location of the
first inode).  This could result in multiple levels of inode, such that a random seek into
the file (our usual modus operandi) could incur many more disk accesses than previously was
the case.

(Obviously these would more likely be cacheable by the OS, so it mightn't be a major problem;
just worth considering)


was (Author: benedict):
bq. I've double checked with multiple familiar people that most of the modern/popular filesystems
(NTFS, ext*, xfs etc.) already have support for that

It's worth double checking what that support entails - in XFS (since I happen to have recently
read the spec), such a gap would be represented by introducing a b+-tree, rather than a single-continuous
allocation (on the assumption contiguous space was available on disk in the location of the
first inode).  This could result in multiple levels of inode, such that a random seek into
the file (our usual modus operandi) could incur many more disk accesses than previously was
the case.

> In process (uncompressed) page cache
> ------------------------------------
>
>                 Key: CASSANDRA-5863
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5863
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: T Jake Luciani
>            Assignee: Branimir Lambov
>              Labels: performance
>             Fix For: 3.x
>
>
> Currently, for every read, the CRAR reads each compressed chunk into a byte[], sends
it to ICompressor, gets back another byte[] and verifies a checksum.  
> This process is where the majority of time is spent in a read request.  
> Before compression, we would have zero-copy of data and could respond directly from the
page-cache.
> It would be useful to have some kind of Chunk cache that could speed up this process
for hot data, possibly off heap.



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

Mime
View raw message