LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: lvs not workimg :(

To: Radu-Adrian Feurdean <raf@xxxxxxxx>
Subject: Re: lvs not workimg :(
Cc: "'lvs-users@xxxxxxxxxxxxxxxxxxxxxx'" <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 25 May 2001 12:48:47 +0300 (EEST)
        Hello,

On Fri, 25 May 2001, Radu-Adrian Feurdean wrote:

> >     empty hash tables:
> >
> >     18 bits occupy 2MB RAM
> >     24 bits occupy 128MB RAM
> >
> >     If the box has 128MB and the bits are 24 the kernel crash is
> > mandatory, soon or later. And this is a good reason the virtual service
> > not to be hit. Expect funny things to happen on box with low memory :)
>
> Oops ! I forgot that not anyone uses 256Mb or more RAM on directors :)

        Yes, 256MB in real situation is ~1,500,000 connections, 128 bytes
each, 64MB for other things ... until someone experiments with SYN attack

> However, for me it makes sense to use up to 66% of total memory for LVS,
> especially on high-traffic directors (in the idea that the directors doesn't
> run all the desktop garbage that comes with most distros).

        If the used bits are 24, an empty hash table is 128MB. For the
rest 128MB you can allocate 1048576 entries, 128 bytes each ... after
the kernel killed all processes.

        Some calcs considering the magic value 16 as average bucket
length and for 256MB memory:

For 17 bits:

2^17=131072 => 1MB for empty hash table

        131072*16=2097152 entries=256MB for connections

For 18 bits:

2^18=262144 => 2MB for empty hash table

for each MB for hash table we lose space for 8192 entries but we speedup
the lookup.

So, even for 1GB directors, 19 or 20 is the recommended value. Anything
above is a waste of memory for hash table. In 128MB we can put 1048576
entries. In the 24-bit case they are allocated for d-linked list heads.

> Radu-Adrian Feurdean
> mailto: raf@xxxxxxxx
> ----------------------------------------------------------------------------
> The light at the end of the tunnel is the headlight of an approaching train.


Regards

--
Julian Anastasov <ja@xxxxxx>



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