|
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
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
