cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (Commented) (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3623) use MMapedBuffer in CompressedSegmentedFile.getSegment
Date Tue, 27 Dec 2011 16:30:30 GMT


Vijay commented on CASSANDRA-3623:

" Also I took a look at the doc you have attached and it looks like test for 10000 is broken
because stress command line shows that you use -S 3000 instead of 10000."
I will fix it.

"Also as I mentioned before - you test on the different nodes on the working cluster, there
are side factors that could be affecting test results. Can you please explain why testing
performance on the working cluster is a good idea?"

How do you know it is a working cluster? They are individual machine isolated without any
network access to any other machine. There isnt anything which is been shared between those
machines (They are VM's from the diffrent servers than the results which i have ever published).
I created this test in different just to make a clean environment with cold cache (other option
is to reset the mmap which i dont want to do). 

I know you have your doubts but I am not that bad ;)
> use MMapedBuffer in CompressedSegmentedFile.getSegment
> ------------------------------------------------------
>                 Key: CASSANDRA-3623
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message