Bug 23762 - Join von Managed Clients wird durch passwordcache und faillog erheblich gebremst
Join von Managed Clients wird durch passwordcache und faillog erheblich gebremst
Status: RESOLVED DUPLICATE of bug 39957
Product: UCS
Classification: Unclassified
Component: Listener (univention-directory-listener)
UCS 2.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: Bugzilla Mailingliste
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-22 11:21 CEST by Roman Asendorf
Modified: 2015-11-17 08:50 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
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): 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 Roman Asendorf univentionstaff 2011-09-22 11:21:01 CEST
In einer Teststellung eines Kunden mit einer erheblich großen Anzahl Useraccounts (50T+) dauert der Joinvorgang bei den Modulen passwordcache und faillog erheblich lange (1 Stunde+, exakte Zeit wurde nicht ermittelt, da vorzeitig abgebrochen).
Comment 1 Philipp Hahn univentionstaff 2015-11-04 11:30:30 CET
Happened again in a UCS@school environment:
- UDL iterates through each cache entry and invokes "faillog" to remove it from the module list
- every single change is fsync()ed.

src/change.c:
 92 »···/* remove old entries for module */
 93 »···univention_debug(UV_DEBUG_LISTENER, UV_DEBUG_INFO,
 94 »···»···»···"remove old entries for module %s", handler->name);
 95 »···for (rv=cache_first_entry(&dbc_cur, &dn, &cache_entry); rv != DB_NOTFOUND;                                                                                                                                                           
 96 »···»···»···rv=cache_next_entry(&dbc_cur, &dn, &cache_entry)) {
 97 »···»···if (rv == -1) continue;
 98 »···»···if (rv < 0) break;
 99 
100 »···»···cache_entry_module_remove(&cache_entry, handler->name);
101 »···»···cache_update_or_deleteifunused_entry(0, dn, &cache_entry);
102 »···»···cache_free_entry(&dn, &cache_entry);
103 »···}


# univention-ldapsearch -LLLo ldif-wrap=no dn | grep -c ^dn
32253


Temporarily solved by putting the UDL cache in a tmpfs:

cd /var/lib/univention-directory-listener
mkdir TEST
mount -t tmpfs -o size=1G udl TEST
cp -pr cache.db cache.db.lock notifier_id handlers TEST/
/usr/sbin/univention-directory-listener ... -c TEST/
...
rsync -a TESTS/ ./
umount ./TEST
Comment 2 Janis Meybohm univentionstaff 2015-11-09 16:22:43 CET
Ticket#2015110421000101

Customer system also suffered from this.
Comment 3 Michael Grandjean univentionstaff 2015-11-11 10:58:12 CET
I guess ticket from comment #1 is 2015110221000211
Comment 4 Michael Grandjean univentionstaff 2015-11-16 17:06:34 CET
Again at Ticket#2015111621000418
Comment 5 Philipp Hahn univentionstaff 2015-11-17 08:50:22 CET

*** This bug has been marked as a duplicate of bug 39957 ***