<!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>