|
Well, rather than dragging this down into a pedantic discussion of details,
let me restate my point:
If you are running a proxy server with heavy load, or large number of users,
just increasing the LVS tables may not be enough. You may have to increase
the size of actual kernel masquerading tables or suffer severe performance
hits. That was the reason I posted this to start with because, as the
subject line states, it was a discussion of the lvs becoming a bottleneck.
There was a statement that the lvs couldn't be the bottleneck, to which I
disagreed, because in my particular situation, the LVS *was* the bottleneck.
That only changed after modifying kernel source code & recompiling.
-d
-----Original Message-----
From: Julian Anastasov
To: Dan
Cc: ''Drew Streib ' '; ''Cono D'Elia ' '; ''lvs-users@xxxxxxxxxxxxxxxxxxxxxx
' '
Sent: 5/12/00 11:19 PM
Subject: RE: lvs bottlekneck
Hello,
On Fri, 12 May 2000, Dan wrote:
> Hi Julian:
>
> The proxy server works thus:
>
> Inbound Connection from External Client to Director Port 8888
> Director creates an LVS masquerading entry for one of n real servers
(also
> on port 8888)
But in table without limits!!!
> The client requests http://www.linuxvirtualserver.org/ (for example)
> The nth real server connects to www.linuxvirtualserver.org port 80
(for
> which the linux kernel creates a real masquerading entry). This is the
> essence of a proxy.
>
> And thus, for each lvs masq entry there is a potential real masq
entry.
But you can create only 4096 entries to
www.linuxvirtualserver.org,
other 4096 to www.domain1.com, other 4096 to www.domain2.com. See,
you have limit while talking to a specific service. So, if you create
4096 entries to 10 external servers you reach the max limit of the
entries: 40960. In normal situations the 4096 entries per external
service
is not reached. This is possible only when all your real servers
try to connect to www.linuxvirtualserver.org! Or with a big rate
because the entry expires after some period. May be the problem
is the FIN-WAIT timeout. You can reduce it.
>
>
> > Don't talk so easy for the MASQ limits :) There are
> > users with more than 4096 entries.
>
> Sorry, I don't understand what you're saying here...
Why /proc/net/ip_masquerade reports 40960 entries for each
protocol as a limit but your limit is 4096. What is your
interpretation? My interpretation is: if only 4096 masquerade
ports are public we can have up to 4096 connections from one remote
client
(addr:port) to the masq box. Because we can't have more than one
connection from one addr:port to other addr:port. In your case
the remote end is server and the limit is reached for the TCP
protocol. So, I think, your MASQ box created 4096 connections to
some remote server, with source port 61000.65095.
Is that correct? Or you can't play with your setup to
investigate the problem.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|
