Friday, November 18, 2022

[389-users] Re: FileDescriptors exhausted


On 11/18/22 9:07 AM, Tobias Ernstberger wrote:
We are using 1.3.8.4 - any remarks regarding this version?

This is a very old version.  It might even be using the "nunc-stans" connection handler which was removed in newer versions because of stability issues.  Check this setting under cn=config:  nsslapd-enable-nunc-stans

If it is set to "on", try setting it to "off", which requires a restart, and see how the server behaves.

Note the 1.3.x series is no longer maintained.  At least try and go to 1.3.10 if you must stay on 1.3.x, but you should seriously look into 389-ds-base-2.x series...

HTH,

Mark

    To avoid idle/stale connections we've set nslapd-ideltimeout and we see now a lower average number of open connections, so this is a first improvement.   We also plan to look into nslapd-ioblocktimeout.      Mit freundlichen Grüßen / Kind regards    Tobias Ernstberger  IT-Architect Identity and Access Management  IBM Security Expert Labs  +49 151 15138929  tobias.ernstberger@de.ibm.com    IBM Security    IBM Deutschland GmbH  Vorsitzender des Aufsichtsrats: Sebastian Krause  Geschäftsführung: Gregor Pillen (Vorsitzender), Nicole Reimer, Gabriele Schwarenthorer, Christine Rupp, Frank Theisen   Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB 14562 / WEEE-Reg.-Nr. DE 99369940  https://www.ibm.com/privacy/us/en/    -----Original Message-----  From: Mark Reynolds <mareynol@redhat.com>   Sent: Samstag, 12. November 2022 22:29  To: General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org>; Tobias Ernstberger <tobias.ernstberger@de.ibm.com>  Subject: [EXTERNAL] Re: [389-users] FileDescriptors exhausted    What version of 389-ds-base are you using?    In newer versions we automatically set the server FD limit to the maximum allowed per process.  This can be seen in the errors log at server startup:    For example:         [09/Nov/2022:16:23:07.100244932 -0500] - INFO - main - Setting the maximum file descriptor limit to: 524288    389-ds also has no issues with handling 1000's of concurrent connections.  So I suspect this is just a tuning issue, but let us know what version you are running so we can give you the proper tuning advice.    Now if you have issues with idle/stale connections, or bad clients, then look into tuning nsslapd-ioblocktimeout (e.g. 10000 => 10 seconds), and maybe nslapd-idletimeout.    Mark      On 11/11/22 9:25 AM, Tobias Ernstberger wrote:  
Hello,    we're observing the following error message:  "ERR - accept_and_configure - PR_Accept() failed, Netscape Portable Runtime error -5971 (Process open FD table is full.)"  Looks like the file descriptors are exhausted, probably mainly used by incoming TCP Connections (based on our investigation regarding open FDs).  We've set (and checked using the runtime information in   /proc/PID/limits) the ulimits and the nsslapd-maxdescriptors to many   thousands (while having about 1000 open connection regularly)    We are investigating in multiple directions here, and have some questions - any input is appreciated:    1) We acknowledge that exhausted FDs prevent additional connections to be opened. But we also see, that existing connections are getting unusable, too. Is this a known behaviour? Can this be avoided?  2) Is there any chance to limit the number of open connections (lower   than the max FDs)? (trying to achieve that existing connections still   work)  3) What are best practice to prevent the ldap server from getting completely useless (until restart) if a client opens many connections?  4) Any additional remarks to prevent this situation?      Kind regards    Tobias Ernstberger  IBM Security    IBM Deutschland GmbH  Vorsitzender des Aufsichtsrats: Sebastian Krause  Geschäftsführung: Gregor Pillen (Vorsitzender), Nicole Reimer,   Gabriele Schwarenthorer, Christine Rupp, Frank Theisen Sitz der   Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, HRB   14562 / WEEE-Reg.-Nr. DE 99369940 https://www.ibm.com/privacy/us/en/  _______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org To   unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  Fedora Code of Conduct:   INVALID URI REMOVED  t.org_en-2DUS_project_code-2Dof-2Dconduct_&d=DwIDaQ&c=jf_iaSHvJObTbx-s  iA1ZOg&r=QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQb  HvIjH7QUwVBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=nl0Y6bzC4oV7Fq65kK  7mta567ymyCTlvchXpD0lpfFI&e= List Guidelines:   INVALID URI REMOVED  _wiki_Mailing-5Flist-5Fguidelines&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=  QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQbHvIjH7QUw  VBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=amrVoneRH3WfaEhePWxL_VqAjZb  Va4T7DQmwg3u1pAg&e= List Archives:   INVALID URI REMOVED  ct.org_archives_list_389-2Dusers-40lists.fedoraproject.org&d=DwIDaQ&c=  jf_iaSHvJObTbx-siA1ZOg&r=QvSqS0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m  =DMcmEB9W7URvfQbHvIjH7QUwVBMYM4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=9R  1JhXk09rfm36xJCxqGK_IWV2xcxHge0HfTDPNyY0s&e=  Do not reply to spam, report it:   INVALID URI REMOVED  2Dinfrastructure_new-5Fissue&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=QvSqS  0gPOnxXMMO9G-eW10oOiG0sRPGfH9BtVh8hhnU&m=DMcmEB9W7URvfQbHvIjH7QUwVBMYM  4zrzEUoukXTViUo_rPc8hdPmOLfpSDFOzwp&s=519Dp4E1pshVxNLpfuS0Cr3H0j8WpKYQ  RbBGujE7X1U&e=  
  --  Directory Server Development Team    _______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines  List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue  
--   Directory Server Development Team

No comments:

Post a Comment