Too many open files .. just curious..

[schilling]

I am having same issue with bind-9.5.0-p1 on Linux dns 2.4.21-47.0.1.ELsmp
#1 SMP Fri Oct 13 17:56:20 EDT 2006 i686 i686 i386 GNU/Linux of Red Hat
Enterprise Linux AS release 3 (Taroon Update 8).
We compiled bind with FS_SETSIZE=4096, added * - nofile 8192 in
/etc/security/limits.conf, folling the link
http://kbase.redhat.com/faq/FAQ_80_1540.shtm


[root at dns1 root]# cat /proc/sys/fs/file-max
209698
[
[root at dns1 root]# ulimit -n
8192
[root at dns1 root]# lsof -c named | wc -l
    985
[root at dns1 root]# netstat -au | wc -l
   1004


But our named have below 1024 number of open files according to lsof and
netstat. and get "too many open file descriptors" in named log.

Is there any other parameters/places to tune the open file descriptors?

Schilling






On Wed, Jul 16, 2008 at 11:02 AM, <etirado.ext at orange-ftgroup.com> wrote:

>
> Hello,
>
> I'm testing BIND 9.4.2-P1.
>
> BIND is running on a RedHat 4.6 with kernel 2.6 , chrooted :
> /prog/named/sbin/named -n 8 -u dns -t /prog/named -c /etc/named.conf
>
> I wanted to test if I'll encounter "Too many open files" error in
> production so I put this little conf in BIND :
>
> max-ncache-ttl 15;
> max-cache-ttl 10;
> max-cache-size 200M;
>
> So this way , I thought BIND will be recursing almost every time with
> ~approx 25 000 queries/sec.
>
> rndc status reports approx 10% of queries/sec for recursive clients. (
> this is enough for this test ).
>
> ls -l /proc/$(pidof named)/fd | wc -l  = ~1000
>
> And yes.. I got the "named[8864]: socket: too many open file
> descriptors"
>
> So I tried to mod the value in /etc/security/limits.conf :
>
> dns     soft    nofile  4096
> dns     hard    nofile  8192
>
> ulimit -Sn = 4096 & ulimit -Hn = 8192 for everyone.
>
> So anyone know what's the problem please?
>
>
> Thank you.
>
> Regards,
>
>
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees.
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration.
> France Telecom Group shall not be liable for the message if altered,
> changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender.
> ********************************
>
>