Hi, folks
I'm hoping to use 389 DS to replace our ancient Sun DS 5.2 service.
I've hit a snag with my 389 development server; it's performance far worse
than the 10 year-old servers it's intended to replace.
Things looked promising: the old directory data has been imported (with
only minor changes), read requests perform reasonably well, and isolated
write requests are ok.
However, even after a small number (typically 6) of consecutive write requests
(basic attribute changes to a single entry, say) the ns-slapd process hits >100%
CPU (of 2 CPUs) and stays there for *at least* 10 seconds per update, and blocks
the client process attempting the update.
I can't see anything obvious in the performance counters or the logs to suggest
a problem. The updates are logged with "etime=0" in the access log.
I've tried enabling different log levels in the error log.
Is it normal for the Plugin level to show constant re-scanning of CoS templates?
I'd be very grateful for any suggestions of how I can go about tracing where the
Problem might be and how to resolve it...
Best wishes,
Steve
Details
The RHEL6.5 server is a VMware ESXi VM with 8GB RAM and 2x CPUs,
and is running the latest EPEL package for RHEL6 (v1.2.11.15-32).
(After a package upgrade a few weeks ago, I ran "setup-ds-admin.pl -u").
The directory contains in excess of 200,000 entries, and
its databases consume over 3.5GB on disk.
The userRoot database has therefore been configured with a 4GB cache
(and the general LDBM max cache is set at 6GB - though it's quite possible
I haven't understood how to set these correctly - I've tried smaller numbers of
each).
The directory contains custom attributes, some of which are CoS,
and many of which have been indexed (AFAIK, all attributes have been re-indexed).
No replication has been configured so far.
___________________________________________________________
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/
___________________________________________________________