[ https://issues.apache.org/jira/browse/CASSANDRA-7031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13977707#comment-13977707 ]
Ryan McGuire commented on CASSANDRA-7031: ----------------------------------------- [~benedict] - here's some graphs: [write n=25000000 -key populate=1..10000 -rate threads=50 -mode thrift|http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.7031.populate_1_10000.json] [write n=25000000 -key populate=1..1000000 -rate threads=50 -mode thrift|http://riptano.github.io/cassandra_performance/graph_v3/graph.html?stats=stats.7031.populate_1_1000000.json] > 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)