Re: cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c tcp_var.h
On Mon, Sep 11, 2006 at 01:21:14AM -0500, Mike Silbersack wrote:
M> Ok, I started looking through the mess that is in_pcb.c, and I came up
M> with a simpler idea than trying to improve upon my old heuristic.
M> What if we just build upon what Gleb did in revision 1.256, and change the
M> size of the tcptw zone? Instead of scaling it to maxsockets / 5, let's
M> scale it to max((ipport_lastauto - ipport_firstauto)/2, 500). We'll have
M> to rescale it whenever the port ranges are changed, but those sysctls are
M> already handled by a function, so it'll be easy.
The UMA zone can't be made smaller than it is, while IP port ranges
can vary in both directions.
M> This means that we'll be keeping around fewer time_wait sockets than we do
M> at present, but I don't think that's a big problem for anyone. On the
M> positive side, it means that time_wait sockets can't starve out ephemeral
M> ports unless you have more than 50% active connections.
M> One slightly more complex solution would be to use one tcptw bucket for
M> connections with local ports >= 1024 and a seperate bucket for connections
M> with local ports < 1024. Assuming that our front end web proxy answers on
M> ports < 1024, that would ensure that we keep one pool of time_wait sockets
M> for our connections from clients and another pool for our connections to
M> the backend web servers. I guess that would be slightly more "correct".
M> What do you guys think?
I think that your original commit should be rethought. It should free one
tcptw entry, in a case of absolute match, and return NULL. Do not jump
up and go on into cycle again.
Totus tuus, Glebius.
Received on Mon Sep 11 2006 - 14:27:06 UTC