[
https://issues.apache.org/jira/browse/CASSANDRA-9533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569466#comment-14569466
]
Benedict commented on CASSANDRA-9533:
-------------------------------------
Well, the old behaviour really was to just ignore the property, since you can
at most flush concurrent_writers operations in a batch (typically 32), and it
would flush as soon as any messages that had arrived in a group had been
written to the buffer cache. So I cannot imagine a scenario in which the upper
limit would have been enforced.
We only updated its behaviour because the docs all described the new behaviour.
If we just remove the docs, we're pretty much good AFAICT, although I have
nothing against inverting the docs, and imposing an upper limit that isn't
enforced :)
Documentation exhibits:
{code}
# When in batch mode, Cassandra won't ack writes until the commit log
# has been fsynced to disk. It will wait up to
# commitlog_sync_batch_window_in_ms milliseconds for other writes, before
# performing the sync.
{code}
{quote}
Users familiar with PostgreSQL may note that commitlog_sync_period_in_ms and
commitlog_batch_window_in_ms correspond to the PostgreSQL settings of
wal_writer_delay and commit_delay, respectively.
{quote}
{quote}
commit_delay (integer)
Time delay between writing a commit record to the WAL buffer and flushing the
buffer out to disk, in microseconds. A nonzero delay can allow multiple
transactions to be committed with only one fsync() system call, if system load
is high enough that additional transactions become ready to commit within the
given interval. But the delay is just wasted if no other transactions become
ready to commit. Therefore, the delay is only performed if at least
commit_siblings other transactions are active at the instant that a server
process has written its commit record. The default is zero (no delay).
{quote}
> Make batch commitlog mode easier to tune
> ----------------------------------------
>
> Key: CASSANDRA-9533
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9533
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Fix For: 3.x
>
>
> As discussed in CASSANDRA-9504, 2.1 changed commitlog_sync_batch_window_in_ms
> from a maximum time to wait between fsync to the minimum time, so one must be
> very careful to keep it small enough that most writers aren't kept waiting.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
