Date: Mon, 11 Sep 2006 18:27:03 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Mike Silbersack <silby@silby.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet in_pcb.c tcp_subr.c tcp_timer.c tcp_var.h Message-ID: <20060911142703.GF27667@FreeBSD.org> In-Reply-To: <20060911005435.A23530@odysseus.silby.com> References: <200609061356.k86DuZ0w016069@repoman.freebsd.org> <20060906091204.B6691@odysseus.silby.com> <20060906143204.GQ40020@FreeBSD.org> <20060906093553.L6691@odysseus.silby.com> <20060906150506.GA7069@rambler-co.ru> <20060911005435.A23530@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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> 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> 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> 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. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060911142703.GF27667>