[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