<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1605" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=515405618-26022009>Andrey, </SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=515405618-26022009>Thanks this actually helps alot towards my
understanding. Appreciate the information, that logconv.pl is
slick!</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=515405618-26022009></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=515405618-26022009>James</SPAN></FONT></DIV><FONT face=Arial color=#0000ff
size=2></FONT><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT face=Tahoma
size=2></FONT><BR> </DIV>
<DIV></DIV>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="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<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>
<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>
</BODY></HTML>