[
https://issues.apache.org/jira/browse/CASSANDRA-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176071#comment-13176071
]
Vijay edited comment on CASSANDRA-3623 at 12/27/11 3:22 AM:
------------------------------------------------------------
Alright i think i found the the missing peace:
1) Plz reapply v2 from CASSANDRA-3611 (which also depends on CASSANDRA-3610)
2) Plz reapply v3 which has the mark() (this seem to be used by range slice and
Stress tool does it).
3) Plz set the CRC chance to 0.0 by update chance - We need to do this before
the SST's are created otherwise it wont take into effect. (update statements i
used is in the *.doc attached)
You might not see any diffrence if it is not set, because thats a big
bottleneck.
4) I used SunJDK for the test.
The Test Results are attached, let me know in case of any questions... the
performance seem to be better.
I Used stress test so we are in the same page, and when the Column size or the
range of columns to be fetched increases the performance gets better (rebuffers)
was (Author: vijay2...@yahoo.com):
Alright i think i found the the missing peace:
1) Plz reapply v2 from CASSANDRA-3611 (which also depends on CASSANDRA-3610)
2) Plz reapply v3 which has the mark() (this seem to be used by range slice and
Stress tool does it).
3) Plz set the CRC chance to 0.0 by update chance - We need to do this before
the SST's are created otherwise it wont take into effect. (update statements i
used is in the *.doc attached)
4) I used SunJDK for the test.
The Test Results are attached, let me know in case of any questions... the
performance seem to be better.
I Used stress test so we are in the same page, and when the Column size or the
range of columns to be fetched increases the performance gets better (rebuffers)
> 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-v2.patch,
> 0001-MMaped-Compression-segmented-file-v3.patch,
> 0001-MMaped-Compression-segmented-file.patch,
> 0002-tests-for-MMaped-Compression-segmented-file-v2.patch,
> 0002-tests-for-MMaped-Compression-segmented-file-v3.patch, CRC+MMapIO.xlsx,
> MMappedIO-Performance.docx
>
>
> 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
