cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8630) Faster sequential IO (on compaction, streaming, etc)
Date Wed, 19 Aug 2015 09:16:47 GMT


Stefania commented on CASSANDRA-8630:

The boundaries are gone. They are serialized in the summary but here we don't need to keep
backward compatibility as it will be recreated on the flight, correct?

bq. In our SegmentedFileBuilder we can just map a segment on-demand (i.e. whenever we build
a SegmentedFile from it, we map any segments we need). We can stick with the TreeMap<Long,
ByteBuffer> (although tbh, I'd prefer we switch to a paired long[] and ByteBuffer[], and
perform binarySearch on the former to key into the latter), it's just built with arbitrary

I see what you mean now. So the segments will belong to the builder like the channel. The
reason I chose the tree map was to avoid changing the CompressedRAR but it shouldn't take
long to change the map to an array of (Long, ByteBuffer) pairs. You prefer the binary search
due to the cost of the map?

> Faster sequential IO (on compaction, streaming, etc)
> ----------------------------------------------------
>                 Key: CASSANDRA-8630
>                 URL:
>             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<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

View raw message