James, sorry I was out for a few days. Yes, if the row cache doesn't give a good hit rate then it should be disabled.
Is there any chance to increase the VM configuration specs? I couldn't pinpoint in exactly which message you mentioned the VMs are 2GB mem and 2 cores, which is a bit meager. Also is it possible to batch the writes together? -- Y. On Mon, Dec 24, 2012 at 7:28 AM, James Masson <james.mas...@opigram.com>wrote: > > > On 21/12/12 17:56, Yiming Sun wrote: > >> James, you could experiment with Row cache, with off-heap JNA cache, and >> see if it helps. My own experience with row cache was not good, and the >> OS cache seemed to be most useful, but in my case, our data space was >> big, over 10TB. Your sequential access pattern certainly doesn't play >> well with LRU, but giving the small data space you have, you may be able >> to fit the data from one column family entirely into the row cache. >> >> >> > I've done some experimenting today with JNA/row cache. Extra 500Mb of > heap, 300Mb row cache, latest JNA, set caching=ALL in the schema for all > column families in this keyspace. > > Getting average 5% row cache hit rate - no increase in cassandra > throughput, and increased disk read I/O, basically because I've sacrificed > Linux disk cache for the cassandra row-cache. > > Load average was 4 (2cpu boxes) for the duration of the cycle, where it > was about 2 before, basically because of the disk I/O I think. > > So, I think I'll disable row caching again... > > James M >
