Hi,<br><br>we use following approaches:<br>1. we limit the idle connection time "net.ipv4.tcp_keepalive_time = ..." in /etc/sysctl.conf<br>2. fs.file-max = 65000 in the same sysct.conf<br>3. In "/etc/profile" we have added the libe "ulimit -n 65000", otherwise /etc/init.d/dirsrv takes the value by default of 8192<br>
4. echo "ldap hard nofile 65000" >> /etc/security/limits.conf<br> echo "ldap soft nofile 65000" >> /etc/security/limits.conf<br> echo "ldap hard core 64" >> /etc/security/limits.conf<br>
echo "ldap soft core 64" >> /etc/security/limits.conf<br><br> echo "root hard nofile 65000" >> /etc/security/limits.conf<br> echo "root soft nofile 65000" >> /etc/security/limits.conf<br>
echo "root hard core 64" >> /etc/security/limits.conf<br> echo "root soft core 64" >> /etc/security/limits.conf<br>5. verification of unindexed searches ("notes=U")<br>
6. nsscache on clients<br><br>we have approx 180 clients, and even without nsscache about 300 conns in parallel are ok...<br>You can also use logconv.pl -V logfile to analyse your logs and stats...<br><br><br><br><div class="gmail_quote">
2009/2/26 Chavez, James R. <span dir="ltr"><<a href="mailto:james.chavez@sanmina-sci.com">james.chavez@sanmina-sci.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br>
<br>
Thanks, I think that may be our issue. Can I ask what parameters you set<br>
to accomplish this?<br>
And also what is your "net.ipv4.tcp_keepalive_time" set to?<br>
<br>
Thanks again<br>
James<br>
<br>
<br>
We had the same problem. We set the idle timeout, and it was fixed. By<br>
default it doesn't timeout connections. We are only doing around 4K<br>
transactions a minute, but the idle connections would constantly grow to<br>
1024. Once putting in the timeout we maintain only about 30 idle at a<br>
time. We set our limit to 60 seconds.<br>
<br>
<br>
-Kevin<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com</a><br>
[mailto:<a href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com</a>] On Behalf Of Chavez,<br>
James R.<br>
Sent: Thursday, February 26, 2009 9:24 AM<br>
To: General discussion list for the Fedora Directory server project.<br>
Subject: RE: [Fedora-directory-users] Too many FDS open<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com</a><br>
[mailto:<a href="mailto:fedora-directory-users-bounces@redhat.com">fedora-directory-users-bounces@redhat.com</a>] On Behalf Of<br>
sigid@JINLab<br>
Sent: Thursday, February 26, 2009 12:43 AM<br>
To: General discussion list for the Fedora Directory server project.<br>
Subject: Re: [Fedora-directory-users] Too many FDS open<br>
<br>
Chavez, James R. wrote:<br>
> Hello Rich, list,<br>
><br>
><br>
> Earlier today we started getting this error in our FDS error log<br>
> repeatedly. Obviously connections were being refused at this point. I<br>
> had to restart the directory server for the server to function again.<br>
> Prior to releasing this box into production I did set the parameters<br>
> according to the Installation guide specifications. The output of<br>
> "ulimit -n" is 8192. The output of "sysctl -p" is below.(I increased<br>
> fs.file-max from 64000)Does anything look off?<br>
> net.ipv4.tcp_syncookies = 1<br>
> net.ipv4.tcp_keepalive_time = 300<br>
> fs.file-max = 128000<br>
> net.ipv4.ip_local_port_range = 1024 65000<br>
><br>
> I also changed the setting in the config from<br>
> nsslapd-maxdescriptors: 1024 to<br>
> nsslapd-maxdescriptors: 8192<br>
><br>
> Is there a way to tweak these settings so that this will not happen in<br>
<br>
> the future?<br>
> This is a dedicated consumer or read only replica.<br>
> Directory size is roughly 20,000 users.<br>
> We are running FC9 and FDS 1.1.1-3.<br>
> We are lacking in RAM but look to improve on that shortly.<br>
><br>
> I do see on the web past posts to this list regarding this error, I am<br>
<br>
> currently looking through them. Is there anyone out there that has<br>
> experienced this and gotten past it?<br>
><br>
> Thanks<br>
> James<br>
><br>
> [25/Feb/2009:13:30:08 -0600] - Not listening for new connections - too<br>
<br>
> many fds open<br>
> [25/Feb/2009:13:30:08 -0600] - Listening for new connections again<br>
> [25/Feb/2009:13:30:08 -0600] - Not listening for new connections - too<br>
<br>
> many fds open<br>
> [25/Feb/2009:13:30:08 -0600] - Listening for new connections again<br>
<br>
Is your client using windows OS? is there any posibilities that it could<br>
be virus replicating and distributing it self into networks?<br>
If storing file on domain/networks using FDS for authentication, the<br>
frequently authentication process should cause the "too many fds open".<br>
<br>
--<br>
<br>
We are using all Linux clients. I would not think it would be virus<br>
related. This implementation is actually replacing Windows.<br>
<br>
This box is the authentication source for all the Linux clients.<br>
What effect if any does replication have on fds or file descriptors..<br>
<br>
Thanks<br>
James<br>
<br>
CONFIDENTIALITY<br>
This e-mail message and any attachments thereto, is intended only for<br>
use by the addressee(s) named herein and may contain legally privileged<br>
and/or confidential information. If you are not the intended recipient<br>
of this e-mail message, you are hereby notified that any dissemination,<br>
distribution or copying of this e-mail message, and any attachments<br>
thereto, is strictly prohibited. If you have received this e-mail<br>
message in error, please immediately notify the sender and permanently<br>
delete the original and any copies of this email and any prints thereof.<br>
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS<br>
NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform<br>
Electronic Transactions Act or the applicability of any other law of<br>
similar substance and effect, absent an express statement to the<br>
contrary hereinabove, this e-mail message its contents, and any<br>
attachments hereto are not intended to represent an offer or acceptance<br>
to enter into a contract and are not otherwise intended to bind the<br>
sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any<br>
other person or entity.<br>
<br>
--<br>
Fedora-directory-users mailing list<br>
<a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br>
<br>
<br>
</div></div>Ahh, I think I found it for the idle connections.<br>
Thanks for the pointer, I appreciate it.<br>
<div><div></div><div class="Wj3C7c"><br>
James<br>
<br>
CONFIDENTIALITY<br>
This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.<br>
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.<br>
<br>
--<br>
Fedora-directory-users mailing list<br>
<a href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/fedora-directory-users" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a><br>
</div></div></blockquote></div><br>