Hi Team, GM We are working on moving from openldap2.4.44 to symasldap2.6.7. We have total of 13million docs.
centos7 to centos7 is taking 1~2hours where as rocky8 is taking 48hours and more.
Settings of centos7 and rocky8 are identical. We are moving to rocky8 as centos7 is EOL.
Can you please let us know how we can fix the data transfer issue. Regards, Anil P
Why not skip 8 and go straight to 9?
Are you sure it is not difference in db engine in openldap? When I import my records I also need to change the config with an ldif to get better performance during slapadd
We are working on moving from openldap2.4.44 to symasldap2.6.7. We have total of 13million docs.
centos7 to centos7 is taking 1~2hours where as rocky8 is taking 48hours and more.
Settings of centos7 and rocky8 are identical. We are moving to rocky8 as centos7 is EOL.
Hi Marc,
We moved other components also to rocky8. So we have a limitation there. Yes we are using mdb database.
Regards, Anil P
We moved other components also to rocky8. So we have a limitation there. Yes we are using mdb database.
I am just giving you my ldif, probably this is your write performance hit
1 dn: olcDatabase={2}mdb,cn=config 2 changetype: modify 3 replace: olcDbNoSync 4 olcDbNoSync: TRUE 5
I am correcting this again in my Dockerfile after import
sed -i 's/TRUE/FALSE/g' $SLAPD_CFG_DIR/change-db-mdbperf-temp.ldif
You have to experiment a bit. Did not check to much what I did.
I don't even get what is happening here. It looks like every few bytes are synced.
Hi!
Instead of talking about wall time elapsed, di you inspect what's going on using tools like sa/sar, top, iftop, iotop, etc.?
Regards, Ulrich
-----Original Message----- From: anilkumar.pathuri7@gmail.com anilkumar.pathuri7@gmail.com Sent: Tuesday, October 1, 2024 3:57 PM To: openldap-technical@openldap.org Subject: [EXT] RE: symas2.6.7 is data transfer is faster in centos7 but very very slow in rocky8
Hi Marc,
We moved other components also to rocky8. So we have a limitation there. Yes we are using mdb database.
Regards, Anil P
--On Friday, October 11, 2024 1:09 PM +0000 "Windl, Ulrich" u.windl@ukr.de wrote:
Hi!
Instead of talking about wall time elapsed, di you inspect what's going on using tools like sa/sar, top, iftop, iotop, etc.?
I will re-iterate:
a) Using a journald filesystem is known to cause a substantial performance hit, it's in the admin guide as I previously noted. b) Using syncrepl to populate a (large) database from scratch is not the correct method. The correct method is to use slapcat/slapadd -q.
--Quanah
--On Tuesday, October 1, 2024 2:34 PM +0000 anilkumar.pathuri7@gmail.com wrote:
Hi Team, GM We are working on moving from openldap2.4.44 to symasldap2.6.7. We have total of 13million docs.
centos7 to centos7 is taking 1~2hours where as rocky8 is taking 48hours and more.
Settings of centos7 and rocky8 are identical. We are moving to rocky8 as centos7 is EOL.
Can you please let us know how we can fix the data transfer issue. Regards,
Use the correct tools:
slapcat slapadd
Outside of that, there's too little information here to go on. For example, same filesystem and same options for the filesystem? If it's cloud now, and was onprem before, what are the IOP restrictions, etc.
--Quanah
slapcat slapadd
Outside of that, there's too little information here to go on. For example, same filesystem and same options for the filesystem? If it's cloud now, and was onprem before, what are the IOP restrictions, etc.
I am using slapadd. If I install from binaries on alpine (3.19) I have this slow writes issue also. How are you testing? I hope not on ssd/nvme.
--On Wednesday, October 2, 2024 9:15 AM +0000 Marc Marc@f1-outsourcing.eu wrote:
slapcat slapadd
Outside of that, there's too little information here to go on. For example, same filesystem and same options for the filesystem? If it's cloud now, and was onprem before, what are the IOP restrictions, etc.
I am using slapadd. If I install from binaries on alpine (3.19) I have this slow writes issue also. How are you testing? I hope not on ssd/nvme.
No context to your issue, my response was for Anil.
You'd at a minimum have to specify your full slapadd command.
--quanah
slapcat slapadd
Outside of that, there's too little information here to go on. For example, same filesystem and same options for the filesystem? If it's cloud
now,
and was onprem before, what are the IOP restrictions, etc.
I am using slapadd. If I install from binaries on alpine (3.19) I have this slow writes issue also. How are you testing? I hope not on
ssd/nvme.
No context to your issue, my response was for Anil.
You'd at a minimum have to specify your full slapadd command.
I am doing this
126 && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-db-mdbperf-temp.ldif \ 127 && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-logging.ldif \ 128 129 && ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f $SLAPD_CFG_DIR/change-acl.ldif \ 130 && kill -HUP $(cat /var/lib/openldap/run/slapd.pid) \ 131 && sync \ 132 && rm -f $SLAPD_CFG_DIR/change-frontend.ldif \ 133 && rm -f $SLAPD_CFG_DIR/change-db.ldif \ 134 && rm -f $SLAPD_CFG_DIR/change-config.ldif 135 136 RUN [ -f "/tmp/ldap.db.gz" ] \ 137 && runuser -l ldap -s '/bin/bash' -c "rm -f $SLAPD_DATA_DIR/openldap-data/*.mdb ; gunzip -c /tmp/ldap.db.gz | /usr/sbin/slapadd -c 2> /tmp/import-errors" \ 138 && sync \ 139 && rm -f /tmp/ldap.db.gz || echo "not importing ldap.db.gz"
--On Thursday, October 3, 2024 7:55 AM +0000 Marc Marc@f1-outsourcing.eu wrote:
/usr/sbin/slapadd -c
a) If you're restoring from a backup, you should not be using -c b) If you're restoring from a backup, you should be using -q
--Quanah
--On Thursday, October 3, 2024 9:31 AM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, October 3, 2024 7:55 AM +0000 Marc Marc@f1-outsourcing.eu wrote:
/usr/sbin/slapadd -c
a) If you're restoring from a backup, you should not be using -c b) If you're restoring from a backup, you should be using -q
In fact, it is almost never the case you should use -c, because if you are hitting errors then that indicates serious issues with your environment. If you don't use -q, it is expected for your slapadds to take an exorbitant amount of time.
--Quanah
Hi Team,
Initially I thought this is server issue. But I did a test within centos itself.
Data transfer of 13M for openldap 2.4.44 is taking less than 30mins where as data transfer from openldap2.4.44 to symas2.5.13 with same centos instance is taking 2 days. Data transfer is very slow.
Regards, Anil P
Dear Symas Team,
We are currently working with Symas OpenLDAP version 2.5.13 and have identified an issue where journaling is affecting performance during large data transfers. Disabling journaling temporarily significantly improved the data transfer speed by avoiding frequent 4KB writes. Specifically, we used the following setting:
dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcDbNoSync olcDbNoSync: TRUE
This enabled faster writes during the initial data transfer. However, we understand that disabling journaling can risk potential data loss, so we plan to re-enable it after the transfer is complete.
Our question is whether there are any options to fine-tune journaling behavior, such as setting a maximum journal size, as we are aware of a parameter like olcDbJournalSize (which is not currently available in Symas).
Specifically, we would like to know:
Is there an equivalent parameter to control journal size or journal behavior in Symas OpenLDAP? Can we adjust journaling settings dynamically during bulk data transfers and then safely revert them afterward (without risking data integrity)? Are there any other journaling-related optimizations (e.g., olcDbWriteMode, olcDbSyncPeriod, or similar) available to improve write performance during bulk operations?
We look forward to your guidance on this matter.
Regards, Anil P
--On Thursday, October 3, 2024 2:39 PM +0000 anilkumar.pathuri7@gmail.com wrote:
Dear Symas Team,
If you want support from Symas, I suggest you contact them and sign up for a support contract at https://www.symas.com
This is the OpenLDAP discussion list, of the OpenLDAP project. It is not owned by Symas.
Additionally, as I already stated, the *CORRECT* way to bring up your new systems is to use slapcat & slapadd.
Finally, the issue with filesystems and journaling is well known. As discussed in the Admin guide in the tuning section, ext2 is recommended for back-mdb databases.
https://www.openldap.org/doc/admin25/tuning.html#Disks
--Quanah
openldap-technical@openldap.org