Josh, I cannot reproduce the excessive semop() on a Dual XEON DP on a
non-bigmem kernel, HT on. Interesting to know if the problem is related
to XEON MP (as Tom wrote) or bigmem.
Josh Berkus wrote:
Dirk,
I'm not sure if this semop() problem is still an issue but the database
behaves a bit
Dirk,
> I'm not sure if this semop() problem is still an issue but the database
> behaves a bit out of bounds in this situation, i.e. consuming system
> resources with semop() calls 95% while tables are locked very often and
> longer.
It would be helpful to us if you could test this with the i
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
> This was the key to look at: we were missing all indices on table which
> is used heavily and does lots of locking. After recreating the missing
> indices the production system performed normal. No, more excessive
> semop() calls, l
Tom, Josh,
I think we have the problem resolved after I found the following note
from Tom:
> A large number of semops may mean that you have excessive contention
on some lockable
> resource, but I don't have enough info to guess what resource.
This was the key to look at: we were missing all i
