[Date Prev][Date Next]
Re: (ITS#8669) Slapd service becomes unresponsive intermittently
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#8669) Slapd service becomes unresponsive intermittently
- From: firstname.lastname@example.org
- Date: Wed, 07 Jun 2017 16:27:11 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
--On Wednesday, June 07, 2017 7:07 AM -0600 Joaquin Estrada=20
> We are running the Berkley DB back-end, =C2=B3back-bdb=C2=B2 in the =
> Our server vendor did the upgrade to version 2.4.39 last year in April. =
> asking them about upgrading to a newer version, as a potential fix, I was
> told the last version in the RHEL repository that they can upgrade to is
> 2.4.40. I=C2=B9m not certain that our vendor will support our choice to
> upgrade to a newer version than what RHEL provides them in the
> repository, but if it will fix our problem, I=C2=B9ll have to push the
> envelope on that matter.
> Were there any known fragmentation issues with back-bdb in the 2.4.39
> version that could also be causing these pauses?
No, back-bdb is not remotely the same as back-mdb. However, I've no idea=20
what options RedHat compiles their BDB library with and there were specific =
options that had an effect on OpenLDAP. Generally, I would note that the=20
back-bdb backend and back-hdb backends are deprecated at this point.
> Is it possible we have the idletimeout set too high and it should be
> lowered? I=C2=B9m wondering if there is some sweet-spot value for this
> particular setting.
I generally leave it unset unless one is encountering an issue of running=20
out of connections. Generally, it would be fairly strange for idletimeout=20
to affect things this way at all. It simply drops idle connections based=20
off of the timer. Disabling rate throttling in rsyslogd is a good idea,=20
but may be unrelated as well. We've also seen cases with RHEL7 where Redhat =
has set things up so that journald also gets all the syslog messages, which =
causes severe performance degredation.
You could spend some time seeing if you can isolate an exact cause. For=20
example, set loglevel to 0 and see if you still encounter the issue. If=20
you do, it is unrelated to syslog activity.
Another test would be to set idletimeout to 0. If you still encounter the=20
issue, it is unrelated to idle connections being dropped. etc.
As Michael noted, Redhat builds are somewhat questionable as they make=20
various changes to the code base that the OpenLDAP project have not been=20
reviewed. Your issues may or may not be related to such a change, it's=20
generally impossible to know.
Hope that helps.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: