Kevin, Thanks again I found the idle timeout setting after looking around in the console as well yesterday. It is added to dse under the dn: cn=config entry as "nsslapd-idletimeout: 60". I imagine an ldapmodify command could be used to add this but not sure about that. One thing is now I get these entries in the access logs. " conn=1461 op=-1 fd=64 closed error 11 (Resource temporarily unavailable) - T1" They do not seem to harm anything but it looks like my connections are not being closed properly or are being left open at least. I am trying to figure out why that is the case. Even if I bump this up to 300 seconds the above entries persist. It was suggested I run logconv and I did. I got some output below which I think if I can clean up my Directory will run smooth. Some pointers from the list on how to clean this up is appreciated. 1. You have unindexed searches, this can be caused from a search on an unindexed attribute, or your returned results exceeded the allidsthreshold. Unindexed searches are not recommended. To refuse unindexed searches, switch 'nsslapd-require-index' to 'on' under your database entry (e.g. cn=UserRoot,cn=ldbm database,cn=plugins,cn=config). ## Will refusing unindexed searches negatively impact user authentication in any way? Although I looked at the etimes on the majority of these and they are all at 0 or 1.## 2. You have some connections that are are being closed by the idletimeout setting. You may want to increase the idletimeout if it is set low. ## Are these Idle kills significant? They seem not to be as the directory still seems to perform.## 3. You have a significant difference between binds and unbinds. You may want to investigate this difference. ## Many of the binds are anonymous, will setting clients with a abinddn and biddn password help here? Why is it that the clients do not unbind?## 4. You have more abnormal connection codes than cleanly closed connections. You may want to investigate this difference. ## This stems from many B1 connection codes in my access log..It is suggested in some documentation to increase the nsslapd-maxbersize entry. However I do not see that in the config file. Does anyone have any knowledge of this setting?# Thanks James -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Zona, Kevin Sent: Friday, February 27, 2009 8:05 AM To: General discussion list for the Fedora Directory server project. Subject: RE: Too many FDS open In the IDM console GUI for the Directory server, I change the "Idle Timeout" on the Performance tab under the Configutation tab. After typing that sentence I wish I had found it somewhere in a command line... -Kevin -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Chavez, James R. Sent: Thursday, February 26, 2009 11:20 AM To: General discussion list for the Fedora Directory server project. Subject: RE: Too many FDS open Thanks, I think that may be our issue. Can I ask what parameters you set to accomplish this? And also what is your "net.ipv4.tcp_keepalive_time" set to? Thanks again James We had the same problem. We set the idle timeout, and it was fixed. By default it doesn't timeout connections. We are only doing around 4K transactions a minute, but the idle connections would constantly grow to 1024. Once putting in the timeout we maintain only about 30 idle at a time. We set our limit to 60 seconds. -Kevin -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of Chavez, James R. Sent: Thursday, February 26, 2009 9:24 AM To: General discussion list for the Fedora Directory server project. Subject: RE: Too many FDS open -----Original Message----- From: fedora-directory-users-bounces at redhat.com [mailto:fedora-directory-users-bounces at redhat.com] On Behalf Of sigid at JINLab Sent: Thursday, February 26, 2009 12:43 AM To: General discussion list for the Fedora Directory server project. Subject: Re: Too many FDS open Chavez, James R. wrote: > Hello Rich, list, > > > Earlier today we started getting this error in our FDS error log > repeatedly. Obviously connections were being refused at this point. I > had to restart the directory server for the server to function again. > Prior to releasing this box into production I did set the parameters > according to the Installation guide specifications. The output of > "ulimit -n" is 8192. The output of "sysctl -p" is below.(I increased > fs.file-max from 64000)Does anything look off? > net.ipv4.tcp_syncookies = 1 > net.ipv4.tcp_keepalive_time = 300 > fs.file-max = 128000 > net.ipv4.ip_local_port_range = 1024 65000 > > I also changed the setting in the config from > nsslapd-maxdescriptors: 1024 to > nsslapd-maxdescriptors: 8192 > > Is there a way to tweak these settings so that this will not happen in > the future? > This is a dedicated consumer or read only replica. > Directory size is roughly 20,000 users. > We are running FC9 and FDS 1.1.1-3. > We are lacking in RAM but look to improve on that shortly. > > I do see on the web past posts to this list regarding this error, I am > currently looking through them. Is there anyone out there that has > experienced this and gotten past it? > > Thanks > James > > [25/Feb/2009:13:30:08 -0600] - Not listening for new connections - too > many fds open > [25/Feb/2009:13:30:08 -0600] - Listening for new connections again > [25/Feb/2009:13:30:08 -0600] - Not listening for new connections - too > many fds open > [25/Feb/2009:13:30:08 -0600] - Listening for new connections again Is your client using windows OS? is there any posibilities that it could be virus replicating and distributing it self into networks? If storing file on domain/networks using FDS for authentication, the frequently authentication process should cause the "too many fds open". -- We are using all Linux clients. I would not think it would be virus related. This implementation is actually replacing Windows. This box is the authentication source for all the Linux clients. What effect if any does replication have on fds or file descriptors.. Thanks James CONFIDENTIALITY 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. 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. -- Fedora-directory-users mailing list Fedora-directory-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users Ahh, I think I found it for the idle connections. Thanks for the pointer, I appreciate it. James -- Fedora-directory-users mailing list Fedora-directory-users at redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users CONFIDENTIALITY 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. 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.
