Re: Monitor contention
- From: "Ethan Post" <post.ethan@xxxxxxxxx>
- To: BLock@xxxxxxxx
- Date: Tue, 15 May 2007 10:44:51 -0500
During some recent RAC scalability testing we saw a lot of GC type waits
during our transaction performance runs after adding a 4'th node into the
cluster. The issue turned out to be a lot of contention on an index for a
very high insert table (logging). We turned the logging feature off and it
all went away. Performance papers suggest tuning the index storage
parameters to allow for fewer entries per block so that the nodes are not
all going after the same block. It is interesting that the problem did not
show up until the 4'th node came on, and the problem was very immediate and
severe, I guess is has something to do with the mechanics of the
interconnect and more than 3 nodes.
I think there is some benefit to taking your top N SQL's and knowing what
the average elapsed time per execute is. If a problem shows up it can be
beneficial to examine this data. I think the other responses are right on,
but I have always found great benefit in having a lot of historical data on
hand for analysis.
- E
On 5/11/07, BLock@xxxxxxxx <BLock@xxxxxxxx> wrote:
What kinds of contention do we still need to look for in a RAC and SAN
environment?
Thanks
Brian Lock
DBA - East Campus
Other related posts:
