On Nov 2, 2006, at 8:53 PM, Christopher Lenton wrote:
Hi Mike,
Sorry I forgot to include information about the logging. Yes I am
using
daemontools with /etc/dnscache/log/run:
#!/bin/sh
exec setuidgid dnscache multilog -*
no problem, thanks for the clarification. if you don't ever intend
to keep or process logs, you can save some system and user cpu time.
configure your dnscache run script to route its output to /dev/null,
and remove your log service. this saves the time the system takes to
process the pipe, and the time that multilog takes to decide not to
log anything.
It seems like the failures have reduced somewhat as I increased the -o
parameter. In the last few hours, I have had only one timeout recorded
on the SLB router's syslog:
Nov 3 12:38:58.563 AEDT: %SLB-6-REAL: Real 203.23.xx.xx (DNS1FARM)
has
changed state to FAILED
Nov 3 12:40:05.303 AEDT: %SLB-6-REAL: Real 203.23.xx.xx (DNS1FARM)
has
changed state to OPERATIONAL
I cannot really comment on this, except to say that I run some fairly
high volume dnscache's with an -o value of 250. FreeBSD will keep a
queue of UDP requests in a buffer of its own. I admittedly do not
fully comprehend the effects of increasing the value of -o.
how is it that your Ciscos are configured to test dnscache? in my
configuration, I have several dnscache instances behind Foundry
ServerIron load balancers. they are configured to query an A record
for 'localhost.', which is good because dnscache will always respond
'127.0.0.1' to this query, without consulting the Internet. if you
are querying an external address, you are allowing the possibility of
a failure external to dnscache to affect your load balanced
configuration.
-Mike
|