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

Re: problems under IRIX 6.2, 6.5



Kurt,

On Tue, 12 Jan 1999, Don Badrak wrote:

> Kurt,
> 
> On Tue, 12 Jan 1999, Kurt D. Zeilenga wrote:
> 
> > Don wrote:
> > > Kurt wrote:
> > > > I'm thinking the problem must be related to our entry reader/writer lock
> > > > code we introduced in 1.1.  I will raise this and some related issues
> > > > with -core and on -devel and see if we can sort this out.
> > 
> > I wonder: is it allocation/deallocation of the reader/writer locks or just the
> > lock/unlock?
> > 
> > BTW, can you increase the cache/dbcachesizes to large numbers (larger than
> > the number of entries in the directory) and then run the search twice?  I
> > wonder what the 'time' difference is?
> 
> Sure.  I originally had the cache to 10240 (I have 8878 DNs in the
> directory).  I'll give it a go and see what happens.

Alright, I bumped the cachesize to 10240 (8878 entries) and the
dbcachesize
to 10485760 (10M, larger than the largest *.dbb file).  I did the search
four times in a row, and got 13.36, 13.13, 12.67, and 13.17 seconds
(search is ldapsearch -h localhost -p 2389 department=geo\* mail
>/dev/null).

I dropped it back down (cachesize == 1024, dbcachesize == 1M), and got
13.17, 12.96, 12.97.  Seems not to be making much of a difference.

Compare this to the older Umich one (cachesize == 1024, dbcachesize ==
1M), same query, getting 1.02, 0.95, 0.84, 0.91.

Don
-- 
Don Badrak <dbadrak@census.gov>              301.457.1793 work
Telecommunications Office		     301.457.4438 fax
U.S. Bureau of the Census                    301.457.1828 fax
Suitland MD, USA