[Date Prev][Date Next]
Re: ldapsearch slow with +110000 entries
Are the configurations bellow:
index uid,uidNumber eq
index uid eq
index uidNumber eq
the same thing?
Yes. By the way, once you do eq, you might as well do pres too, as it
adds only a tiny additional memory requirement.
Why are you only using a 10 MB dbcache when you have 1 GB of memory?
Ok, I'm using now 50MB dbcachesize
I assume you actually proceeded by benchmarking with varying cachesize
and dbcachesize, then choosing values at which you saw no more return on
your resource comitments. If not, this would be a useful exercise.
For these tests I'm using ide disks. The production configuration are
scsi u2w/lvd disks. IMHO, I SHOULD have acceptable timings in the test
plataform for at least ONE search, since in the production I'm going to
have many concurrent searchs!
You should definitely tune your ide disks using hdparm. Disk throughput
is likely killing you on that first search. See, for example
on how to do this. This is good for your system in general, independent
index default eq,pres
I think you don't want to do this. Indexing on what you search on is a
very good idea. Indexing on what you don't search on will actually slow
you down some.
With these settings cachesize is twice the number of entries and
dbcachesize become larger than the largest file in /var/lib/ldap.
The (approximate) criterion for being able to hold everything in memory
is that dbcachesize be as large as the sum of all files in /var/lib/ldap.
The first search is slow (about 1min10s) but the others take 3,5s to 4s.
I suspect that by doing the stuff I mentioned above, you will be able to
improve on these numbers further. Do watch the size of your slapd
process to make sure you don't run out of memory. And do watch your CPU
consumption during searches, to make sure you are not CPU limited.
Good luck! And feel free to recommend me to your friends. :-)