|
Hi Joe,
Sorry for the late reply.
> > I don't exactly know where there is the misunderstanding but the director
> > never crashes because of exhaustion of memory.
>
> Let's say you fill up RAM with the hash table and all user processes go
> to swap, then there will be problems - I don't know what, but it doesn't
> sound great. I expect we need to leave a certain amount for
But this is the problem of the VM in general. We cannot fix it in the LVS code.
Just now there was a big discussion on lkml about OOM questions, swapoff and
the VM behaviour in general in 2.4.x kernels. BTW, you can never have all user
processes go to swap AFAIK. The kernel has its reserved memory range and if
it's used we get a page fault and the kmalloc returns NULL. For example in
net/ipv4/ip_vs.c [2.2.x] when we allocate memory for a new masquerading table
entry:
dest = (struct ip_vs_dest*) kmalloc(sizeof(struct ip_vs_dest),
GFP_ATOMIC);
if (dest == NULL) {
IP_VS_ERR("ip_vs_new_dest: kmalloc failed.\n");
return NULL;
}
memset(dest, 0, sizeof(struct ip_vs_dest));
and then in net/ipv4/ip_vs.c [2.2.x] ip_vs_add_dest():
dest = ip_vs_new_dest(svc, mctl);
if (dest == NULL) {
write_unlock_bh(&__ip_vs_lock);
IP_VS_ERR("ip_vs_add_dest(): out of memory\n");
return -ENOMEM;
}
So, if we don't get a memory chunk big enough, the return pointer will be NULL
and we return -ENOMEM which results, thousands of lines of code later, in a
goto drop or return -1 from the packet_handler. Set the debugging to 10 and
watch your kernlog. If this message shows up, you're out of memory.
LVS can use up all memory but I would be very surprised if it would crash
the kernel.
> user space processes and not allow the director to take more than a certain
> amount of memory.
AFAIK the kernel doesn't take away the memory of the userspace, anyone?
> > Not that I would know of but you could use my treshold limitation patch :)
>
> Maybe I'd better go grab it.
Since I've already read the later posting between you and Julian, I reckon his
solution is more appropriate for your problem.
> It would seem that we need a method of stopping the director hash table from
> using all memory.
>
> > 128MByte, persistency 300s:
>
> why does the persistency timeout affect the number of connections?
> It affects the number of users that can be connected at any time.
users != connections
The persistency timeout defines the amount of time a template may reside in
the masquerading table for lookups. The higher the timeout the longer we have
to keep the incoming connections in the table the more will be in the table
until the first templates expire.
> > max amount of concurrent connections: 3495.
> > We assume having 4 realservers equally load balance, thus we have to
> > limit the upper threshold per realserver to 873. Like this you would never
> > have a memory problem but a security problem.
>
> what's the security problem?
SYN/RST flood. My patch will set the weight of the realserver to 0 in case the
upper threshold is reached. But I do not test if the requesting traffic is
malicious or not, so in case of SYN-flood it may be 99% of the packets causing
the server to be taken out of service. In the end we have set all server to
weight 0 and the load balancer is non-functional either. But you don't have
the memory problem :)
Cheers,
ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
