[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-6764: Attachment: 6764.fix2.txt Take two > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino >Assignee: John Carrino > Fix For: 2.1 beta2 > > Attachments: 6764.fix.txt, 6764.fix2.txt, cassandra_6764_v2.patch, > cassandra_6764_v3.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict updated CASSANDRA-6764: Attachment: 6764.fix.txt This patch broke our unit tests: simple fix (attached) is to simply assert that we have the correct type of exception thrown, rather than the exception being taken as test failure. > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino >Assignee: John Carrino > Fix For: 2.1 beta2 > > Attachments: 6764.fix.txt, cassandra_6764_v2.patch, > cassandra_6764_v3.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Carrino updated CASSANDRA-6764: Attachment: cassandra_6764_v3.patch > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino > Fix For: 1.2.16 > > Attachments: cassandra_6764_v2.patch, cassandra_6764_v3.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Carrino updated CASSANDRA-6764: Attachment: cassandra_6764_v2.patch > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino > Fix For: 1.2.16 > > Attachments: cassandra_6764_v2.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Carrino updated CASSANDRA-6764: Attachment: (was: cassandra_6764_v1.patch) > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino > Fix For: 1.2.16 > > Attachments: cassandra_6764_v2.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CASSANDRA-6764) Using Batch commitlog_sync is slow and doesn't actually batch writes
[ https://issues.apache.org/jira/browse/CASSANDRA-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Carrino updated CASSANDRA-6764: Attachment: cassandra_6764_v1.patch > Using Batch commitlog_sync is slow and doesn't actually batch writes > > > Key: CASSANDRA-6764 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6764 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: John Carrino > Attachments: cassandra_6764_v1.patch > > > The assumption behind batch commit mode is that the client does it's own > batching and wants to wait until the write is durable before returning. The > problem is that the queue that cassandra uses under the covers only allows > for a single ROW (RowMutation) per thread (concurrent_writes). This means > that commitlog_sync_batch_window_in_ms should really be called sleep_between > each_concurrent_writes_rows_in_ms. > I assume the reason this slipped by for so long is that no one uses batch > mode, probably because people say "it's slow". We need durability so this > isn't an option. > However it doesn't need to be this slow. > Also, if you write a row that is larger than the commit log size it silently > (warn) fails to put it in the commit log. This is not ideal for batch mode. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
