|
I guess one of us need to dig through the Linux
kernel code to find out how the CPU usage was
registered in NAT mode, but not in DR mode.
In my testing with NAT mode, I could not find
any CPU usage, but I was not use top command,
rather I was using vmstat command.
At 04:30 PM 8/15/00 -0400, Joseph Mack wrote:
>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?
>
>
>Joe
>
>--
>Joseph Mack mack@xxxxxxxxxxx
|
