On 02/19/2014 04:56 PM,
Russell Beall wrote:
Hi all,
We've just set up monster-sized server nodes to run
389 as a replacement to Sun DS. I've been running my
tests and I am pleased to report that the memory issue
seems to be in check with growth only up to double the
initial memory usage after large quantities of
ldapmodify calls. We have plenty of room in these
boxes to accommodate caching the entire database.
The key blocker on this is still the ACL processing
times for which I have been unable to find a decent
resolution. We have 135 ACIs at the root of the
suffix. When I comment out most of them but leave one
service account active, processing times are very
nicely fast. When I leave them all on, that same
service account takes 2.5 seconds to respond when only
one request is pending. A new kink in the puzzle here
which is probably going to be a deal breaker is that
if I run the same request on multiple threads, each
thread takes proportionately longer to respond
depending on the number of threads. If I have 12
threads going doing a simple lookup, each thread
responds in 45-55 seconds. If I have 24 threads
going, each thread takes 1m45s - 1m55s to respond.
The box has 32 cores available. While processing,
each thread is burning 100% of an available CPU thread
for the entire time. Theoretically when up to 32
requests are simultaneously processing, each thread
should return in 2.5 seconds just as if it were one
thread.
Note that the directory server performance does not scale
linearly with the number of cores. At some point you will
run into thread contention. Also things like replication
compete for thread resources.
Since all threads are burning 100% the entire time,
it doesn't seem like that would be caused by simple
thread locking where some threads are waiting for
others.
No, see below.
I'm thinking the system is not properly configured
in some way and there is a system bottleneck blocking
the processing. When burning the CPU there is very
little percentage allocated to the user percentage,
most of the CPU usage is listed under the system CPU
usage. Is this normal, or is this indicative of some
system layer that is bottlenecking the processing?
Sounds like the ACI may be doing some sort of unindexed
internal search.
Have you narrowed it down to a particular ACI that is
causing the problem?
Another question I posed earlier is whether or not
it is possible to replicate three subtrees
independently and then keep the aci entry at the root
suffix independent so it can be set separately for
multiple downstream replicants. That way we could
possibly subdivide the service accounts across
different nodes. Is that possible?
No.
Thanks,
Russ.
==============================
Russell
Beall
Systems Programmer IV
Enterprise
Identity Management
University of Southern
California
==============================
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--