Univention Bugzilla – Bug 26806
Connector Tests 30.000 bzw. 50.000 Benutzer
Last modified: 2012-06-11 06:29:47 CEST
Es sollte ein Test mit 30.000 Benutzern (alle Benutzer in Domain Users) und 70.000 Benutzern (verteilt in Domain Users pro Schule) durchgeführt werden.
Auf S4 Seite sind aktuell ca. 13.000 Benutzer angelegt. Die Suche im S4 dauert relativ lange: S4: 9,6 Sekunden: univention-s4search cn=norbert125 cn 11,3 Sekunden: univention-s4search cn=norbert126 Im OpenLDAP sind bereits 30.000 Benutzer: 0,3 Sekunden: time univention-ldapsearch uid=norbert125 uid 0,2 Sekunden: univention-ldapsearch uid=norbert126 Wenn der Connector gestoppt wird, dann sind die S4 Daten ebenfalls OK: 0,4 Sekunden: univention-s4search cn=norbert127 cn 0,4 Sekunden: univention-s4search cn=norbert128 Im Connector Debug ist zu sehen, dass für das Ändern der primären Gruppe in S4 ca. 6 Sekunden benötigt werden: 30.04.2012 07:07:43,895 LDAP (INFO ): primary_group_sync_from_ucs: primary Group needed change of membership in S4 30.04.2012 07:07:49,758 LDAP (INFO ): primary_group_sync_from_ucs: changed primary Group in S4 Zwischen den beiden Meldungen ist lediglich der folgende Aufruf: self.lo_s4.lo.modify_s(compatible_modstring(object['dn']),[(ldap.MOD_REPLACE, 'primaryGroupID', rid)])
Created attachment 4348 [details] S4 Connector Debug Level 4 für einen Benutzer
(In reply to comment #1) > Im Connector Debug ist zu sehen, dass für das Ändern der primären Gruppe in S4 > ca. 6 Sekunden benötigt werden: > > 30.04.2012 07:07:43,895 LDAP (INFO ): primary_group_sync_from_ucs: > primary Group needed change of membership in S4 > 30.04.2012 07:07:49,758 LDAP (INFO ): primary_group_sync_from_ucs: > changed primary Group in S4 > > Zwischen den beiden Meldungen ist lediglich der folgende Aufruf: > self.lo_s4.lo.modify_s(compatible_modstring(object['dn']),[(ldap.MOD_REPLACE, > 'primaryGroupID', rid)]) Es gibt eine Möglichkeit direkt beim Anlegen die primäre Gruppe zu setzen: root@master322:~# ldbadd -H /var/lib/samba/private/sam.ldb s3.ldif ERR: Unwilling to perform : "The primary group isn't settable on add operations!" on DN CN=s3,CN=schueler,CN=users,OU=school,DC=deadlock32,DC=local Added 0 records with 1 failures root@master322:~# ldbadd -H /var/lib/samba/private/sam.ldb --controls="relax:0" s3.ldif Added 1 records with 0 failures root@master322:~#
Für den Listener sollten die beiden Variablen auf no gesetzt werden: listener/memberuid/skip: no listener/uniquemember/skip: no Wir sollten den Default in UCS wieder ändern, ich denke das ist nicht mehr notwendig. Ggf. sollten Listener / Notifier während des Imports angehalten werden.
Beim Import von 50000 Benutzern blieb der Import reproduzierbar bei ca. 29000 Benutzern stehen. Durch das Setzen der folgenden UCR Variablen vor dem Import lief der Import weiter: ucr set ldap/cachesize=20000 \ ldap/database/bdb/db_config_options=set_flags,set_lk_max_lockers,set_lk_max_locks,set_lk_max_objects \ ldap/database/bdb/set_cachesize="0 268435456 1" \ ldap/database/bdb/set_flags=DB_LOG_AUTOREMOVE \ ldap/database/bdb/set_lk_max_lockers=10000 \ ldap/database/bdb/set_lk_max_locks=10000 \ ldap/database/bdb/set_lk_max_objects=10000 \ ldap/database/type=bdb \ ldap/idlcachesize=20000 \ ldap/idletimeout=0 \ ldap/page-results=on \ ldap/sizelimit=400000 \ ldap/threads=64
Die 50.000 Benutzer Umgebung wurde erfolgreich aufgesetzt. KVM mit 4 CPUs und 2 GB RAM auf skepp. Der Import der Daten (es wurden alle Benutzer angelegt) dauerte 680 Minuten (11,33 Stunden). Der Listener und S4 Connector lief in der Zeit. Der Connector war nach 19,5 Stunden fertig. Die 50.000 Benutzer waren aufgeteilt auf ca. 150 Schulen.
Die Tests mit der 30.000 Benutzer Umgebung dauern deutlich länger, wenn alle Benutzer die gleiche primäre Gruppe haben. In diesem Fall wird alleine beim Ändern der Gruppe eine bis zu 5 MB grosse Pickle-Datei für den Connector geschrieben. Da bei jedem Erzeugen eines Benutzers Domain Users geändert wird, hatte ich teilweise knapp 30 GB Pickle-Daten. Ich habe einen zweiten Testlauf gestartet, in dem die Mitglieder aus Domain Users immer wieder entfernt werden. So ist es auch in der Kundenumgebung. Damit erwarte ich keine Performance Probleme mehr. Damit das zukünftig einstellbar ist, habe ich Bug #18247 auf 3.0-x gesetzt.
durch.(In reply to comment #7) > Die Tests mit der 30.000 Benutzer Umgebung dauern deutlich länger, wenn alle > Benutzer die gleiche primäre Gruppe haben. In diesem Fall wird alleine beim > Ändern der Gruppe eine bis zu 5 MB grosse Pickle-Datei für den Connector > geschrieben. Da bei jedem Erzeugen eines Benutzers Domain Users geändert wird, > hatte ich teilweise knapp 30 GB Pickle-Daten. > > Ich habe einen zweiten Testlauf gestartet, in dem die Mitglieder aus Domain > Users immer wieder entfernt werden. So ist es auch in der Kundenumgebung. Damit > erwarte ich keine Performance Probleme mehr. > > Damit das zukünftig einstellbar ist, habe ich Bug #18247 auf 3.0-x gesetzt. Der LDAP Import der 30.000 Benutzer war nach 296 Minuten (ca. 5 Stunden) durch. Der S4 Sync hat nochmal 5 Stunden länger benötigt und war somit nach 10 Stunden abgeschlossen.
Es wurde nun ein weitere Test-Import angestoßen. Import Datei: Die Import Datei definiert 40 Schulen mit ja 10 Klassenstufen und 4 Klassen pro Stufe. In jeder Klasse gibt es 30 Schüler. Für jede Klasse gibt es einen Lehrer, der Mitglied der aller Klassengruppen seiner Klassenstufe ist. Zusammen sind das dann 49600 Benutzer. UCS System: Ein UCS School Master (nicht SingleMaster) mit Samba4 und dem Samba4 Connector. Folgende Variablen wurden gesetzt: ucr set \ listener/memberuid/skip=no \ listener/uniquemember/skip=no\ ldap/cachesize=20000 \ ldap/database/bdb/db_config_options=set_flags,set_lk_max_lockers,set_lk_max_locks,set_lk_max_objects \ ldap/database/bdb/set_cachesize="0 268435456 1" \ ldap/database/bdb/set_flags=DB_LOG_AUTOREMOVE \ ldap/database/bdb/set_lk_max_lockers=10000 \ ldap/database/bdb/set_lk_max_locks=10000 \ ldap/database/bdb/set_lk_max_objects=10000 \ ldap/database/type=bdb \ ldap/idlcachesize=20000 \ ldap/idletimeout=0 \ ldap/page-results=on \ ldap/sizelimit=400000 \ ldap/threads=64
Bei den Tests bin ich in folgende Probleme gelaufen: * Bug #25813 (listener Speicherverbrauch) -> während des Test wurde alle 25min der listener neu gestartet * Bug #24273 (samba4 hat keine Änderungen mehr zugelassen) -> samba4 und connector neu gestartet Die Zeit des Import ist wegen der obigen Problem nun wenige aussagekräftig. Jedoch sah man, das das Anlegen von einzelnen Benutzern im Samba4 zum Ende des Imports recht zügig ging (<1s). Außerdem wurde nach dem Sync von UCS nach S4 keine weitere Änderung von S4 anch UCS geschrieben. Insgesamt hat es ca. 30h gedauert (bis auch der connector fertig war). Durch obiges Problem wurde aber mind. 1h verloren.
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"