Joseph Mack wrote:
With sufficient number of connections, a director could
start to swap out its tables (is this true?)
In this case, throughput could slow to a crawl. I presume
the kernel would have to retrieve parts of the table to find
the real-server associated with incoming packets. I would
think in this case it would be better to drop connect
requests than to accept them.
In earlier verions of LVS, you could set the amount of
memory for the tables (in bytes). Now you allocate a number
of hashes, whose size could (in the worst case) grow without limit.
If I have 128M RAM == 1M connections, am I going to
run out of ports first?
What would have to happen for LVS to start swapping?
(ie how much of a problem is this?)
If it's possible for LVS to start the director to swap,
is there some way to stop this?
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA
With sufficient number of connections, a director could
start to swap out its tables (is this true?)
In this case, throughput could slow to a crawl. I presume
the kernel would have to retrieve parts of the table to find
the real-server associated with incoming packets. I would
think in this case it would be better to drop connect
requests than to accept them.
In earlier verions of LVS, you could set the amount of
memory for the tables (in bytes). Now you allocate a number
of hashes, whose size could (in the worst case) grow without limit.
If I have 128M RAM == 1M connections, am I going to
run out of ports first?
What would have to happen for LVS to start swapping?
(ie how much of a problem is this?)
If it's possible for LVS to start the director to swap,
is there some way to stop this?
Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@epa.gov ph# 919-541-0007, RTP, NC, USA