[sakai2-tcc] Site caching

[Matthew Jones]

This has probably been a problem for Sakai since ehcache was implemented in
2.5 (SAK-11440 <https://jira.sakaiproject.org/browse/SAK-11440>). This is
not something someone would notice unless they had a high usage site, didn't
restart often AND were looking at the heap dumps in a memory analyzer.

On Wed, Feb 16, 2011 at 2:04 PM, David Haines <dlhaines at umich.edu> wrote:

> It is not new to 2.8, we found it in 2.7.1.
>
> - Dave
>
>  David Haines
> CTools Developer
> Digital Media Commons
> University of Michigan
> dlhaines at umich.edu
>
>
>
>
> On Feb 16, 2011, at 7:56 AM, May, Megan Marie wrote:
>
> Just to be clear on the scope of the issue – is this new in 2.8 or has it
> existed in previous releases?
>
> Megan
>
> *From:* sakai2-tcc-bounces at collab.sakaiproject.org [mailto:
> sakai2-tcc-bounces at collab.sakaiproject.org] *On Behalf Of *Berg, Alan
> *Sent:* Wednesday, February 16, 2011 7:49 AM
> *To:* sakai2-tcc at collab.sakaiproject.org
> *Subject:* [sakai2-tcc] Site caching
>
> Hi TCC,
>
> Site caching is currently broken in Sakai 2.8. David Hainies reported this
> in: https://jira.sakaiproject.org/browse/KNL-652
>
> And for specific tuning information for a partial solution in
> https://jira.sakaiproject.org/browse/KNL-658
>
> Quote:” Site caching is broken in the K1 kernel 1.1.9 release. Sites
> objects themselves are cached but when sites are evicted from the site cache
> the secondary, in memory, caches for tools, pages, and groups are not
> cleaned up, the references to the objects remain and those objects can not
> be garbage collected. Over time this leads to large numbers of objects that
> won't be used but will consume memory. At Michigan, after not restarting
> Sakai for a couple of weeks we ended up with almost 2GB of memory devoted to
> the site cache. That caused long periods of fruitless garbage collection and
> a degradation of service.
>
> The problem is avoided in the short run by restarting Sakai instances or by
> manually clearing the caches with the Admin memory tool. “
>
>
> I believe David Howitz has placed the partial solution in production at UCT
> and has reported no issues. However, there needs to be more testing and
> perhaps refinement of the patch. The code is currently in trunk.
>
> My suggestion is that we merge what exists into the next QA tag. Seth's QA
> server is already under consistent low level load from a Jmeter script,
> after a week with the new tag I could review the servers logs for
> Exceptions. When I have time I can then perform a more vigorous analysis or
> stress test, if not perhaps UMICH.
>
> Both David Haines and David Howitz know the technology better than I, so if
> you have questions I will leave it to them to reply.
>
> Alan
>
> Alan Berg
> QA Director - The Sakai Foundation
>
> Senior Developer / Quality Assurance
> Group Education and Research Services
> Central Computer Services
> University of Amsterdam
>
> http://home.uva.nl/a.m.berg
> _______________________________________________
> sakai2-tcc mailing list
>
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
>
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110216/8fc4a324/attachment-0001.html