We've been really pleased with our 389 servers, which have been successfully running
as a multi-master pair in production for 7 weeks, following (elapsed) months of
Unfortunately, in the last few days their performance has radically degraded to the point
where they are becoming unusable due to excessive memory consumption. At first, we
suspected a recent update to the package - but are no longer convinced that's the
I'd really appreciate any suggestions on how to troubleshoot this further.
389 ignores its 4GB userRoot nsslapd-cachememsize and its overall memory usage expands to
encompass all of the server's 8GB RAM - and a large proportion of its 10GB swap. The
service eventually fails, and hangs the server.
As per the previous guidance for RHEL 6 installations, we had been using the packages from
the COPRS repository (389-ds-base-188.8.131.52-1 aka 184.108.40.206 B2014.247.2316).
(As several of our applications require CoS/dynamic attributes, earlier versions of the
RHEL packages were unusable for us until this fix was ported:
- which was only recently applied to
the RHEL packages).
Due to an unfortunate misconfiguration, the production servers received automated updates
- and were upgraded to RHEL 6.6, the latest COPRS package (220.127.116.11-1), and a new kernel
The directory contains 236,340 entries, and id2entry.db4 is 3.6GB.
We've tried to balance isolating the problem with maintaining a critical service for
* An additional 8GB RAM (and additional CPU) was added to the VM to mitigate the
immediate problem - but this was soon swallowed up too.
* Attempting to reproduce this on our equivalent development servers has not been
successful, even when subjecting them to load.
* Downgrading to the RHEL packages (18.104.22.168-48 aka 22.214.171.124 B2014.300.2010) as
per Noriko's very helpful procedure below (though I stopped the services prior to the
downgrade). No obvious difference.
* Rebooting into the previous kernel (2.6.32-431.29.2). This slowed the problem,
but only to an extent.
Not attempted yet:
* Turning on debugging on the production servers, as they're in a fragile and
* Building the latest 1.3.x build on RHEL 6. Will be attempting this soon...
* Installing RHEL 7.0 on a fresh VM, as we don't have experience with 7 yet.
* Downgrading to the previous COPRS package, as no longer publicly available(?)
Please let me know if more information would help...
[mailto:firstname.lastname@example.org] On Behalf Of Noriko Hosoi
Sent: 25 October 2014 00:05
General discussion list for the 389 Directory server project.
Subject: [389-users] Please take an action: 389 Directory Server 1.2.11.X Discontinued for
389 Directory Server 1.2.11.X Discontinued for EL6
The 389 Directory Server team announces the binary release of 389-ds-base version 1.2.11
for EL6 will be stopped via temporary COPR repository. We encourage you to switch it to
the official version included in the Red Hat Enterprise Linux 6 distribution or its
How to switch to the official version
Remove a yum repo file which points to the temporary COPR repository (e.g.,
nhosoi-389-ds-base-epel6-epel-6.repo) from /etc/yum.repos.d.
If the current 389 Directory Server 1.2.11 has the greater build number than 15, for
instance, 126.96.36.199, downgrade it once by "yum downgrade" as follows.
yum downgrade 389-ds-base 389-ds-base-libs
Then, upgrade to make sure you have the latest version.
yum upgrade 389-ds-base
After upgrade completes, run setup-ds-admin.pl -u to update your directory server/admin
more information about the initial installation, setup, and upgrade
information about source tarballs and SCM (git) access.
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/