[cle-release-team] [Building Sakai] 2.9.0 Realm/cache issue

[Matthew Jones]

Though it feels like the default would be *better* being overflow=false,
then selectively turning on the ones you know are safe to overflow.All of
them apparently aren't without moving more stuff in shared or caching
something different than what's currently being cached.

For some of those "larger" ones you mention, we also talked about that on
the list that while the default works for demo or installations of a few
hundred, people who run 1000+ users probably want to increase a few of the
caches.

Specifically these all go above the "10000" default, but increasing them
means you also have to have a bigger heap, which might not be what users of
a demo or testing/dev instance expect. I'd generally prefer the memory
count for most of these being increased (as for authz cache the size of the
objects was only 2MB per 10K elements) rather than overflowing to disk at
all.

(Caches that are too low by default, defaults on 2.9 rc01 in parenthesis)
memory.org.sakaiproject.user.api.UserDirectoryService.callCache - (20000,
false) <-- Not sure why this is 20000, but possibly low. Does callCache
ovelap with the other UDS cache?
org.hibernate.cache.StandardQueryCache (10000, overflow false)  <-- Not
sure about this one, but seems low
org.sakaiproject.authz.api.SecurityService.cache (10000, overflow false)
<-- This for sure should be at least 100000
org.sakaiproject.db.BaseDbFlatStorage.SAKAI_SITE_PAGE_PROPERTY (10000,
overflow true) < These 2 should probably be increased and probably safe to
overflow if necessary
org.sakaiproject.db.BaseDbFlatStorage.SAKAI_SITE_PROPERTY (10000, overflow
true)
org.sakaiproject.site.impl.SiteCacheImpl.cache (10000, overflow false) <--
This should be increased and it's impl so has to stay in memory
org.sakaiproject.user.api.UserDirectoryService (100000, overflow false) <--
This one is fine

On Tue, Oct 16, 2012 at 10:03 AM, Aaron Zeckoski <azeckoski at unicon.net>wrote:

> I agree with Matt Jones' comment that the best option here is to go
> ahead and just flip these over to not overflow to the disk. For the
> smaller and more core kernel caches this is probably better for
> performance anyway. For larger caches (like User) this could be an
> issue so I would not just do it to all of them.
>
> -AZ
>
>
> On Tue, Oct 16, 2012 at 9:49 AM, David Horwitz <david.horwitz at uct.ac.za>
> wrote:
> > A heads up is I've discovered a similar case:
> >
> > https://jira.sakaiproject.org/browse/KNL-976
> >
> > D
> >
> > On 10/16/2012 02:44 PM, Adrian Fish wrote:
> >
> > I can well believe it. Where's the best place to set the prop? In
> > authz-components.xml?
> >
> > On 16 October 2012 13:41, David Horwitz <david.horwitz at uct.ac.za> wrote:
> >>
> >> Yes that's right - if there are more than cacheMemory size items that
> are
> >> younger than TTL and TTI than the least referenced one will be dropped.
> I
> >> increased the size of the memory cache slightly.
> >>
> >> We've found that overflowing caches to disc can have worse effects that
> >> going to the db anyway. Our site property cache did this and it
> saturated
> >> disk IO
> >>
> >> D
> >>
> >> On 10/16/2012 02:28 PM, Adrian Fish wrote:
> >>
> >> There must be side effects to that though, surely? Does is just mean
> that
> >> old stuff gets culled earlier?
> >>
> >> On 16 October 2012 13:15, David Horwitz <david.horwitz at uct.ac.za>
> wrote:
> >>>
> >>> Thanks to so pointers from Aaron it seems the simple solution is to set
> >>> overFlow to disk to be false for that cache
> >>>
> >>>
> >>> D
> >>> On 16 October 2012 08:52, David Horwitz <david.horwitz at uct.ac.za>
> wrote:
> >>>>
> >>>> Jira'ed and having a look:
> >>>>
> >>>> https://jira.sakaiproject.org/browse/KNL-975
> >>>>
> >>>> D
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20121016/008a294d/attachment-0006.html