bind-9.5.0b1 problem on ppc64 : rbtdb.c:1532: REQUIRE(prev > 0) failed

[Res]

On Tue, 5 Feb 2008, Fajar A. Nugraha wrote:

>> It doesnt matter at all, the server I was referring to was a DNS cache, on
>
> Really? That's new to me. We had several authoritative nameservers and some
> caching nameservers, the caching-one always uses more CPU.

our users DNS are separate to authoritives, each remote PoP has a local 
route to a primary end user DNS, IOW, eg: end users are all asigned 
ns3.blah and ns4.blah, ns3, is duplicated in every PoP, all has the same 
IP but each PoP has a route for that IP locally so it doesnt have to 
traverse the country back to our data centre, ns4 is located in our data 
centre, ns1 and 2 are as well but they are authoritives so end users only 
use them when looking up us, those caches have forwarders etc


>> primary for an entire state of dial/dsl customers hence why concurrent was
>> set to 10000, because even at 8000 bind gave errors, and I made the fatal
>
> We ended up setting it to 10000 as well.

if your at 10K and having troubles, bind is not the cause. if it works for 
nothing here it should everywhere,

ns3 (results of only 1 box, in my state)  DL360 G4, 4gb ram
rndc status shows 9718 requests

22:15:27 up 305 days, 12:46,  1 user,  load average: 0.00, 0.01, 0.01

you dont have logging on do you? the only time i've ever seen Bind use 
any CPU is when querry logging is on, and thats just plain crazy on 
busy networks unless you are testing.

logging {
         category lame-servers { null; };
         category client { null; };
         //channel log_queries { file "/var/named/query.log"; print-category yes; };
         //category queries { log_queries; };
};


>> not in an ISP environment when you have 20K dsl users on one PoP :)
> Try about one million users :)

1 mil and you only have 10K concurrent? man your users must do SFA :)

> Going from power4 to power5+ in my setup actually reduce concurrent users as
> shown by "rndc status". Going from bind 9.3 -> 9.5 reduce it even further.

we notice no delays in DNS requests, all lookups are instant, sop faster 
hardware wouldnt have any affect here.

> A P4 isn't sufficient for that (not in my experince, anyway)

well, I dont recommend it, but it shows it can be done if you have nothing 
else available in the middle of the night :) It handled it very well.

> I'm interested, though, in what tuning you have done on that server. Any
> special settings that can significantly improve performance?

apart from the log statement above, and only allowing recursion to the 
admin acl, and only allowing our clients to use our DNS servers, only one 
other setting is used in "tuning" and thats  min-refresh-time 7200, so 
its pretty stock standard really.


-- 
Cheers
Res

mysql> update auth set Framed-IP-Address='127.0.0.127' where user= 'troll';