It sounds like you may have stale client connections. There are a lot
of bad LDAP clients that never close their connections properly.
the way to work around this is to set a TCP keepalive to a shorter
than default. here is a good article on the subject
https://www.looklinux.com/how-to-configure-tcp-keepalive-setting-in-linux/
i recommend that heartbeats be initiated after 60 seconds after the
connection becomes idle and only a few failures before they are
dropped.
Also it's important to know all 3 settings must be set for this to
work. If you don't set all 3 related settings or if any of them are
set to 0 it will not do anything.
an other thing is the open file limits they must be set in two places
first is explained here
https://access.redhat.com/solutions/1257953#:~:text=service.,descriptors%20is%20limited%20to%20500%2C000.&text=The%20change%20is%20applied%20after,configuration%20and%20restarting%20the%20service.
The other is in the dse.ldif file
https://docs.kolab.org/administrator-guide/tweaking-389ds.html#:~:text=A%20389%20Directory%20Server%20is,open%20file%20descriptors%20from%201024.
On Fri, Nov 11, 2022 at 11:37 PM Howard Chu <hyc@symas.com> wrote:
>
> > Date: Fri, 11 Nov 2022 14:25:57 +0000
> > From: Tobias Ernstberger <tobias.ernstberger@de.ibm.com>
>
> > 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:
>
> Have you checked with e.g. lsof to see where all the FDs are being used? If you think there's only 1000
> incoming connections, probably there are other things going on e.g. DNS reverse lookups on client
> addresses, miscellaneous other files being opened, etc.
> >
> > 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?
>
> Fyi, OpenLDAP has no issue with multiple thousands of FDs being served concurrently...
> >
> >
> > 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/
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
> _______________________________________________
> 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
_______________________________________________
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
No comments:
Post a Comment