[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
http://lists.suse.com/archive/suse-amd64/2005-Jul/0071.html
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
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6