slapd langsam, um Ergebnisse zurückzugeben, wenn Filter nur aus einem Buchstaben + Platzhalter besteht

Question

Meine OpenLDAP-Instanz ist langsam, Datensätze zurückzugeben, wenn ein Filter eines Buchstabens und eines Platzhalters (*) für ein Feld mit einem Teilzeichenindex verwendet werden. Wenn der Filter mehr als einen Buchstaben hat, ist die Suche sehr schnell. Meine Frage ist warum?

Das Szenario ist OpenLDAP v.2.4.44, LMDB Back-End, OS X, 1,3 Millionen Datensätze, Index gesetzt, wie:

olcDbIndex: objectClass eq 
olcDbIndex: cn eq,sub 

Wenn die Suchfilter ist ‚(cn = s *) ', dauert die Abfrage eine lange Zeit, während, wenn der Filter ' (cn = sm *) ' ist es blitzschnell ist. Running Slapindex macht keinen Unterschied.

Hier sind einige Zahlen, Zeit mit:

$time ldapsearch -H ldap:/// -D cn=Manager,dc=xyz,dc=com -w secret -b dc=xyz,dc=com -s sub -z 5 '(cn=s*)' cn sn 

-- some ldap records -- 

real 0m0.474s 
user 0m0.001s 
sys  0m0.002s 

Wechsel zu '(cn = sm *)' ergibt:

real 0m0.012s 
user 0m0.001s 
sys  0m0.003s 

Um ‚(cn = smi *):

real 0m0.012s 
user 0m0.001s 
sys  0m0.003s 

Tatsächlich bleiben diese Zeiten konstant, wenn der Filter mehr als einen Buchstaben und den Platzhalter hat.

Untersuchung weiter, fand ich, dass das Heruntergehen des Alphabets führt zu immer längeren Zeiten, aber nur für diese Suche mit einem Buchstaben.

Möchten '(cn = a *)' gibt:

real 0m0.012s 
user 0m0.001s 
sys  0m0.003s 

'(cn = b *)':

real 0m0.046s 
user 0m0.001s 
sys  0m0.004s 

An dieser Stelle können Sie sehen, Benutzer und System sind immer schnell, also werde ich sie von jetzt an weglassen und nur echte Zeiten anzeigen. Also:

'(cn=a*)' --> 0m0.012s 
'(cn=b*)' --> 0m0.046s 
'(cn=c*)' --> 0m0.105s 
'(cn=d*)' --> 0m0.149s 
'(cn=e*)' --> 0m0.174s 
... 
'(cn=m*)' --> 0m0.342s 
... 
'(cn=s*)' --> 0m0.523s 
... 
'(cn=z*)' --> 0m0.606s 

Aber wenn jeder dieser Suche einen zusätzlichen Buchstaben gegeben sind, ist es wieder zu schnell (0.012s ist die avg). Aus irgendeinem Grund braucht slapd eine lange Zeit, um diesen ersten Buchstaben zu finden, aber nur wenn ein Buchstabe verwendet wird.

Bei noch genauerer Untersuchung ergibt die Filterung des Attributs 'sn' (z. B. 'sn = s *'), das NICHT indiziert ist, die gleiche Zeit wie das indexierte Attribut 'cn', wenn ein Buchstabe + Wildcard-Filter verwendet wird . Daher scheint slapd den Teilstringindex für das Attribut "cn" zu ignorieren, wenn nach einem Buchstaben + Platzhalter gefiltert wird. Durch Hinzufügen eines zweiten Buchstabens wird jedoch der Filter 'cn' schnell, während der Filter 'sn' langsam bleibt, was zu erwarten ist.

Warum passiert das und wie kann es behoben werden?

Answer 1

Haben Sie herausgefunden, dass dieses Verhalten beabsichtigt ist. OpenLDAP verfügt über eine globale Einstellung, die die Mindestlänge für einen Teilzeichenfolgenindex steuert. Die standardmäßige Mindestanzahl an Zeichen, die in einem Teilzeichenfolgenindex indexiert werden, ist 2.

Wenn Sie Online-Konfiguration (OLC) verwenden, finden Sie die Beschreibung der Einstellung in Mann slapd-config finden:

olcIndexSubstrIfMinlen: <integer>
      das Minimum angeben Länge für Subindex- und Subfinal-Indizes. Ein Attributwert muss mindestens so viele Zeichen enthalten, dass er von den Indexierungsfunktionen verarbeitet werden kann. Der Standardwert ist 2.

Oder, wenn Sie die traditionelle Konfigurationsmethode verwenden, werden Sie seine Beschreibung in Mann slapd.conf finden:

index_substr_if_minlen: <integer>
      Geben Sie die Mindestlänge für Sub- und Subfinal-Indizes an. Ein Attributwert muss mindestens so viele Zeichen enthalten, dass er von den Indexierungsfunktionen verarbeitet werden kann. Der Standardwert ist 2.

Der Mann Seiten zusätzlich sagen:

Optionen in diesem Abschnitt für alle Backends gelten beschrieben, sofern dies nicht ausdrücklich in einem Backend-Definition überschrieben.

Weiß jemand, ob dieses Verhalten auf Attributebene überschrieben werden kann? Es wäre großartig, wenn die Min- und Max-Längen der Teilstrings auf einer detaillierteren Ebene als global oder pro Backend spezifiziert werden könnten.