[Date Prev][Date Next]
(ITS#6646) back-hdb dncache disregarded in some searches
Full_Name: Ondrej Kuznik
Submission from: (NULL) (126.96.36.199)
is a database that has most of its 1M entries as uid=%d,o=one,o=test.
perform an unindexed search:
ldapsearch -b o=test uid=1
the entry is first in the db, so is spit out immediately. Watching dn
cn=Database 2,cn=Databases,cn=Monitor shows:
This is OK, but:
perform an unindexed search with base o=one,o=test:
ldapsearch -b o=one,o=test uid=1
watching dn cn=Database 2,cn=Databases,cn=Monitor shows that all 1M dns are
loaded into the cache and only after that the entry uid=1,o=one,o=test is spit
out. Then the dncache starts decreasing as the database filters out the
perform an unindexed search with base o=one,o=test but either kill ldapsearch
while hdb is still crunching or add a sizelimit greater than the number of
entries that should be returned:
ldapsearch -z2 -b o=one,o=test "uid=1*"
olmBDBDNCache contains most of the database and never decreases.
A dn is later freed from the cache only in case it is referenced, should there
be another similar arc e.g. o=another,o=test, its dns are added inside the cache
too if we use the same technique.
This makes hdb unusable for a large database (whose set of dns alone can eat the
entire memory if loaded into dncache) unless one can guarantee that every search
is either indexed or with search base == suffix of the db.
In the example scenario, the value of cachefree affects almost nothing.