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. This is all on Debian 3.1's (amd64) libdb4.2 and slapd packages. Any ideas here? Thanks, John -- John Madden UNIX Systems Engineer Ivy Tech Community College of Indiana [EMAIL PROTECTED]
