I did some profiling on the 2.4.32 build and the output of callgrind is
attached as graph.
below four functions are coming as bottleneck while searching
Can anyone help why below functions are taking too much CPU. Why
mdb_entry_decode mdb_cursor_set and mdb_i2dl_search are taking all most all
On Tue, Aug 28, 2012 at 10:35 PM, Yajuvendra Singh <
Thanks for replying, I have few more observation regrading my load runs,
real time of load run with MDB is 98% even at 10 TPS.
What version of OpenLDAP are you using?
What type of disk?
--root@tspatca2103> fdisk -l /dev/mapper/vg00-root
Disk /dev/mapper/vg00-root: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/vg00-root doesn't contain a valid partition table
What type of file system?
--ext4 (/dev/mapper/vg00-root on / type ext4 (rw,nouser_xattr))
What is your *exact* slapadd command?
--/opt/openldap/yaju/sbin/slapadd -q -w -f
/opt/openldap/yaju/etc/openldap/slapd.conf -l /root/yaju/db.ldif
I am using jmeter to simulate the load.
Thanks and Regards
On Tue, Aug 28, 2012 at 8:19 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote:
> --On Tuesday, August 28, 2012 5:29 PM +0530 Yajuvendra Singh <
> yajuvendra.singh(a)gmail.com> wrote:
> 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.
> You don't provide any useful or relevant information, so it is impossible
> to help you.
> What version of OpenLDAP are you using?
> What type of disk?
> What type of file system?
> What is your *exact* slapadd command?
> There is virtually no tuning involved with MDB, although I strongly
> recommend you read Howard's notes about the writeback bits for EXT4 etc he
> made in a recent post to -technical about MDB.
> Quanah Gibson-Mount
> Sr. Member of Technical Staff
> Zimbra, Inc
> A Division of VMware, Inc.
> Zimbra :: the leader in open source messaging and collaboration