Re: How to meausre the capacity of LVS dispatcher??

To: Wayne <wayne@xxxxxxxxxxxxxxx>
Subject: Re: How to meausre the capacity of LVS dispatcher??
Cc: Wang Haiguang <wanghaig@xxxxxxxxxxxxxxx>, LVS <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Joseph Mack <mack@xxxxxxxxxxx>
Date: Tue, 15 Aug 2000 16:30:53 -0400 (EDT)
On Tue, 15 Aug 2000, Wayne wrote:

> Joe,
> Since LVS is working in the kernel, there is no process
> actually associate with it, so that the CPU usage is not
> being reported.  In normal operation, kernel is working
> on behalf a process or a group of processes. That is
> not true for LVS kernel, which is acting in the kernel and
> no process associated to it.

I assume you've answered my question, but since you didn't explicitely say
so, I want to make sure I'm not missunderstanding you...

LVS could be burning up all sorts of cycles in VS-DR and I won't see it in
system on "top"?

> >Top reports (among other things) system and user usage. 
> >I had assumed that was kernel and userland. Am I wrong?

When I run a heavy load through a director forwarding by VS-NAT the load
average goes through the roof (>5), top reports 98% CPU usage and the
keyboard and mouse don't respond anymore. This was as I expected.

Doing the same thing with VS-DR, with the same throughput on the director,
there's no effect on load average (<0.1), the keyboard and mouse are
responsive and top reports almost no increase in CPU usage. I was
suprised, and after consulting with a few people, who weren't terribly
helpful, decided that routing (which is what VS-DR does) isn't terribly
expensive for the CPU. I could only assume that the CPU is looking at the
header of the packet and the rest of the packet doesn't get clocked
through the kernel, but gets sent back out the NIC again. Still I would
have expected some CPU useage to rewrite the MAC address at least.

So is there a lot of CPU being burned up with VS-DR too, but not enough
that the mouse doesn't work anymore as it does with VS-NAT?


Joseph Mack mack@xxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>