ACLPB_MAX_SELECTED_ACLS and aci cache overflows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

A bit unsure whether this should be posted to the user- or dev- list, but
landed on the former.

We've recently been attempting to move an existing ldap-structure from a
Sun 5.2 server, to Fedora DS 1.1. The move itself was relatively painless
apart from one thing: When running certain searches, we'd see loads of
"aci cache overflown" messages in the logs, and performance would slow to
a crawl. This is probably due to parts of the structure making very heavy
use of ACIs.

A C/C++ proficient coworker tracked down acl.c and the constant
ACLPB_MAX_SELECTED_ACLS in acl.h. By bumping this from the original 200 to
something higher, the cache overflows stopped, and searches completed
normally. There doesn't seem to be any bad side-effects.

For my own peace of mind, however, I'd be interested in hearing thoughts
on bumping this value, and the reason it's 200.

- Any chance this value might become configurable in future versions?
- Can you think of any unfortunate side-effects down the road from bumping
this value, aside from increased memory-usage?
- Is '200' a more or less arbitrarily chosen round number deemed
sufficient, or is there a very specific reason it isn't higher? Ie: a size
of 200 should be sufficient for any structure, and overflows might
indicate excessive use of ACIs and a structure that should be reworked?

(actually not excluding that last one possibility anyway, as evaluating an
ACI at every node probably is a performance-killer as far as searches go)


I'm interested in hearing any thoughts on this, even wild tangents :)

--
Regards,
Audun

--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users

[Index of Archives]     [Fedora Directory Users]     [Fedora Directory Devel]     [Fedora Announce]     [Fedora Legacy Announce]     [Kernel]     [Fedora Legacy]     [Share Photos]     [Fedora Desktop]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite News]

  Powered by Linux