On 7 October 2010 20:49, Peter Schuller <peter.schul...@infidyne.com> 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 <mden...@riptano.com> 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.
