Severely delayed (15s) ACK on inbound NNTP packets causing hung c hannels
brett.wyer at telecheck.com
Wed Oct 6 12:08:39 UTC 1999
Over the last few months I've been running into a problem with INN v2.x and
was hoping that someone could either tell me what's wrong, or possibly point
me in the right direction as to how to track the problem down. Basically,
the problem manifests itself as our system dropping somewhere between 50-75%
of our inbound news. After a bit of testing, I was able to determine that
(based on sniffer traces) individual channels are sitting and waiting for my
system to return a TCP ACK before shipping more information. According to
my sniffer traces, this can be for up to 15 seconds.
Now for the strange part. Occasionally, all six of my channels from one
provider will be in this state. During this time, there is NO activity on
my system--CPU's (4) are 100% idle, no disk I/O, nothing. Once the 15
seconds elapses, bing! the feeds start going again.
My system is a 4-processor AlphaServer 2100 with 1GB of memory, four 275MHz
processors and 72GB of disk storage. Apparently, this has been going on for
quite some time, but I wasn't made aware of it until recently. Any
suggestions as to how to trace this would be quite helpful.
Some specific questions I have:
- Does the OS wait to send a TCP ACK until a buffer is flushed by the app
(assuming the window is full)?
- What section of code in INN is responsible for this buffering?
- Is there a specific reason a 24K buffer was chosen in rc.c? (I ask this
question because my Cyclone feed keeps trying to grow the buffer beyond
this--I assume that the window won't grow past this limit, at least that
appears to be the limiting factor)
More information about the inn-workers