Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] updating member change times slows the DB

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] updating member change times slows the DB

Chronological Thread 
  • From: Jim Fox <>
  • To: Shilen Patel <>
  • Cc: grouper users list <>
  • Subject: Re: [grouper-users] updating member change times slows the DB
  • Date: Tue, 1 Mar 2011 12:46:26 -0800 (PST)

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.


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?


-- 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.


Archive powered by MHonArc 2.6.16.

Top of Page