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

Jordan West commented on CASSANDRA-15452:
-----------------------------------------

I backported the branch to 4.1 
[here|https://github.com/jrwest/cassandra/tree/jwest/15452-4.1-readahead] and 
ran tests on it:
 - 
[Java8|https://app.circleci.com/pipelines/github/jrwest/cassandra/186/workflows/b46f0e55-db2e-43e4-be9d-c88447034d45]
 - 
[Java11|https://app.circleci.com/pipelines/github/jrwest/cassandra/186/workflows/534fe8b7-cabb-461d-9614-2fcd70d3b156]

The only failures look like (unrelated, known) flakes and a container 
downloading configuration issue I am not familiar with but will take a closer 
look.

For the 5.0 branch, besides running tests the only thing still outstanding is 
to make it work with BTI format. BTI opens scanners differently than BIG format 
so we lose the read ahead buffer mode when its enabled, as currently 
implemented.

Also, right now the patch also applies to range scans. We should do some 
benchmarking to determine impact of that or limit it to compaction only.

> Improve disk access patterns during compaction and streaming
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-15452
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15452
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Local Write-Read Paths, Local/Compaction
>            Reporter: Jon Haddad
>            Assignee: Jordan West
>            Priority: Normal
>         Attachments: everyfs.txt, iostat-5.0-head.output, 
> iostat-5.0-patched.output, iostat-ebs-15452.png, iostat-ebs-head.png, 
> iostat-instance-15452.png, iostat-instance-head.png, results.txt, 
> sequential.fio, throughput-1.png, throughput.png
>
>
> On read heavy workloads Cassandra performs much better when using a low read 
> ahead setting.   In my tests I've seen an 5x improvement in throughput and 
> more than a 50% reduction in latency.  However, I've also observed that it 
> can have a negative impact on compaction and streaming throughput. It 
> especially negatively impacts cloud environments where small reads incur high 
> costs in IOPS due to tiny requests.
>  # We should investigate using POSIX_FADV_DONTNEED on files we're compacting 
> to see if we can improve performance and reduce page faults. 
>  # This should be combined with an internal read ahead style buffer that 
> Cassandra manages, similar to a BufferedInputStream but with our own 
> machinery.  This buffer should read fairly large blocks of data off disk at 
> at time.  EBS, for example, allows 1 IOP to be up to 256KB.  A considerable 
> amount of time is spent in blocking I/O during compaction and streaming. 
> Reducing the frequency we read from disk should speed up all sequential I/O 
> operations.
>  # We can reduce system calls by buffering writes as well, but I think it 
> will have less of an impact than the reads



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to