Bug 58119 - Performance Degradation When Deleting Computer Objects With Dedicated Admin Account
Summary: Performance Degradation When Deleting Computer Objects With Dedicated Admin A...
Status: CLOSED FIXED
Alias: None
Product: UCS
Classification: Unclassified
Component: UDM (Generic)
Version: UCS 5.0
Hardware: Other Linux
: P5 normal
Target Milestone: UCS 5.2-1-errata
Assignee: Florian Best
QA Contact: Johannes Lohmer
URL: https://git.knut.univention.de/univen...
Keywords:
Depends on:
Blocks: 58128
  Show dependency treegraph
 
Reported: 2025-03-25 17:20 CET by Finn David
Modified: 2025-04-02 14:09 CEST (History)
4 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 4: Minor Usability: Impairs usability in secondary scenarios
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 3: A User would likely not purchase the product
User Pain: 0.137
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2025030321000975
Bug group (optional): UCS Performance
Customer ID: 39720
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Finn David univentionstaff 2025-03-25 17:20:29 CET
#
# Environment
#

UCS: 5.0-10 errata1224
Installed: prometheus-node-exporter=2.0.1 samba4=4.16 self-service=5.0 self-service-backend=5.0 ucsschool=5.0 v6

#
# Summary
#

Deleting computer objects in UCS takes significantly longer when the user executing the deletion has many group memberships.
The delay occurs during the cleanup of DNS host records in /usr/lib/python3/dist-packages/univention/admin/handlers/__init__.py.

#
# Steps to Reproduce
#

- Use a UCS user with few group memberships to delete a computer and its referring objects.
- Use a UCS user with many group memberships to delete a computer and its referring objects.
- Compare execution times, particularly in the cleanup of DNS host records.

#
# Observed Behavior
#

The deletion process takes significantly longer when executed by a user with many group memberships.
Debugging output indicates that most of the delay happens during the lookup() or open() calls in the following code:

        start = time.time()
        for irecord in univention.admin.modules.lookup('dns/host_record', self.co, self.lo, base=self.lo.base, scope='sub', superordinate=zoneObj):
            irecord.open()
            new_entries = list(set(irecord['a']) - ips)
            if len(new_entries) != len(irecord['a']):
                log.debug('Entry found in "%s":\n%s ==> %s', irecord.dn, irecord['a'], new_entries)
                irecord['a'] = new_entries
                irecord.modify()
        end = time.time()
        duration = end - start
        log.debug('clean up host records %.4f Sekunden', duration)

Log output shows a significant delay:

        25.03.25 15:52:25.340  ADMIN ( ALL ) : __init__.cleanup:3450: clean up host records 11.4635 Sekunden

No debug message "Entry found in ..." appeared in management-console-module-udm.log, indicating that the code never entered
the if block containing irecord.modify(). This strongly suggests that the slowdown is caused by univention.admin.modules.lookup()
or irecord.open(), likely due to extensive LDAP permission checks related to group memberships.
Comment 1 Finn David univentionstaff 2025-03-26 14:00:44 CET
Further debugging showed that the number of group memberships is not essential to the cause:

Another test with a dedicated admin account with only 4 groups also showed similar slow results. This still indicates a problem with LDAP permission checks, but not primarily related to the number of group memberships.
Comment 3 Florian Best univentionstaff 2025-03-28 12:51:04 CET
The behavior was introduced in Bug #26400 git:93ae62a30c3c3d720b6f8dff264f80c008553eca and looks like unnecessary duplicated logic of what is done already a few lines before.
We also verified this in the customer environment that the host records for that zone are already removed during that performance problem.
Nevertheless we can simply add a LDAP filter which speeds up the search drastically, if there are 12014 host records in that zone.
Comment 4 Florian Best univentionstaff 2025-03-28 13:55:24 CET
While we could clean up a lot here, we make a simple fix, which only adds a correct LDAP filter to the dns/host_record search which reduced the time from 12 seconds to under 1 second in the customer environment.

univention-directory-manager-modules.yaml
35d6ae98b7e9 | perf(udm): fix performance of computer removal

univention-directory-manager-modules (17.0.31)
35d6ae98b7e9 | perf(udm): fix performance of computer removal
Comment 5 Johannes Lohmer univentionstaff 2025-03-28 13:59:08 CET
errata-yaml ok
debian paket ok
problem reproduced ok
problem fixed ok
code-review ok
Comment 6 Christian Castens univentionstaff 2025-04-02 14:09:59 CEST
<https://errata.software-univention.de/#/?erratum=5.2x56>