[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: server startup overhead
Eric Irrgang wrote:
I continue to have trouble with getting a freshly started server to be
responsive. One problem in particular is one that I thought had been
resolved some time ago but is apparently biting me right now...
With the hdb backend (at least in OL 2.3.34 and OL 2.3.35) if you perform
a search with a search base deeper than the root suffix, the search takes
a very long time to complete if the cache hasn't been established. In my
case the difference is less than a second versus several hours. I'm not
sure yet which bit of cache needs to be primed. I can switch back and
forth searching with the same filter in the root and then a child search
base with the same results.
If it takes several hours, then most likely your BDB cache is too small.
As for which cache, it's either the DN cache (aka EntryInfo in the code)
or the IDL cache. (Currently the DN cache size is not configurable, will
probably add a keyword for that in 2.4.)
Is this a bug recursion or something that I just hadn't been noticing?
What would be the best search to perform to prepare whatever cache is
getting hit to make searches outside of the root DN faster?
Priming the caches will only help if you actually have sufficient RAM
available. If the DB is too large, then there's not much you can do
about it. If you have sufficient RAM, then doing a subtree search from
the root, on an unindexed attribute, looking for a value that doesn't
exist, will hit every entry in the DB and fully prime the DN cache (and
the DN-related info in the IDL cache). It will cycle the full contents
of the dn2id and id2entry DBs through the BDB cache as well.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/