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@peter-dambier.de
mail: peter@echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/