Speicherverbrauch von slapd in UCS 2.0

UCS - Univention Corporate Server
#1

Hallo,

nach einem Tag Nutzung steigt der Speicherverbrauch des OpenLDAP Servers auf 60% des vefügbaren Hauptspeichers (1GB ist installiert):

[code]top - 13:12:32 up 4 days, 19:35, 3 users, load average: 0.00, 0.01, 0.03
Tasks: 118 total, 1 running, 117 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1035624k total, 996772k used, 38852k free, 31940k buffers
Swap: 2097136k total, 144k used, 2096992k free, 114612k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13352 root 23 0 767m 611m 11m S 0 60.5 11:59.95 slapd
[/code]

Ich habe die Einstellungen des LDAP Servers bereits etwas verändert:

ldap/cachesize: 1000000 ldap/database/bdb/set_cachesize: 0 45000000 1
Das LDAP Verzeichnis enthält ca. 2000 Userkonten und ca 50 Maschinenkonten.
Einzige Besonderheit: Ein Squid Cache nutzt die LDAP Datenbank zur Authorisierung von Internetzugriffen; cached aber jedes Anfrageergebnis für 5 Minuten.

Die Speichernutzung scheint mir unverhältnismäßig hoch. Was kann man tun um das einzudämmen?

Gruß

#2

kleines update:

der Speicherverbrauch steigt innerhalb eines Tages nach Neustart des slapd Prozesses von 0.8% auf 60% ohne das das System aktiv von Usern benutzt wird. LDAP Zugriffe werden nur vom Mailserver (sehr geringes Volumen) und durch die üblichen LDAP Lookups der 5 beteiligten, idlenden Memberserver erzeugt.
NSCD läuft auf allen Maschinen.

#3

Hallo,

[quote=“marcjadu”]nach einem Tag Nutzung steigt der Speicherverbrauch des OpenLDAP Servers auf 60% des vefügbaren Hauptspeichers (1GB ist installiert):

Ich habe die Einstellungen des LDAP Servers bereits etwas verändert:

ldap/cachesize: 1000000 ldap/database/bdb/set_cachesize: 0 45000000 1[/quote]

Nachdem die zweite Configuration Registry-Variable gesetzt wurde muss db4.2_recover aufgerufen werden. Wurde das durchgeführt? Nur dann wird diese Änderung wirksam.

Generell ist der Speicherbedarf des slapd-Prozess recht hoch, da viele Daten zwischengespeichert werden, was die Reaktionszeiten des Prozesses beschleunigt. Bei der Anzahl von Benutzern halte ich den Verbrauch für durchaus normal.

Wenn Sie die Einstellungen des BDB-Caches verändern, können Sie mit dem Tool db4.2_stat (aufgerufen im Verzeichnis /var/lib/univention-ldap/ldap/) prüfen was für die Datenbank gerade reserviert ist.

Mit freundlichen Grüßen
Andreas Büsching

#4

Ja, db_recover wurde ausgeführt.
Ich kann ihre Ansicht über den Speicherverbrauch von OpenLDAP aus Erfahrung nicht bestätigen. Andere OpenLDAP installationen mit ähnlichen Datenbanken und Konfigurationen verbrauchen unter 100MB Hauptspeicher. Darüberhinaus ist bei 600 MB hier ja nicht schluss sondern nur der Punkt wo ich den Server neu starten muss, da der Rest des Systems ja auch Speicher benötigt.
Ich bin mir noch nicht sicher ob das zusammenhängt, aber bei der weiteren Diagnose bin ich auf folgendes gestoßen: Jedes mal, wenn eine Email an cyrmaster ausgeliefert wird, macht dieser einen LDAP Lookup und sucht nach den posixGroups. Danach macht er dann je eine LDAP Suchanfrage für jeden einzelnen User im System und sucht nach “uid uniqueMember objectClass”. Ich weis nicht genau wozu das gut sein soll, aber es hängt mit der config-registry option mail/cyrus/imap/lookup_groups zusammen. Dies erzeugt je ausgelieferter Mail ca 1300 LDAP requests.
Nachdem ich keine Shared-Folder in IMAP verwende, habe ich diese Option nun deaktiviert. Die LDAP requests sind nun weg. Ich hoffe dass das auch den Speicherbedarf etwas im Zaum hält.

Edit: ich muss mich korrigieren, die LDAP requests sind leider nicht weg. Aber sie sehen jetzt anders aus:

Feb  6 10:12:30 host slapd[24135]: conn=10 op=2179 SRCH base="dc=domain,dc=de" scope=2 deref=0 filter=
"(&(objectClass=posixAccount)(uid=username))"
Feb  6 10:12:30 host slapd[24135]: conn=10 op=2179 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirecto
ry loginShell gecos description objectClass

Vorher sah es so aus:

Feb 6 06:00:07 host slapd[18326]: conn=7290 op=1054 SRCH base="uid=username,cn=container,cn=users,dc=domain,dc=de" scope=0 deref=0 filter="(objectClass=*)" Feb 6 06:00:07 manager slapd[18326]: conn=7290 op=1054 SRCH attr=uid uniqueMember objectClass [/code]

#5

Hallo,

Der Speicherbedarf des slapd hängt weniger mit der Anzahl der ankommen Anfragen zusammen, sondern wird primär durch die Zwischenspeicher und die Menge der Daten beeinflusst.

Wenn Sie den Speicherbedarf weiter reduzieren wollen, dann können Sie folgende Dinge prüfen bzw. anpassen.

Die tatsächlich von dem BDB-Backend genutzte Zwischenspeichergröße kann mit dem folgenden Kommando geprüft werden:/var/lib/univention-ldap/ldap# db4.2_stat -m|head -n1
Sollte diese Größe für die Menge an Speicher, die Sie verwenden möchten, zu hoch sein, dann sollten Sie den Wert der Configuration Registry-Variable ldap/database/bdb/set_cachesize weiter reduzieren (und anschließend db4.2_recover aufrufen), bis der Wert ihren WÜnschen entspricht.

Zusätzlich können Sie die Configuration Registry-Variable ldap/cachesize ebenfalls weiter heruntersetzen (der Standardwert von slapd ist 1000).

Wenn Sie die Zwischenspeicher sehr weit reduzieren ist es durchaus möglich, dass die Performance des slapd stark beeinträchtigt wird.

Mit freundlichen Grüßen
Andreas Büsching

Mastodon