|
Hello,
Julian Anastasov wrote:
>It is true that we don't have much/any control in the conn expiration
process.
>May be the devel IPVS 1.1.0 will solve this problem. Currently, the only
way to forget
>about all connections is to unload the ipvs module. May be a new conn
expiration method
>can allow the conn entries to be deleted from any context.
thanks for this info, ip_vs doesnt want to get unloaded / device busy, also
something
strange happens to the expire time which i think is the reason for "device
busy" ,
yesterday evening i left the lvs with a 2 hours persistant timeout for the
night, i
made a conx request and closed it afterwards.
IPVS connection entries
pro expire state source virtual destination
TCP 115:58.78 NONE venus.intern:0 lbs.intern:65535
hh-fra-in01.intern:65535
today for my surprise i see:
IPVS connection entries
pro expire state source virtual destination
TCP 357913:56.47 NONE venus.intern:0 lbs.intern:65535
hh-fra-in01.intern:65535
there was no request during this time, the time difference between this to
lists is
around 14 hours.
i understand the problem occuring with high persistant timeout and will see
how to get
my boss understand this too and change our logic here ....
Regards
Matthias
|
