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.

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.

...

...

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 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

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