[
https://issues.apache.org/jira/browse/CASSANDRA-8177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14183783#comment-14183783
]
Sean Bridges edited comment on CASSANDRA-8177 at 10/25/14 12:18 AM:
--------------------------------------------------------------------
{quote}
My guess for sequential repair generating lots of IO is that, when reading from
snapshot, it is hitting disk for each snapshot SSTable to read its bloom
filters, index files etc
{quote}
When you snapshot you are hardlinking the old and original sstables, they are
the same files, so the os cache shouldn't be the difference
was (Author: sgbridges):
{quote}
My guess for sequential repair generating lots of IO is that, when reading from
snapshot, it is hitting disk for each snapshot SSTable to read its bloom
filters, index files etc
{quote}
When you snapshot you are hardlinking the old and original sstables, they are
the same file, so the os cache shouldn't be the difference
> sequential repair is much more expensive than parallel repair
> -------------------------------------------------------------
>
> Key: CASSANDRA-8177
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8177
> Project: Cassandra
> Issue Type: Bug
> Reporter: Sean Bridges
> Assignee: Yuki Morishita
> Attachments: cassc-week.png, iostats.png
>
>
> This is with 2.0.10
> The attached graph shows io read/write throughput (as measured with iostat)
> when doing repairs.
> The large hump on the left is a sequential repair of one node. The two much
> smaller peaks on the right are parallel repairs.
> This is a 3 node cluster using vnodes (I know vnodes on small clusters isn't
> recommended). Cassandra reports load of 40 gigs.
> We noticed a similar problem with a larger cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
