Re: RAC interconnect packet size??
Date: Wed, 22 Apr 2009 11:20:30 -0500
Message-ID: <203315c10904220920k395e8d8bhb5021652b45fb893_at_mail.gmail.com>
Resending...
AFAIK, LMS process doesn't break the packets. As Greg pointed out, you would see increased kernel mode CPU usage, if much packet assembly stuff is going on. CPU usage in network router or port will be higher too.
LMS processes tend to use higher CPU if Global cache traffic is higher. Performance of LMS processes are critical for decent GC performance, exactly why LMS process have RT priority from 10gR2 onwards. Further, to the point, higher CPU usage can affect LGWR performance, which in turn, has negative effect on GC performance.
If CPU usage is mostly from LMS, then I guess, you might have to reduce GC
traffic. Even though Cache fusion is supposed to eliminate much of
application worload partitioning, my experience is that this is still
needed. It isn't as bad olden days, but still there is some amount of
workload partitioning needed. Another area is to make sure that there are
no gc blocks lost etc..
Of course, some of these concepts documented here:
Cheers
Riyaj Shamsudeen
Principal DBA,
Ora!nternals - http://www.orainternals.com
Specialists in Performance, Recovery and EBS11i
Blog: http://orainternals.wordpress.com
Original message:
On Wed, Apr 22, 2009 at 9:04 AM, Bobak, Mark <Mark.Bobak_at_proquest.com>wrote:Hi Tanel,
I hear what you're saying, but, because the LMS processes were by far the biggest CPU hogs, I was thinking that the overhead of breaking down and reassembling packets was the primary cause of CPU starvation.
As I said, we're currently in "wait and see" mode, hoping that we've seen the last of these events. Obviously, if I see more CPU starvation, I'll have to re-think the root cause. But, as I mentioned before, enabling jumbo frames is the "right" thing to do, and there's really no downside, so....
Anyhow, we'll see what happens.
-Mark
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 22 2009 - 11:20:30 CDT