Univention Bugzilla – Bug 28679
OpenLDAP in UCS 3.1: Performance ldapdelete / Index
Last modified: 2018-04-14 13:43:50 CEST
+++ This bug was initially created as a clone of Bug #27992 +++ Bei einem Kundenprojekt (1 GiB VM auf boksel, Standarteinstellung) trat folgendes Problem auf: Das Löschen von 22k Benutzer dauerte sehr lange (gefühlt 3 Benutzer/s). Ein strace auf dem slapd hat gezeigt, daß vorallem die Zeit für die Aktualisierung der Indexes benötigt wurde, deren Daten dann auch per fdatasync() auf die Platte gezwungen wurde. Folgende Variante war dagegen heute innerhalb 1m46.016s beendet: /etc/init.d/slapd stop ucr unset ldap/index/eq ldap/index/pres ldap/index/sub slapindex /etc/init.d/slapd start time univention-ldapsearch -xLLLb "ou=metadir2,$(ucr get ldap/base)" -s one dn | ldapsearch-wrapper | ldapsearch-decode64 | sed -ne 's/^dn: //p' | ldapdelete -xD "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret -f /dev/stdin /etc/init.d/slapd stop ucr set ldap/index/eq=aRecord,automountInformation,cNAMERecord,cn,description,dhcpHWAddress,displayName,gidNumber,givenName,homeDirectory,krb5PrincipalName,macAddress,mail,mailAlternativeAddress,mailPrimaryAddress,memberUid,objectClass,ou,pTRRecord,relativeDomainName,sambaAcctFlags,sambaDomainName,sambaGroupType,sambaPrimaryGroupSID,sambaSID,sambaSIDList,secretary,sn,uid,uidNumber,uniqueMember,univentionCanonicalRecipientRewriteEnabled,univentionLicenseModule,univentionLicenseObject,univentionMailHomeServer,univentionNagiosHostname,univentionObjectType,univentionPolicyReference,univentionServerRole,univentionService,univentionShareGid,univentionShareSambaName,univentionShareWriteable,univentionUDMPropertyCLIName,univentionUDMPropertyDefault,univentionUDMPropertyDeleteObjectClass,univentionUDMPropertyDoNotSearch,univentionUDMPropertyHook,univentionUDMPropertyLayoutOverwritePosition,univentionUDMPropertyLayoutOverwriteTab,univentionUDMPropertyLayoutPosition,univentionUDMPropertyLayoutTabAdvanced,univentionUDMPropertyLayoutTabName,univentionUDMPropertyLdapMapping,univentionUDMPropertyLongDescription,univentionUDMPropertyModule,univentionUDMPropertyMultivalue,univentionUDMPropertyObjectClass,univentionUDMPropertyOptions,univentionUDMPropertyShortDescription,univentionUDMPropertySyntax,univentionUDMPropertyTranslationLongDescription,univentionUDMPropertyTranslationShortDescription,univentionUDMPropertyTranslationTabName,univentionUDMPropertyValueMayChange,univentionUDMPropertyValueRequired,univentionUDMPropertyVersion,zoneName \ ldap/index/pres=aRecord,automountInformation,cn,description,dhcpHWAddress,displayName,gidNumber,givenName,homeDirectory,krb5PrincipalName,macAddress,mail,mailAlternativeAddress,mailPrimaryAddress,memberUid,name,objectClass,ou,relativeDomainName,sn,uid,uidNumber,uniqueMember,univentionMailHomeServer,univentionPolicyReference,univentionUDMPropertyCLIName,univentionUDMPropertyDefault,univentionUDMPropertyDeleteObjectClass,univentionUDMPropertyDoNotSearch,univentionUDMPropertyHook,univentionUDMPropertyLayoutOverwritePosition,univentionUDMPropertyLayoutOverwriteTab,univentionUDMPropertyLayoutPosition,univentionUDMPropertyLayoutTabAdvanced,univentionUDMPropertyLayoutTabName,univentionUDMPropertyLdapMapping,univentionUDMPropertyLongDescription,univentionUDMPropertyModule,univentionUDMPropertyMultivalue,univentionUDMPropertyObjectClass,univentionUDMPropertyOptions,univentionUDMPropertyShortDescription,univentionUDMPropertySyntax,univentionUDMPropertyTranslationLongDescription,univentionUDMPropertyTranslationShortDescription,univentionUDMPropertyTranslationTabName,univentionUDMPropertyValueMayChange,univentionUDMPropertyValueRequired,univentionUDMPropertyVersion,zoneName \ ldap/index/sub=automountInformation,cn,default,description,displayName,givenName,mail,mailAlternativeAddress,mailPrimaryAddress,sambaSID,sn,uid,zoneName slapindex /etc/init.d/slapd start PS: Wie jeder gute Datenbanker weiß kostet jeder zusätzliche Index Performance, der bei jeder Änderung mit gepflegt werden muß. Von daher wäre es ggf. sinnvol die Liste der Indices zu schrumpfen und Attribute zu entfernen, nach denen sowieso nur sehr selten gesucht wird.
Du hast den Bug als Clone von dem OpenLDAP 3.1 Bug erstellt. Weiß du, ob das mit UCS 3.0 anders war?
(In reply to comment #1) > Du hast den Bug als Clone von dem OpenLDAP 3.1 Bug erstellt. Weiß du, ob das > mit UCS 3.0 anders war? Weiß ich leider nicht mehr.
Um das nochmal zu präzisieren: Hauptproblem ist, dass slapd langsam ist, wenn man (viele) Einträge löscht. Als eine Ursache wurden die große Anzahl von Indizes ausgemacht, von daher sollte man prüfen, ob es wirklich notwendig ist, für jedes Attribut, nach dem einmal im Jahrzehnt gesucht wird, direkt einen Index anzulegen. Indizes kosten Performance beim Modifizieren, von daher ist hier der Kosten-Nutzen-Faktor zwischen Anlegen/Ändern/Löschen gegenüber Abfragen zu beachten. Wenn es eine andere Stellschraube gibt um die Performance zu verbessern, ist das natürlich auch okay.
(In reply to comment #3) > Um das nochmal zu präzisieren: > Hauptproblem ist, dass slapd langsam ist, wenn man (viele) Einträge löscht. > > Als eine Ursache wurden die große Anzahl von Indizes ausgemacht, von daher > sollte man prüfen, ob es wirklich notwendig ist, für jedes Attribut, nach dem > einmal im Jahrzehnt gesucht wird, direkt einen Index anzulegen. Indizes kosten > Performance beim Modifizieren, von daher ist hier der Kosten-Nutzen-Faktor > zwischen Anlegen/Ändern/Löschen gegenüber Abfragen zu beachten. > > Wenn es eine andere Stellschraube gibt um die Performance zu verbessern, ist > das natürlich auch okay. Der Hauptfokus ist und bleibt das Lesen. Es müssen nicht alle Attribute im Index stehen, aber nach vielen wird viel gesucht, deshalb sollte die drin stehen. Sollten Attribute nicht im Index stehen müssen, dann bitte zu den Attributen Bugs erstellen.