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 FlipKromer. The comment on this change is: Changed confusing descriptions for concurrent_writes and disk_access_mode to match recommendations from driftx and benblack. http://wiki.apache.org/cassandra/StorageConfiguration?action=diff&rev1=41&rev2=42 -------------------------------------------------- ||''-Dcassandra.config=file:///home/me/external-local-cassandra.yaml'' ||loads a local configuration file that is not located in the cassandra classpath. || + + == "Where are my keyspaces?" == LiveSchemaUpdates. You can load the schema once by using: {{{ bin/schematool HOST PORT import }}} - = Config Overview = Not going to cover every value, just the interesting ones. When in doubt, check out the comments on the default cassandra.yaml as they're well documented there. @@ -49, +50 @@ * '''concurrent_reads''' and '''concurrent_writes''', '''commitlog_sync''' and '''commitlog_sync_period_in_ms''' - 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. Increase {{{concurrent_writes}}} to the number of clients writing at once if you use commitlog_sync. + 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 {{{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. @@ -61, +62 @@ * '''disk_access_mode''' + In 0.7, the default 'mmap_index_only' is recommended. For version 0.6, the default is 'auto', but you're better off beginning your tuning with this set to 'standard'. Don't otherwise touch this dial until you've read and understood the [[http://issues.apache.org/jira/browse/CASSANDRA-1214|discussion in CASSANDRA-1214]], and examined your [[CassandraHardware|swap and VM configuration]]. - The options are: 'auto', 'mmap', 'mmap_index_only', and 'standard'. mmapped i/o is substantially faster, but only practical on a 64bit machine (which notably does not include EC2 "small" instances) or relatively small datasets. "auto", the safe choice, will enable mmapping on a 64bit JVM. Other values are "mmap", "mmap_index_only" (which may allow you to get part of the benefits of mmap on a 32bit machine by mmapping only index files) and "standard". (The buffer size settings that follow only apply to standard, non-mmapped i/o.) - - Default is: 'auto'. * '''dynamic_snitch''' and '''endpoint_snitch''' @@ -81, +80 @@ * '''listen_address''' - Commenting out this property leaves it up to {{{InetAddress.getLocalHost()}}}. This will always do the Right Thing *if* the node is properly configured (hostname, name resolution, etc), and the Right Thing is to use the address associated with the hostname (it might not be). + Commenting out this property leaves it up to {{{InetAddress.getLocalHost()}}}. This will always do the Right Thing *if* the node is properly configured (hostname, name resolution, etc), and the Right Thing is to use the address associated with the hostname (it might not be: on cloud services you should ensure the private interface is used). Default is: 'localhost'. This must be changed for other nodes to contact this node. * '''memtable_flush_after_mins''', '''memtable_operations_in_millions''', and '''memtable_throughput_in_mb''' - The maximum time to leave a dirty memtable unflushed. (While any affected columnfamilies have unflushed data from a commit log segment, that segment cannot be deleted.) This needs to be large enough that it won't cause a flush storm of all your memtables flushing at once because none has hit the size or count thresholds yet. For production, a larger value such as 1440 is recommended. + '''memtable_flush_after_mins: '''The maximum time to leave a dirty memtable unflushed. (While any affected columnfamilies have unflushed data from a commit log segment, that segment cannot be deleted.) This needs to be large enough that it won't cause a flush storm of all your memtables flushing at once because none has hit the size or count thresholds yet. For production, a larger value such as 1440 is recommended. - The maximum number of columns in millions to store in memory per ColumnFamily before flushing to disk. This is also a per-memtable setting. Use with {{{MemtableSizeInMB}}} to tune memory usage. + '''memtable_operations_in_millions: '''The maximum number of columns in millions to store in memory per ColumnFamily before flushing to disk. This is also a per-memtable setting. Use with {{{MemtableSizeInMB}}} to tune memory usage. - The maximum amount of data to store in memory per !ColumnFamily before flushing to disk. Note: There is one memtable per column family, and this threshold is based solely on the amount of data stored, not actual heap memory usage (there is some overhead in indexing the columns). See also MemtableThresholds. + '''memtable_throughput_in_mb: '''The maximum amount of data to store in memory per !ColumnFamily before flushing to disk. Note: There is one memtable per column family, and this threshold is based solely on the amount of data stored, not actual heap memory usage (there is some overhead in indexing the columns). See also MemtableThresholds. Defaults are: '60' minutes, '0.3' millions, and '64' mb respectively. @@ -160, +159 @@ Default is: '864000' seconds, or 10 days. * '''keys_cached''' and '''rows_cached''' + - Determines how many keys and rows to cache. The values can either be an absolute value or a double between 0 and 1 (inclusive on both ends). + Determines how many keys and rows to cache. The values can either be an absolute value or a double between 0 and 1 (inclusive on both ends). Each key cache hit saves 1 seek and each row cache hit saves 2 seeks at the minimum, sometimes more. The key cache is fairly tiny for the amount of time it saves, so it's worthwhile to use it at large numbers all the way up to 1.0 (all keys cached). The row cache saves even more time, but must store the whole values of its rows, so it is extremely space-intensive. It's best to only use the row cache if you have hot rows or static rows. Defaults are: '200000' keys cached, and '0', disabled row cache. * '''preload_row_cache''' + - Attempts to populate the row cache on start up with sequential reads. Despite the improvement over random seeks during runtime, this can still take a fairly long time if the row cache to fill is massive. + Attempts to populate the row cache on start up with sequential reads. Despite the improvement over random seeks during runtime, this can still take a fairly long time if the row cache to fill is massive. Default is: 'false'. * '''read_repair_chance''' + Before 0.7, read_repair was either invoked on every read request or on none of them. This is now tunable as a double between 0 and 1 (inclusive on both ends) for the chance of invoking the repair. Default is: '1.0', read repair on every read request. @@ -185, +187 @@ == per-Column Settings == * '''index_name''' and '''index_type''' - These settings control the secondary (automatic) indexes. See [[SecondaryIndexes]]. + These settings control the secondary (automatic) indexes. See SecondaryIndexes. Default is: None, no secondary index support.
