Hello list,
Solaris 10u8
db-4.8.30.NC
openldap-2.4.23
So in the last week, simple queries have been really slow. For example:
# time /usr/local/bin/ldapsearch -h 0 -D cn=admin,dc=company,dc=com -x -w pass
-b ou=mail,dc=company,dc=com mail=testloo...@domain.com
1m21s
Of course mail in
Quoting Howard Chu h...@symas.com:
The chain overlay needs to be configured on the frontendDB in order
to catch these update referrals.
Excellent. Thanks to your advice together with Pierangelo's patch of
29 April 2010 (which I hope will soon be committed), my test
configuration is now
No real reason, tried various different settings but to no real advantage.
Now I have:
Filesystem size used avail capacity Mounted on
swap19G 7.7G11G42%/tmp
# grep cache DB_CONFIG
set_cachesize 8 0 1
# time
truss is pretty much useless in this context. Most of BDB's activity is
thru memory-mapping, which involves no system calls for truss to trace.
You need an actual profile (e.g. using oprofile) to identify where the
time is going.
This is very true. But reach for the tools you have, even if it
Jorgen Lundman wrote:
Now repeat the db_stat call and see how long it takes the 2nd time.
It does indeed speed up, if I do not wait too long between tests.
real1m27.712s
real0m29.696s
real0m4.332s
real0m4.452s
If it slows down after you wait a while, that means some other
Howard Chu wrote:
If it slows down after you wait a while, that means some other process
on the machine is using the system RAM and forcing the BDB data out of
the system cache. Find out what other program is hogging the memory,
it's obvious that BDB is not doing anything wrong on its own.
