On 24/07/2014 01:35, Matthew Calder wrote: > At the moment I'm limited to using 2 UDP listeners per interface. When > stress testing I can see that only 2 out of 4 CPUs are being used, I'm > guessing because I'm limited to 2 listeners. Any suggestions for what > could be limiting BIND from using a higher number of UDP listeners?
named will tell you in its startup logs how many workers it is running (either from auto-detecting #cpus or from -n when running named). It will also tell you how many listeners per interface (default for 9.9 is the same as the number of worker threads, but it's also controlled by -U at start up). The number of listeners per interface is also capped at the number of worker threads. >From BIND 9.10 we changed the default behaviour - it's this: "If not specified, named will calculate a default value based on the number of detected CPUs: 1 for 1 CPU, 2 for 2-4 CPUs, and the number of detected CPUs divided by 2 for values higher than 4. If -n has been set to a higher value than the number of detected CPUs, then -U may be increased as high as that value, but no higher." Also, working out what's going on is a bit of an 'art' because within BIND, depending on how the OS works, you're probably going to get each worker thread pegged to the same CPU most of the time (but not always), but each worker thread itself is going to be running multiple tasks - not just the listeners, so while it sometimes works out under stress that we see the listener tasks always on the same threads and those threads always on the same CPU, it's not guaranteed to split that way (particularly if -n and -U are the same and/or -n is set larger than the number of available CPUs). Cathy _______________________________________________ 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
