Željko Nejašmić wrote:
On Fri, Oct 4, 2013 at 10:26 AM, hyc@symas.com wrote:
Thanks. So far the output shows nothing out of the ordinary. Can you also provide the output for: ls -l /opt/openldap/var/openldap-data
root@spr101:~ $ ls -ahl /opt/openldap/var/openldap-data total 100K drwxr-xr-x. 2 openldap openldap 4.0K Oct 4 07:54 . drwxr-xr-x. 4 openldap openldap 4.0K May 28 08:49 .. -rw-------. 1 openldap openldap 88K Oct 4 07:44 data.mdb -rw-------. 1 openldap openldap 8.0K Oct 4 07:54 lock.mdb
Something is flaky with your installation. As I wrote in my previous email, LMDB always sets the file size to match your mapsize, to avoid this SIGBUS issue. Your mapsize is 38654705664 (36GB) but the data.mdb filesize is only 88K, it should be 36GB. You must have some other process running that is truncating the file; there is nothing in OpenLDAP's code that would cause this behavior.
root@spr101:~ $ ps -efa | grep slapd openldap 44012 1 0 07:54 ? 00:00:01 /opt/openldap/libexec/slapd -h ldap:/// ldapi:/// -F /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap
root@spr101:~ $ mount | grep sdb1 /dev/sdb1 on /opt type ext4 (rw,noatime,nobarrier,data=ordered) Do note that we did load testing on ext2 and ext4, with both being tweaked and not, and as far as I recall, every combination of parameters causes the problem; I will try to reproduce it on ext{2,3,4} with default mounting parameters. Almost forgot, we did tests using tmpfs also, with the same outcome. The whole /opt was used as a mount point for the tmpfs.
root@spr101:~ $ fdisk -lu /dev/sdb1 Disk /dev/sdb1: 400.0 GB, 400027127808 bytes 224 heads, 56 sectors/track, 62284 cylinders, total 781302984 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
gparted doesn't seem to be complaining about SSD block alignment: root@spr101:~ $ parted /dev/sdb1 align-check opt 1
Another thing I'll be trying is making a partition with different alignment parameters to see if any change occurs; tried using a different scheme, but that hasn't produced a a change in behavior.
Note from the mmap(2) manpage:
Use of a mapped region can result in these signals: SIGSEGV Attempted write into a region mapped as read-only. SIGBUS Attempted access to a portion of the buffer that does not
correspond to the file (for example, beyond the end of the file, including the case where another process has truncated the file).
LMDB always sets the size of the file when using the WRITEMAP option, so the SIGBUS condition should never happen. The pointers in your gdb output are all within the bounds of the map and mapsize you configured.
What filesystem type is the data directory stored on? This is looking more like a kernel or filesystem bug than anything else.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/