tech-net archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: tcp_vtw fail (was: Re: CVS commit: src)
On Tue, May 17, 2011 at 05:16:08PM -0400, Matthew Mondor wrote:
> On Tue, 17 May 2011 08:09:55 +0000
> David Holland <dholland-current%netbsd.org@localhost> wrote:
>
> > Yeah, so this turns out to be because the tcp_vtw code unconditionally
> > allocates about 9M of memory for vestigial connection entries (or
> > some such thing) even when it's AFAICT not in use.
>
> > int tcp4_vtw_enable = 0; /* 1 to enable */
> > int tcp6_vtw_enable = 0; /* 1 to enable */
> > int tcp_vtw_was_enabled = 0;
> > -int tcp_vtw_entries = 1 << 16; /* 64K vestigial TIME_WAIT
> > entries */
> > +int tcp_vtw_entries = 1 << 4; /* 16 vestigial TIME_WAIT
> > entries */
>
> Strikes me as odd if they're really being allocated despite the feature
> being disabled.
>
> I'm not very familiar with this other than the previous discussions
> about it here, but was 64K entries the default because it's
> performance-critical?
>
> If so, would it be possible to dynamically resize these, controled by a
> sysctl stub (or even better, automatically via heuristics in the long
> run)?
In the short run, it is best if memory allocation is postponed until
after VTW is enabled. I will look into it. It may have to wait until
Monday.
In the long run, it is best if the number of entries is adjustable at
run-time.
Dave
--
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 344-0444 x24
Home |
Main Index |
Thread Index |
Old Index