On 7 October 2010 20:49, Peter Schuller <[email protected]> wrote: > ... if you "waste" 10-15 gigs of RAM on the JVM heap for a > Cassandra instances which could live with e.g. 1 GB, you're actively > taking away those 10-15 gigs of RAM from the operating system to use > for the buffer cache. Particularly if you're I/O bound on reads then, > this could have very detrimental effects (assuming the data set is
Peter - in my defense, I was doing this on 68GB mega-boxes :) But, yeah, we're seeing far more *predictable* results from the OS's ability to cache file system access, than Cassandra-with-Java's ability to manage its own memory. My own sys-admin experience previously had been on real hardware, usually 16GB, occasionally 32GB boxes, but with *much* larger file systems than we're using with Cassandra, hence my earlier optimism at leaving a 'mere' 30-40GB for FS cache. On 8 October 2010 02:05, Matthew Dennis <[email protected]> wrote: > Also, in general, you probably want to set Xms = Xmx (regardless of the > value you eventually decide on for that). Matthew - we'd just about reached that conclusion! Is it as big an issue for clusters that are up for days at a time, with maybe Xmx:3G? I'd kind of assumed that it'd get to its max pretty quickly. I haven't been watching that with jconsole, but might watch it on the next startup. As to heap size determination ... the equation offered: MemtableThroughputInMB * 3 * (number of ColumnFamilies) + 1G + (size of internal caches) -- has (for us, at least) 3 constants and 2 quite fuzzy values. The experiments continue! Jedd.
