Strange state of bind

[Peter Dambier]

Daniel Ryslink wrote:
> Hello,
> 
> After further investigating the problems with BIND on our caching 
> nameservers, I have find out that after several days of operation, BIND 
> starts to eat 99% of CPU capacity, and ktrace shows that it does 
> repeatedly this system call:
> 

Bind is looking through its cache, taking a record and comparing the
timestamps.

>   41418 named    CALL  gettimeofday(0xbfbffa58,0)
>   41418 named    RET   gettimeofday 0

Throw away if expired, keep if still valid, relase memory if no longer
needed.


Get next record from cache and compare timestamps again

>   41418 named    CALL  gettimeofday(0xbfbfe9e8,0)
>   41418 named    RET   gettimeofday 0

Throw away or keep ...

>   41418 named    CALL  gettimeofday(0xbfbfea18,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea98,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
>   41418 named    RET   gettimeofday 0
>   41418 named    CALL  gettimeofday(0xbfbfea28,0)
> 
> Any ideas about what could cause this behavior?
> 
> Thanks.
> 
> Best Regards
> Daniel Ryslink
> 

That looking for the system clock may occur in different contexts.
That is why it is done again and again, not keept in memory.

That processing record after record may be interrupted by queries
from outside. That is why we have to lookup the time again.


Kind regards
Peter and Karin Dambier

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
mail: peter at echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/