Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.
The "StorageConfiguration" page has been changed by JonHermes. http://wiki.apache.org/cassandra/StorageConfiguration?action=diff&rev1=53&rev2=54 -------------------------------------------------- Defaults are: '/var/lib/cassandra/commitlog', '/var/lib/cassandra/data', and '/var/lib/cassandra/saved_caches' respectively. - * '''concurrent_reads''' and '''concurrent_writes''', '''commitlog_sync''' and '''commitlog_sync_period_in_ms''' + * '''concurrent_reads''' and '''concurrent_writes''' Unlike most systems, in Cassandra writes are faster than reads, so you can afford more of those in parallel. A good rule of thumb is 4 concurrent_reads per processor core. It's unwise to adjust the {{{concurrent_writes}}} until you have a a performance problem to address. In general, though, for a dedicated cluster it should exceed somewhat the number of cpu-cores on the ring + Defaults are: '8' c. reads, and '32' c. writes. + + * '''commitlog_rotation_threshold_in_mb''', '''commitlog_sync''', '''commitlog_sync_period_in_ms''', and '''commitlog_sync_batch_window_in_ms''' + The rotation threshold determines how often a new commitlog segment is created. This number is generally never changed, but can be reduced if small amount of memory need to be squeezed from the system. + - {{{CommitLogSync}}} may be either "periodic" or "batch." When in batch mode, Cassandra won't ack writes until the commit log has been fsynced to disk. It will wait up to {{{CommitLogSyncBatchWindowInMS}}} milliseconds for other writes, before performing the sync. + {{{CommitLogSync}}} may be either "periodic" or "batch". When in batch mode, Cassandra won't ack writes until the commit log has been fsynced to disk. It will wait up to {{{CommitLogSyncBatchWindowInMS}}} milliseconds for other writes, before performing the sync. - This is less necessary in Cassandra than in traditional databases since replication reduces the odds of losing data from a failure after writing the log entry but before it actually reaches the disk. So the other option is "timed," where writes may be acked immediately and the {{{CommitLog}}} is simply synced every {{{CommitLogSyncPeriodInMS}}} milliseconds. + This is less necessary in Cassandra than in traditional databases since replication reduces the odds of losing data from a failure after writing the log entry but before it actually reaches the disk. So the other option is "periodic", where writes may be acked immediately and the {{{CommitLog}}} is simply synced every {{{CommitLogSyncPeriodInMS}}} milliseconds. Usually the default of 1000ms is fine; increase it only if the CommitLog PendingTasks backlog in jmx shows that you are frequently scheduling a second sync while the first has not yet been processed. - Interval at which to perform syncs of the {{{CommitLog}}} in periodic mode. Usually the default of 1000ms is fine; increase it only if the CommitLog PendingTasks backlog in jmx shows that you are frequently scheduling a second sync while the first has not yet been processed. - - Defaults are: '8' c. reads, '32' c. writes, 'periodic' sync, '10000' ms between syncs. + Defaults are: '128'mb commitlog size, 'periodic' sync, '10000' ms between syncs. * '''disk_access_mode'''
