New LVS installation - wierd problems
ja at ssi.bg
Wed Aug 22 09:05:06 BST 2001
On Tue, 21 Aug 2001, Nate Stone wrote:
> Thanks for the reply.
> > It seems you have problems with your real server OS. May be
> > you can tell us the exact versions of the real server (if Linux) and
> > of the Apache. But that seems as incorrect process state management
> > in the kernel. What shows vmstat on the real server? Full CPU usage?
> > Any additional patches applied on the real servers?
> The real servers are Redhat 7.1 running kernel 2.4.5 with the ipvs and
> netfilter patches (and any others that came with the IPVS distro). This
> could, of course, be the problem - I am aware that IPVS is still in
> development for kernel 2.4.5. Maybe I need to downgrade?
No, you have to _upgrade_ your kernel. You have problems in
the real servers, LVS is working on the director.
> The real server is completely unloaded when this problem is going on
> (processor wise). vmstat shows 94% idle for processor and a bunch of
> uninterruptible sleep processes (800). Our disk swap is rather high
> (200-400 MB) and we're not sure if shared memory is working properly
> (which could be a dramatic effect since Apache relies heavily on shared -
> apparently they turned off the shared memory calculation in kernels 2.4.x
> which really is killing our ability to optimize our memory configuration).
Yes, 2.4 wastes more swap space but may be this is going to change
in the next kernels, I know that such patch already exist in the -ac
> We plan to add more ram this week (we have 512mb per server on Athlon
> 933mhz processors). The problem really looks like simple NFS I/O wait
> which is a problem because we will have to upgrade our drive system if
> that's it - I'm optimizing NFS right now, but I'm not getting much
I don't know what to recommend here. The only thing I can tell
you is to try to upgrade to 2.4.9. I'm not sure whether your problems
will go away. If not, you can report these problems on linux-kernel.
> > Your real server should be ready for everything: attacks,
> > incorrect packets, etc. IMO, you can achieve the same D states even
> > without using LVS. The problem can't be in the director.
> I agree that the problem can occur any number of ways and was really just
> curious if anyone had seen similar problems in other LVS implementations.
> I think it is probably just disk/nfs i/o which may just be a lack of
> Thanks for your help. Please let me know if you have any other
Julian Anastasov <ja at ssi.bg>
More information about the lvs-users