We are using 1.3.8.4 - any remarks regarding this version? 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 [email protected] 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 <[email protected]> Sent: Samstag, 12. November 2022 22:29 To: General discussion list for the 389 Directory server project. <[email protected]>; Tobias Ernstberger <[email protected]> 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 -- [email protected] To > unsubscribe send an email to [email protected] > 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 -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
