cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8630) Faster sequential IO (on compaction, streaming, etc)
Date Mon, 31 Aug 2015 21:36:48 GMT

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

Benedict commented on CASSANDRA-8630:
-------------------------------------

I've pushed a version with a few suggestions, and a bug fix, in decreasing order of note:

* {{MappedRegions.close}} now always calls {{channel.close}}, and returns any error thrown
by it
* Removed the {{readBytes}} method entirely, since it doesn't appear to offer anything {{readFully}}
and, transitively, {{ByteBufferUtil.read}}, doesn't (correct me if I'm wrong...?)
** Simplified {{readFully}} while we're here
* Moved some of the {{close}} methods to the new {{Throwables.perform}} API to make their
behaviour more robust
* Replaced {{AssertionError}} with {{UnsupportedOperationException}} where suitable
* Removed {{IOException}} from the throws clause of close, so no need to introduce the new
{{closeQuietly}} calls
* Removed the (as commented in TODO) unnecessary {{BufferedSegmentedFile.createReader}}
* {{ChecksummedDataInput}} extends {{RandomAccessReader.RandomAccessReaderWithOwnChannel}}
* Removed / standardised EOF behaviour for RAR and CRAR

Let me know what you think, and we can squash/commit.

bq.  how picky the platform is about timing on DirectBuffer unmapping etc.

[~JoshuaMcKenzie]: is this wrt file rename / deletion, or wrt closing the channel? My understanding
was the former, in which case any such problem would indicate a severe bug with 2.2+ (unless
snapshots are involved, but don't think we even try to handle that), and shouldn't be affected
by this patch. Absolutely no harm running the tests, of course.

> Faster sequential IO (on compaction, streaming, etc)
> ----------------------------------------------------
>
>                 Key: CASSANDRA-8630
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8630
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core, Tools
>            Reporter: Oleg Anastasyev
>            Assignee: Stefania
>              Labels: compaction, performance
>             Fix For: 3.x
>
>         Attachments: 8630-FasterSequencialReadsAndWrites.txt, cpu_load.png, flight_recorder_001_files.tar.gz,
flight_recorder_002_files.tar.gz, mmaped_uncomp_hotspot.png
>
>
> When node is doing a lot of sequencial IO (streaming, compacting, etc) a lot of CPU is
lost in calls to RAF's int read() and DataOutputStream's write(int).
> This is because default implementations of readShort,readLong, etc as well as their matching
write* are implemented with numerous calls of byte by byte read and write. 
> This makes a lot of syscalls as well.
> A quick microbench shows than just reimplementation of these methods in either way gives
8x speed increase.
> A patch attached implements RandomAccessReader.read<Type> and SequencialWriter.write<Type>
methods in more efficient way.
> I also eliminated some extra byte copies in CompositeType.split and ColumnNameHelper.maxComponents,
which were on my profiler's hotspot method list during tests.
> A stress tests on my laptop show that this patch makes compaction 25-30% faster  on uncompressed
sstables and 15% faster for compressed ones.
> A deployment to production shows much less CPU load for compaction. 
> (I attached a cpu load graph from one of our production, orange is niced CPU load - i.e.
compaction; yellow is user - i.e. not compaction related tasks)



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

Mime
View raw message