[
https://issues.apache.org/jira/browse/CASSANDRA-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174902#comment-13174902
]
Vijay commented on CASSANDRA-3623:
----------------------------------
Hi Pavel, Write()? i dont understand that part. (Are we talking about dirty
pages?)
Sure if you have flash drives or Disc's which are faster than memory there wont
be any benefits but in general it increases the IO throughput and helps with
the latency. Yes the copying will be unavoidable and it is no different than
the existing disc reads we have to read the blocks to uncompress it, hence it
isn't drastically different you are going to do IO for the skiped bytes in both
the cases, and if it is mmaped it will atleast have better performance (if you
consider it as a hot compressed block and it is cached) as it might be from
memory. In our environment going to Disc (AWS) is really bad specially with the
amount of disc activity will compressed CF do makes it unusable in the current
state.
BTW: i think i can remove copying in reBuffer(). if thats the only consern. I
have to test it to see if it will be safe.
> use MMapedBuffer in CompressedSegmentedFile.getSegment
> ------------------------------------------------------
>
> Key: CASSANDRA-3623
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3623
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Affects Versions: 1.1
> Reporter: Vijay
> Assignee: Vijay
> Labels: compression
> Fix For: 1.1
>
> Attachments: 0001-MMaped-Compression-segmented-file.patch
>
>
> CompressedSegmentedFile.getSegment seem to open a new file and doesnt seem to
> use the MMap and hence a higher CPU on the nodes and higher latencies on
> reads.
> This ticket is to implement the TODO mentioned in CompressedRandomAccessReader
> // TODO refactor this to separate concept of "buffer to avoid lots of read()
> syscalls" and "compression buffer"
> but i think a separate class for the Buffer will be better.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
