Scott Lambert
2007-Oct-29 22:13 UTC
Is anyone seeing BIND 9.3.4-P1 use all CPU time on 6.2-STABLE?
I have a 6.2-STABLE snapshot box from August that where named(8) is
going into what appears to be a tight loop calling gettimeofday(). It
is using all CPU time on the box. It seems to be answering queries
alright, just using a lot of CPU.
BIND 9.3.4-P1
FreeBSD 6.2-STABLE-200708 #0: Fri Aug 17 09:31:11 UTC 2007
root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
ACPI APIC Table: <Intel N440BX >
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Pentium III/Pentium III Xeon/Celeron (596.92-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x673 Stepping = 3
Features=0x387fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE>
real memory = 402587648 (383 MB)
avail memory = 384450560 (366 MB)
I noticed a mention of a change in gettimeofday() handling in the
release announcement for 9.3.4-P1, and am wondering if that may have
something to do with the problem.
http://marc.info/?l=bind-announce&m=118531674631565
1990. [bug] libbind: isc's override of broken gettimeofday()
implementions was not always effective.
[RT #15709]
It could be that I just need to scrap that machine...
--
Scott Lambert KC5MLE Unix SysAdmin
lambert@lambertfam.org
Doug Barton
2007-Oct-30 06:24 UTC
Is anyone seeing BIND 9.3.4-P1 use all CPU time on 6.2-STABLE?
On Mon, 29 Oct 2007, Scott Lambert wrote:> I have a 6.2-STABLE snapshot box from August that where named(8) is > going into what appears to be a tight loop calling gettimeofday(). It > is using all CPU time on the box. It seems to be answering queries > alright, just using a lot of CPU.I think your best bet would probably be to try BIND 9.4 and see if it does the same thing. 9.3.x is still going to get some bugfixes, but more attention has been paid to the 9.4.x branch. If you're building bind94 on RELENG_6 make sure to unselect the threads option. hth, Doug -- This .signature sanitized for your protection