cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cassandra Wiki] Update of "StorageConfiguration" by JonHermes
Date Mon, 01 Nov 2010 21:51:32 GMT
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'''
  

Mime
View raw message