[
https://issues.apache.org/jira/browse/CASSANDRA-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976547#comment-13976547
]
Benedict commented on CASSANDRA-7031:
-------------------------------------
The _worst_ latency is substantially reduced, which is down to waiting on the
commit log to catch up. It's possible the 99th/99.9th are increased due to
sharing the same disk, but notice the 95th percentile is lower also for both,
so it's only a slight spike in the 99th+99.9th for a substantial drop in the
max and the more common cases. Could simply be random noise from running on my
box, though. [~enigmacurry] perhaps you could kick off a simple test comparing
with and without this patch on the real cluster so we can see some pretty
graphs (keep populate range low so that commit log is a more visible component
though, preferably)?
> Increase default commit log total space + segment size
> ------------------------------------------------------
>
> Key: CASSANDRA-7031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7031
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Priority: Trivial
> Fix For: 2.1 beta2
>
> Attachments: 7031.txt
>
>
> I would like to increase the default commit log total space and segment size
> options for 64-bit JVMs:
> The current default of 1Gb and 32Mb is quite constrained and can have some
> (very minor) negative performance implications, for no major benefit:
> # 32Mb files are actually quite small, and if during the 10s interval we have
> completely filled multiple of them (quite easy) it would be more efficient to
> write fewer larger files, as we can issue fewer fsyncs and permit the OS to
> schedule the writes more efficiently. On my box this has a small but
> noticeable impact. Although I would expect on decent server hardware this
> would be smaller still, since we immediately drop the pages from cache on
> writing there isn't a great deal of advantage to keeping the files so small.
> The only advantage I can see is that during a drop KS/CF or other event that
> forces log rollover we're wasting less space until log recycling. 128-256Mb
> are modest increases that seem more appropriate to me.
> # 1Gb is too small for the default total log space. We can find that we force
> memtable flushes as a result of log utilisation instead of memtable occupancy
> quite often (esp. as a result of increased effective memtable space from
> recent improvements), especially on machines with more addressable memory. I
> suggest 8Gb as a minimum. The only disadvantage of having more log data is
> that replay on restart may be slightly slower, but since most of the events
> will be ignored it should be relatively benign, and I would rather take the
> penalty on startup instead of during running, no matter how small the running
> penalty.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
