[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: substring index oddity

"John Madden" <jmadden@ivytech.edu> writes:

> This is something of a repeat of a previous post:
> http://www.openldap.org/lists/openldap-software/200101/msg00542.html
> I think I'm seeing the same sort of behavior.  Basically, I've got a directory
> with 1 million objects on a machine with 4GB RAM, a cachesize of 100000, and a bdb
> cache of 2GB.  Searches on an indexed attribute (uid, let's say) returns odd
> problems off of substring searches with "index uid sub,eq,pres:"
> uid=*222* : 29 seconds
> uid=*222 : 0.063 seconds
> uid=*2*22 : 0.14 seconds
> All searches return roughly the same number of entries, give or take a couple
> thousand.  All of the "good" searches take less than a second, all of the "bad"
> ones take about 29 seconds every time, leading me to believe the index is simply
> not being used and that's just how long it takes to traverse the entire directory.
> One thing that does seem suspect is that db_stat is reporting a very low cache hit
> on the bdb for the uid index, but everything appears to be in-memory and there's
> absolutely zero I/O while these searches run.  (Memory was seeded before testing
> with an objectclass=* search, which bumps slapd's RSS up to 1.8GB.

There are actually two issues which may affect your search results
1. the well known PCI hole with amd64 and 4GB

2. the default settings for subinitial and subfinal, so changing this
   default settings may increase your search speed, see slapd.conf(5)

But I would vote for default settings of subinitial and subfinal.


Dieter Klünter | Systemberatung