I decided to bite the bullet and move the last nameserver off of the old X1
architecture with the P1 code, to the new T2000 32-core with the 9.5.0-P2.
The good news is that it is working fine without the dreaded "too many file
descriptors error", which appeared immediately upon activation of the BIND
daemon in the P1 version.

I will keep a close eye on the service, but I am knocking wood that this one
is good!


Emery Rudolph

2008/8/5 Emery Rudolph

> I can deal with the "too many descriptors" error, because I am running BIND
> on 32-core boxes, which don't sweat the overhead. What I will not be able to
> handle are unserved queries. I am in a quandry because I have one nameserver
> that is not on the new hardware and it is ocassionally hitting 100% cpu
> utilization, while the 32-core box, which is getting the same errors is only
> hitting 6% cpu utilization.
> As I said, I am planning to move the named service to off of the older
> hardware, but I am in a quandry as to whether to move to 9.5.0-P1 or P2.
> I think another problem will be - now that so many people have remediated
> the immediate concern, they will not bother to move to P2, so the pool of
> feedback is going to be much, much lower than the first go around.
> Emery Rudolph
> On Tue, Aug 5, 2008 at 2:15 PM, JINMEI Tatuya / 神明達哉 <
> Jinmei_Tatuya@isc.org> wrote:
>> At Tue, 5 Aug 2008 13:20:03 -0400,
>> "Emery Rudolph" wrote:
>> > This is exactly what I did not want to hear. I have been using the

>> 9.5.0-P1
>> > version was hoping the "too many file descriptors" error was going to be
>> > solved in the P2 distribution. Several ISC representatives promised as

>> much.
>> > I really would like to hear more feedback from P2 users on Solaris 10

>> before
>> > moving forward.

>> The difficult part is to provide a reasonable parameter for
>> FD_SETSIZE/ ISC_SOCKET_FDSETSIZE, etc that work for everyone. That's
>> why P2 doesn't try to change the system default by default. Even
>> though I know even P2 should still have some scalability
>> limitation, I suspect the primary reason for this particular report is
>> the use of a small FD_SETSIZE value. I understand your concern, but
>> I'd appreciate if you could still be a bit more patient to see what
>> actually happened.
>> ---
>> JINMEI, Tatuya
>> Internet Systems Consortium, Inc.