- wrote the following on 11/20/2013 12:30 PM:
Depending on your OS and Bind settings, Bind may be performing IPv6/AAAA
queries in parallel to IPv4/A queries. If IPv6 is disabled on your RHEL5
server I suspect they may only be performing IPv4/A queries during
recursion. You might check if this is, at least in part, responsible for the
additional load.

I just compiled a version of bind on the RHEL 6 system with ipv6
disabled and the results were the same.

You didn't provide the same CPU information about your RHEL 5 builds as you
did for your RHEL6 system, so I just responded about the information you did
provide. Are these 24/32 core systems? Do the same number of named child
processes run on both the RHEL5 and RHEL6 systems? I'm going to assume that
you've already examined query load on the servers and found them similar.
The other system only has 16 CPUs but named runs at a third of the CPU
that the RHEL 6 box does.

RHEL 5:
version: 9.9.4-P1 () <id:07aaf1ef>
CPUs found: 16
worker threads: 16
UDP listeners per interface: 16
number of zones: 169
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 30/9900/10000
tcp clients: 0/100
server is up and running


What about the information from top? When comparing RHEL5 and RHEL6 systems, I would compare the total CPU usage of the server (out of 100% not 2400% or 1600%).

Since the hardware is different, comparing a 16 named threads on a 16 core box at ???MHz against a 24 core box with 24 named threads at ???MHz may not necessarily be valid. If the CPUs are running at the same frequency (look at what speed they are actually running at vs the max speed... see /proc/cpuinfo ) then you can probably account for the 16 vs 24 core difference pretty easily. If the CPUs run at more than negligibly different frequencies you will have to factor that into any comparison or make the frequencies the same to make a 1:1 good comparison.

--Blake
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to