[jira] [Commented] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.
[ https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225427#comment-14225427 ] Ryan McGuire commented on CASSANDRA-8342: - http://riptano.github.io/cassandra_performance/graph_v4/graph.html?stats=stats.8342.json Definitely agree that increasing it doesn't improve things, but not seeing much of a dropoff either. Per Jonathan's suggestion, this test was all in memory though. Rereading the guidance text in the yaml would seem to suggest testing this with a load larger, no? Remove historical guidance for concurrent reader and writer tunings. Key: CASSANDRA-8342 URL: https://issues.apache.org/jira/browse/CASSANDRA-8342 Project: Cassandra Issue Type: Improvement Reporter: Matt Stump Assignee: Ryan McGuire The cassandra.yaml and documentation provide guidance on tuning concurrent readers or concurrent writers to system resources (cores, spindles). Testing performed by both myself and customers demonstrates no benefit for thread pool sizes above 64 in size, and for thread pools greater than 128 in size a decrease in throughput. This is due to thread scheduling and synchronization bottlenecks within Cassandra. Additionally, for lower end systems reducing these thread pools provides very little benefit because the bottleneck is typically moved to either IO or CPU. I propose that we set the default value to 64 (current default is 32), and remove all guidance/recommendations regarding tuning. This recommendation may change in 3.0, but that would require further experimentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.
[ https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223342#comment-14223342 ] Jonathan Ellis commented on CASSANDRA-8342: --- [~enigmacurry] as a sanity check can you stress i2.8xl reads at 64 128 and 256 concurrent read threads? Remove historical guidance for concurrent reader and writer tunings. Key: CASSANDRA-8342 URL: https://issues.apache.org/jira/browse/CASSANDRA-8342 Project: Cassandra Issue Type: Improvement Reporter: Matt Stump The cassandra.yaml and documentation provide guidance on tuning concurrent readers or concurrent writers to system resources (cores, spindles). Testing performed by both myself and customers demonstrates no benefit for thread pool sizes above 64 in size, and for thread pools greater than 128 in size a decrease in throughput. This is due to thread scheduling and synchronization bottlenecks within Cassandra. Additionally, for lower end systems reducing these thread pools provides very little benefit because the bottleneck is typically moved to either IO or CPU. I propose that we set the default value to 64 (current default is 32), and remove all guidance/recommendations regarding tuning. This recommendation may change in 3.0, but that would require further experimentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.
[ https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223618#comment-14223618 ] Ryan McGuire commented on CASSANDRA-8342: - Do we only care about testing the tweak on reads? I'll start it tomorrow during the day, that instance is $7/hr (!) so requires some babysitting time. Remove historical guidance for concurrent reader and writer tunings. Key: CASSANDRA-8342 URL: https://issues.apache.org/jira/browse/CASSANDRA-8342 Project: Cassandra Issue Type: Improvement Reporter: Matt Stump Assignee: Ryan McGuire The cassandra.yaml and documentation provide guidance on tuning concurrent readers or concurrent writers to system resources (cores, spindles). Testing performed by both myself and customers demonstrates no benefit for thread pool sizes above 64 in size, and for thread pools greater than 128 in size a decrease in throughput. This is due to thread scheduling and synchronization bottlenecks within Cassandra. Additionally, for lower end systems reducing these thread pools provides very little benefit because the bottleneck is typically moved to either IO or CPU. I propose that we set the default value to 64 (current default is 32), and remove all guidance/recommendations regarding tuning. This recommendation may change in 3.0, but that would require further experimentation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
