Bug 57065 - Use "multival" for uniqueMember and memberUid to improve performance of group membership changes
Use "multival" for uniqueMember and memberUid to improve performance of group...
Status: NEW
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 5.2
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
UCS maintainers
https://www.openldap.org/doc/admin25/...
:
Depends on: 52175
Blocks:
  Show dependency treegraph
 
Reported: 2024-02-16 12:00 CET by Jürn Brodersen
Modified: 2024-02-16 12:00 CET (History)
2 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Large environments, UCS Performance
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jürn Brodersen univentionstaff 2024-02-16 12:00:01 CET
+++ This bug was initially created as a clone of Bug #52175 +++

Same idea as in bug #52175. This could improve the performance as well. This option is only available for slapd 2.5, so it can not be used in 5.0!

As I understand it this would also need a database reload, so we might want to consider bug #52175 and this bug for the 5.0 -> 5.2 upgrade.

A performance improvement for group membership updates would be a very welcome addition for large school environments.

-----------------------------------------

6.2.5.10. multival: { <attrlist> | default } <integer> hi,<integer> lo

Specify the number of values for which a multivalued attribute is stored in a separate table. Normally entries are stored as a single blob inside the database. When an entry gets very large or contains attributes with a very large number of values, modifications on that entry may get very slow. Splitting the large attributes out to a separate table can improve the performance of modification operations. The threshold is specified as a pair of integers. If the number of values exceeds the hi threshold the values will be split out. If a modification deletes enough values to bring an attribute below the lo threshold the values will be removed from the separate table and merged back into the main entry blob. The threshold can be set for a specific list of attributes, or the default can be configured for all other attributes. The default value for both hi and lo thresholds is UINT_MAX, which keeps all attributes in the main blob.

In addition to increasing write performance of operations the use of multival can also decrease fragmentation of the primary MDB database.