On 3/30/06, Daniel Hartmeier <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 30, 2006 at 01:58:19PM -0600, Bill Marquette wrote:
>
> > Any suggestions??? I'm guessing most people aren't seeing this as
> > they are connecting to multiple hosts, not a select few at a "decent"
> > connection rate.
>
> Is squid re-using the same source address AND port for all those
> connections? Or just the source address, with random source ports?
>
> The former couldn't possibly work at a rate of once per second. The
> latter shouldn't cause much of a problem with that rate.
It's certainly using random source ports. Same source address, same
dest address/dest port, randomly selected source port at a rate of one
per second. I'll need to spend more time debugging as this is
happening on 1 in 1000 connections.
> Are you sure you decreased the right timeout? Those states should all be
> using the tcp.closed timeout (default 90s), if the connections were
> closed normally (which might be confusing, as netstat calls it
> FIN_WAIT_2). Run pfctl -ss, if they show up as FIN_WAIT_2:FIN_WAIT_2,
> that means pf is applying the tcp.closed timeout, and pfctl -vss should
> show 'expires in' accordingly.
Good question. I'll poke at that some more then, I forgot that I can
get the 'expires in' value from pfctl. We did change the tcp.closed
timeout to 5s and tcp.finwait to 10s for that rule (as I showed in my
previous email) w/out any significant improvement - I'm hesitant about
shortening it any more as it doesn't feel like a tunable I really need
to be modifying.
What I neglected to mention in my previous email is the pf options we set:
set limit { states 131072 , frags 2048 }
set optimization normal
set loginterface em1
set block-policy return
set state-policy if-bound
set debug loud
--Bill
