On 02/28/2014 05:26 PM, Russell Beall wrote:
Yes. Many rules are groupdn based, sometimes with multiple rules
where the dn must be in some groups but not in others. And some of
the groups have 50,000-100,000+ members.
Breaking out the groupdn checks into something very simple did not
On Mar 3, 2014, at 6:39 AM, Rich Megginson
rmegg...@redhat.commailto:rmegg...@redhat.com wrote:
On 02/28/2014 05:26 PM, Russell Beall wrote:
This has led me to finally discover the true bottleneck in the indexing of one
particular attribute. The attribute is a custom attribute similar to
On Mar 3, 2014, at 11:01 AM, Rich Megginson
rmegg...@redhat.commailto:rmegg...@redhat.com wrote:
On 03/03/2014 11:38 AM, Russell Beall wrote:
On Mar 3, 2014, at 6:39 AM, Rich Megginson
rmegg...@redhat.commailto:rmegg...@redhat.com wrote:
On 02/28/2014 05:26 PM, Russell Beall wrote:
This has
On 02/28/2014 01:31 AM, Rich Megginson wrote:
On 02/27/2014 05:06 PM, Russell Beall wrote:
Thanks again for your comments on this.
I tried an alternate approach in which I deleted a number of relevant
indexes that theoretically should be needed all across the ACIs. I
was shocked to find
Yes. Many rules are groupdn based, sometimes with multiple rules where the dn
must be in some groups but not in others. And some of the groups have
50,000-100,000+ members.
Breaking out the groupdn checks into something very simple did not change the
performance at all. Changing all the
Thanks again for your comments on this.
I tried an alternate approach in which I deleted a number of relevant indexes
that theoretically should be needed all across the ACIs. I was shocked to find
out that the processing time was totally unaffected. Then I took it a step
further and deleted
On 02/27/2014 05:06 PM, Russell Beall wrote:
Thanks again for your comments on this.
I tried an alternate approach in which I deleted a number of relevant
indexes that theoretically should be needed all across the ACIs. I
was shocked to find out that the processing time was totally
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
On 07/09/2013 12:01 AM, Russell Beall wrote:
Hi Ludwig,
Thanks for responding on this.
After further experimentation and re-applying ACI files from earlier times, I
find that the condition probably has been present the whole time and I just
didn't notice because I was focusing on
Hi Ludwig,
Thanks for responding on this.
After further experimentation and re-applying ACI files from earlier times, I
find that the condition probably has been present the whole time and I just
didn't notice because I was focusing on performance related to our Directory
Manager-based
Hi,
yes, aci processing can become very expensive if you have a lot of acis
are used, the code tries to do soem optimizations to cache evaluation,
but a small change in acis could prevent the use of cached results. So
if you do not have a full set of acis from the better times it will be
11 matches
Mail list logo
