Grouper Users - Open Discussion List

[Jim Fox <>]

I think I misunderstood something.  Does last_membership_change mean
last effective membership change?  That would indeed explain the many updates,
probably with some locking as well.  I can see why it is optional.
Possibly in the future the sense of direct or effective of that timestamp
could be switchable.

It's a lot of work keeping 'effectiveness' up to date, especially
when nested groups are common.  That's why we tend to compute
effective things on the queries.

Jim



> Do your membership changes often cause a lot of effective membership changes? 
> If so, that update statement would be updating a lot of groups.  Otherwise, 
> have you tried to see if analyzing your tables (grouper_groups and 
> grouper_group_set) helps?
>
> Thanks!
>
> -- Shilen
>
> On 3/1/11 1:54 PM, Jim Fox wrote:
> > A couple of weeks ago I activated the update of membership changes:
> >
> >     groups.updateLastMembershipTime = true
> >
> >
> > This did update membership change times, but also caused a major
> > hit on our postgres DBMS.  Response times on our web service
> > went from 1-2 sec to 5-10 sec.  Looking at the database we saw
> > continually running update statements like:
> >
> >     update grouper_groups set last_membership_change = $1 where id  in ($2, 
> > $3...)
> >
> > As soon as one completed another started - or so it seemed.
> > The load average on our DB server went from below 1 to above 7.
> > Setting the updateLastMembershipTime back to false removed the
> > update commands and immediately improved response times.
> >
> > This is standard grouper 1.6.0.  During normal daytime operations
> > we see membership changes every five to ten seconds.
> >
> > Jim