[ https://issues.apache.org/jira/browse/CASSANDRA-3623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193402#comment-13193402 ]
Vijay commented on CASSANDRA-3623: ---------------------------------- Hi Jonathan, The env which i was testing was on XFS and NOOP scheduler (with JVM heap of 12/2). I also have a lot of memory (70G) to spare on those boxes... Having said that I am not sure if it is was just me who will be benefited by this patch... may be a 3rd opinion might help. > 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