Howard,

Maybe I'm not understanding very well your explanation.

What I can see is that until the dncache is filled any search can be done very fast. After this is filled even stopping the original search and starting a new one the pace is now very slow with some queries taking around 8 seconds to end.

real 0m8.001s user 0m0.002s sys 0m0.006s

Once dncache is filled is there any configuration like cachefree that could make the searches become similar to the original pace?

Thanks,

Rodrigo.

Howard Chu wrote:

Rodrigo Costa wrote:

...

Howard,

The idea was exactly to use the dncachesize large so the search or random database access would not be affected.

The issue is that after DB is filled any search hangs time by time even there are many entrances into cache. I was expecting that to remove or re-cache an entrance some performance affectance would occur but if ldapsearch would be stopped and a new one started the search would be faster since there are millions of entrances already cached.

Except that there *aren't* million of entries already cached, you've only cached a few thousand entries. And when you have such a tiny fraction of the database cached, the cache is going to be mostly useless for random access patterns. At this point you're making me repeat myself, so I'm stopping here.

By the way, an "entrance" is a doorway. A directory object is an "entry" ... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/