UDP packet loss
Scott S. Bertilson
scott at nts.umn.edu
Thu Jun 8 20:07:17 UTC 2006
> Rick Jones wrote:
> > Patrick Klos <pklos at osmium.mv.net> wrote:
> >> I'd say your biggest problem is the 214 million packet receive
> >> errors! Find the source of those errors, and you'll likely take
> >> care of your problem. Your machine is tossing 1 out of every 4 or 5
> >> packets!
> > IIRC, 99 times out of 10 those packet receive errors are the socket
> > buffer overflowing.
> > Now, to actually get a larger socket buffer, you may need to tweak the
> > sysctl settings _and_ something in the named config file. Sysctl to
> > raise the limit and named config file to make sure that named doesn't
> > "undo" it by asking for something smaller.
> > However, that will only help if the issue is occasional bursts of
> > requests and the average request rate remains within the limits of the
> > server. If the average request rate is higher than the server can
> > satisfy, no increase in the socket buffer will help.
> > rick jones
> That's what I thought. I just need to know what to change on Bind level.
> Operating system keeps this limit OK, but I don't know if Bind is
> actually using it. I don't think that hardware couldn't keep up with
> traffic (processors are at least 20% idle), about 4GB ram free etc, but
> maybe there is something more to tweak. Suggestions, anyone?
You can get an idea of what the socket buffer size is
if you can catch the system at a time when the "packet
receive error" counter is ticking along by:
netstat -na --inet | grep ':53 '
You'll likely see a TCP port 53 socket, but its Recv-Q
is likely small or 0 unless you're receiving a very
large number of TCP queries (a very unusual situation).
On the other hand, you should see a fairly large number
in a UDP port 53 Recv-Q. If you're overflowing, that
number will probably be very close to the UDP socket
input queue size for that socket.
More information about the bind-users