UPDATE - 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! Thanks, Emery Rudolph 2008/8/5 Emery Rudolph <[EMAIL PROTECTED]> > 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 / [EMAIL PROTECTED]@C#:H(B < > [EMAIL PROTECTED]> wrote: > >> At Tue, 5 Aug 2008 13:20:03 -0400, >> "Emery Rudolph" <[EMAIL PROTECTED]> 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. >> > >
