Re: RAC interconnect packet size??

From: Riyaj Shamsudeen <>
Date: Wed, 22 Apr 2009 11:20:30 -0500
Message-ID: <>


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:

Riyaj Shamsudeen
Principal DBA,
Ora!nternals - Specialists in Performance, Recovery and EBS11i Blog:

Original message:

On Wed, Apr 22, 2009 at 9:04 AM, Bobak, Mark <>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.


Received on Wed Apr 22 2009 - 11:20:30 CDT

Original text of this message