named and high CPU utilization

[Radu "Ux" D.]

In fact, is BIND 9.3.1... Sorry forgot to mention.

Thx

Radu "Ux" D.



Danny Mayer wrote:

> Radu "Ux" D. wrote:
>
>> Hi
>>
>>
>> The named (not very high loaded one) goes taking 100% CPU and can't 
>> be stopped in an usual fashion. The same named configuration, on 
>> other machine, doesn't behaves like this. It seems that this is only 
>> occurring on Windows systems with dual cpu’s. I did find a forum 
>> online for a software called Plesk that uses named.exe that has the 
>> same issue and the fix that they applied was to assign cpu affinity 
>> to named.exe in the code. Windows will allow you to assign cpu 
>> affinity through task manager but it won’t allow you to assign 
>> affinity to a service! The following is taken from the Plesk forum:
>>
>> "Bind is configured to work on 1 CPU and it makes it do not waste CPU 
>> resources."
>
>
> If this is BIND 8 then that might be true. However BIND 9 was designed 
> to take advantage of multiprocessors and in fact uses at least 6 
> threads each of which could take avantage of multiprocessors. If you 
> are running one of the old versions of BIND 9 you could have this 
> problem. Upgrade to BIND 9.3.1 and you won't have this problem.
>
>>
>> Also I pulled the following from the Oreilly windows 2000 performance 
>> guide:
>>
>> "It should not be a big surprise to learn that one secondary effect 
>> of multiprocessor coordination and serialization is that it makes 
>> caching less effective. This, in turn, reduces the processor's 
>> instruction execution rate. To understand why SMPs impact cache 
>> effectiveness, we soon take a detour into the realm of cache 
>> coherence. From a configuration and tuning perspective, one intended 
>> effect of setting up an application to run with processor affinity is 
>> to improve cache effectiveness and increase the instruction execution 
>> rate. Direct measurements of both instruction execution rate and 
>> caching efficiency, fortunately, are available via the Pentium 
>> counters."
>>
>> Anyone encountered something like this? Any idea?
>>
> Cache effectiveness is a lot more complicated than this sounds but 
> it's not your problem. Upgrade.
>
> Danny
>