I am not sure if there is a ticket on this but I have always thought the row cache should not bother caching an entry bigger then n columns.
Murmurs of a slice cache might help as well. On Saturday, December 10, 2011, Peter Schuller <peter.schul...@infidyne.com> wrote: >> After re-reading my post, what I meant to say is that I switched from >> Serializing cache provider to ConcurrentLinkedHash cache provider and then >> saw better performance, but still far worse than no caching at all: >> >> - no caching at all : 25-30ms >> - with Serializing provider : 1300+ms >> - with Concurrent provider : 500ms >> >> 100% cache hit rate. ParNew is the only stat that I see out of line, so >> seems like still a lot of copying > > In general, if you want to get to the bottom of this stuff and you > think GC is involved, always run with -XX:+PrintGC -XX:+PrintGCDetails > -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps so that the GC activity > can be observed. > > 1300+ should not be GC unless you are having fallbacks to full GC:s > (would be possible to see with gc logging) and it should definitely be > possible to avoid full gc:s being extremely common (but eliminating > them entirely may not be possible). > > -- > / Peter Schuller (@scode, http://worldmodscode.wordpress.com) >
