cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13530) GroupCommitLogService
Date Tue, 19 Sep 2017 15:47:00 GMT

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

Ariel Weisberg commented on CASSANDRA-13530:
--------------------------------------------

I've run into a different justification for this change. Reducing P/E cycles on SSDs that
don't have a non-volatile write cache sitting in front.

So we don't need to justify having this functionality with just performance and batch would
still do the wrong thing even if it was faster.

Just a heads up this can only go into trunk. 2.2,  3.0, and 3.11 are bug fix only. So in 2.2,
3.0 and 3.11 we could fix batch by ignoring the value commitlog_sync_batch_window_in_ms and
updating the documentation in cassandra.yaml as well as mentioning that it's deprecated.

So on to reviewing the details.

* This needs a unit test exercising the new commit log configuration, as well as acceptable
and not acceptable configuration values (0, negative, largest value, smallest value)
* How about we fix commitlog_sync_batch_window_in_ms by 100% ignoring the value. We can't
change the configuration behavior of batch (people won't update their config) but we can fix
the broken implementation. Also mark it as deprecated in the docs so we can remove it later.
* Then use commitlog_sync_group_window_in_ms to configure the batch commit log service. If
unset, batch works the way it does today. If set then it implements the fixed grouping behavior.
Document in cassandra.yaml appropriately.
* Alternatively add a new commit log implementation (group) that can do both group and batch
and deprecate batch commit log. Eventually we will converge on one implementation with consistent
configuration naming.


> GroupCommitLogService
> ---------------------
>
>                 Key: CASSANDRA-13530
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13530
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Yuji Ito
>            Assignee: Yuji Ito
>             Fix For: 2.2.x, 3.0.x, 3.11.x
>
>         Attachments: groupAndBatch.png, groupCommit22.patch, groupCommit30.patch, groupCommit3x.patch,
groupCommitLog_noSerial_result.xlsx, groupCommitLog_result.xlsx, GuavaRequestThread.java,
MicroRequestThread.java
>
>
> I propose a new CommitLogService, GroupCommitLogService, to improve the throughput when
lots of requests are received.
> It improved the throughput by maximum 94%.
> I'd like to discuss about this CommitLogService.
> Currently, we can select either 2 CommitLog services; Periodic and Batch.
> In Periodic, we might lose some commit log which hasn't written to the disk.
> In Batch, we can write commit log to the disk every time. The size of commit log to write
is too small (< 4KB). When high concurrency, these writes are gathered and persisted to
the disk at once. But, when insufficient concurrency, many small writes are issued and the
performance decreases due to the latency of the disk. Even if you use SSD, processes of many
IO commands decrease the performance.
> GroupCommitLogService writes some commitlog to the disk at once.
> The patch adds GroupCommitLogService (It is enabled by setting `commitlog_sync` and `commitlog_sync_group_window_in_ms`
in cassandra.yaml).
> The difference from Batch is just only waiting for the semaphore.
> By waiting for the semaphore, some writes for commit logs are executed at the same time.
> In GroupCommitLogService, the latency becomes worse if the there is no concurrency.
> I measured the performance with my microbench (MicroRequestThread.java) by increasing
the number of threads.The cluster has 3 nodes (Replication factor: 3). Each nodes is AWS EC2
m4.large instance + 200IOPS io1 volume.
> The result is as below. The GroupCommitLogService with 10ms window improved update with
Paxos by 94% and improved select with Paxos by 76%.
> h6. SELECT / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|192|103|
> |2|163|212|
> |4|264|416|
> |8|454|800|
> |16|744|1311|
> |32|1151|1481|
> |64|1767|1844|
> |128|2949|3011|
> |256|4723|5000|
> h6. UPDATE / sec
> ||\# of threads||Batch 2ms||Group 10ms||
> |1|45|26|
> |2|39|51|
> |4|58|102|
> |8|102|198|
> |16|167|213|
> |32|289|295|
> |64|544|548|
> |128|1046|1058|
> |256|2020|2061|



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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


Mime
View raw message