Neat! Thanks. From: Sylvain Lebresne <sylv...@datastax.com<mailto:sylv...@datastax.com>> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Thursday 21 March 2013 10:10 To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Re: Cassandra freezes
Prior to 1.2 the index summaries were not saved on disk, and were thus computed on startup while the sstable was loaded. In 1.2 they now are saved on disk to make startup faster (https://issues.apache.org/jira/browse/CASSANDRA-2392). That being said, if the index_interval value used by a summary saved doesn't match the current one while the sstable is loaded, the summary is recomputed anyway, so restarting a node should always take a new index_interval setting into account. -- Sylvain On Thu, Mar 21, 2013 at 9:43 AM, Andras Szerdahelyi <andras.szerdahe...@ignitionone.com<mailto:andras.szerdahe...@ignitionone.com>> wrote: I can not find the reference that notes having to upgradesstables when you change this. I really hope such complex assumptions are not formulating in my head just on their own and there actually exists some kind of reliable reference that clears this up :-) but, # index_interval controls the sampling of entries from the primrary # row index in terms of space versus time. The larger the interval, # the smaller and less effective the sampling will be. In technicial # terms, the interval coresponds to the number of index entries that # are skipped between taking each sample. All the sampled entries # must fit in memory. Generally, a value between 128 and 512 here # coupled with a large key cache size on CFs results in the best trade # offs. This value is not often changed, however if you have many # very small rows (many to an OS page), then increasing this will # often lower memory usage without a impact on performance. it is ( very ) safe to assume the row index is re-built/updated when new sstables are built. Obviously the sample of this index will have to follow this process very closely. It is possible however that the sample itself is not persisted and is built at startup as opposed to *only* when the index changes.( which is what I thought was happening ) It shouldn't be too difficult to verify this, but I'd appreciate if someone who looked at this before could confirm if this is the case. Thanks, Andras On 21/03/13 09:13, "Michal Michalski" <mich...@opera.com<mailto:mich...@opera.com>> wrote: >About index_interval: > >> 1) you have to rebuild stables ( not an issue if you are evaluating, >>doing >> test writes.. Etc, not so much in production ) > >Are you sure of this? As I understand indexes, it's not required because >this parameter defines an interval of in-memory index sample, which is >created during C* startup basing on a primary on-disk index file. The >fact that Heap usage is reduced immediately after C* restart seem to >confirm this, but maybe I miss something? > >M.
