Dear Experts,
Today we tried with to run the load with the below schema. We added about .6M entries in the DB. Still our performance is severely poor. (10 TPS)
Can anybody review our slapd.conf file and point us where we are wrong, is there any other config we have missed out.
System we have is 64 bit 12 core machine RHEL having total memory of 49418952 kB.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ dn: dc=example,dc=com objectClass: dcObject objectClass: organization o: Example Company dc: example
dn: cn=Manager0,dc=example,dc=com objectClass: organizationalRole cn: Manager0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Thanks and Regards
Yajuvendra
Insanity: D*oing* the same *thing* over and over *again and expecting* different results. Albert Einstein
On Sat, Aug 25, 2012 at 2:37 PM, aryan rawat aryanrawat24@gmail.com wrote:
Hi ,
Chirs and Howard,
Please share the slapd.conf for MDB for which you have done the performance testing..
BR's, Haroon
On Fri, Aug 24, 2012 at 11:46 PM, Howard Chu hyc@symas.com wrote:
Chris Card wrote:
> I am using openldap 2.4.32 on centos 6, on a 24 core box with 132
Gb RAM.
> My test directory has ~ 3 million entries, and I loaded it into mdb
using
slapadd which took over 2 days (by comparison, the same load into
bdb takes
2-3 hours).
This is not normal. With slapadd -q MDB is faster than BDB assuming
you're
using a decent filesystem and sensible mount options. JFS, EXT2, do
better
than other filesystems in my tests. Very recent EXT4 may be better
than EXT3
as well.
The filesystem is xfs, mounted as a drbd device (although at the
moment the other
half of the drbd pair is not configured, so it doesn't have to wait
for synchronous
writes across the network)
Sounds like you're not using slapadd -q. Either that, or your
filesystem cache
Oh ****! You're quite right, I managed to lose the -q from the slapadd
command when copy/pasting
from a script. I'll try running it again with -q.
Do you have an ETA for improvements to mdb write performance?
Not at this point. There are several approaches to test; most of them will probably be dead ends.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/