Hi,
I have an openldap instance that I'd like to migrate to arm64, just loading a mdb from an amd64 instance results in all filtered queries returning empty results, which is resolved by running slapindex. I've managed to get this to complete in reasonable time using an arm64 mac and a tmpfs volume to hold a smaller test mdb in memory, but I can't replicate this performance in the cloud and I can't fit the prod mdb into tmpfs and have enough memory to work with left over.
I've noticed that despite setting olcToolThreads high, it only ever pins one CPU, so I wonder if it's the difference in single threaded performance of my m1max mac vs a graviton2 instance?
Is there any way to get slapindexing to use more than one cpu, or are there any other performance improvements you can suggest? I need it to complete within 6 hours maximum to fit into a change window. I'd prefer not to resort to running a parallel instance out of service and then swap the two over if it can be helped.
It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex.
I'd appreciate any advice you could give.
--On Thursday, July 20, 2023 8:54 AM +0000 maud.parratt@bjss.com wrote:
It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex.
I'd appreciate any advice you could give.
OpenLDAP version? Indexing configuration? File system type? File system options? What type of drives? Cloud?
--Quanah
--On Thursday, July 20, 2023 8:18 AM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, July 20, 2023 8:54 AM +0000 maud.parratt@bjss.com wrote:
It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex.
I'd appreciate any advice you could give.
OpenLDAP version? Indexing configuration? File system type? File system options? What type of drives? Cloud?
Oh, and what is your toolthreads setting in the configuration?
--Quanah
2.6.4 (alpine linux, run in a container) I’m unable to share the indexing schema, I’m under strict rules on exposing anything project specific. I’ve been using a tmpfs memory mounted file system for the slapindex
slcToolThreads I’ve experimented with a bunch of settings, from 4-48 with 16 physical cores, but no matter what I do it only ever pins one core to 100%.
From: Quanah Gibson-Mount quanah@fast-mail.org Date: Thursday, 20 July 2023 at 15:19 To: Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Thursday, July 20, 2023 8:18 AM -0700 Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Thursday, July 20, 2023 8:54 AM +0000 maud.parratt@bjss.com wrote:
It doesn't go at a consistent rate, but right now it looks like it'd take 2-3 days to complete. I'm passing -t and -q to slapindex.
I'd appreciate any advice you could give.
OpenLDAP version? Indexing configuration? File system type? File system options? What type of drives? Cloud?
Oh, and what is your toolthreads setting in the configuration?
--Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Thursday, July 20, 2023 3:28 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
2.6.4 (alpine linux, run in a container)
I'm unable to share the indexing schema, I'm under strict rules on exposing anything project specific.
I've been using a tmpfs memory mounted file system for the slapindex
slcToolThreads I've experimented with a bunch of settings, from 4-48 with 16 physical cores, but no matter what I do it only ever pins one core to 100%.
It looks like the documentation needs updating. For back-mdb, any value above 2 is set to 2, as it has no improvement in indexing performance.
A better question would be, is why are you running slapindex at all? Generally one loads their database with slapadd, which includes indexing the database. If you need to change the indexing for a specific attribute, then you slapindex *just that attribute*.
If you are doing slapadd followed by slapindex you're wasting resources, assuming your indexing hasn't changed.
It's unfortunate you cannot share your indexing since it's possible that there unnecessary indexing involved.
--Quanah
The database already exists as an mdb, I could dump and restore it with slapadd, but I expect that’d take as much time as the slapindex.
If I load the mdb from an x86 instance of openldap on an arm64 index, queries return zero results until I do a slapindex, I suspect the way indexes is encoded is inconsistent between architectures.
It certainly would’ve saved me some time experimenting with tool threads if I was aware of that limitation.
From: Quanah Gibson-Mount quanah@fast-mail.org Date: Thursday, 20 July 2023 at 15:52 To: Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Thursday, July 20, 2023 3:28 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
2.6.4 (alpine linux, run in a container)
I'm unable to share the indexing schema, I'm under strict rules on exposing anything project specific.
I've been using a tmpfs memory mounted file system for the slapindex
slcToolThreads I've experimented with a bunch of settings, from 4-48 with 16 physical cores, but no matter what I do it only ever pins one core to 100%.
It looks like the documentation needs updating. For back-mdb, any value above 2 is set to 2, as it has no improvement in indexing performance.
A better question would be, is why are you running slapindex at all? Generally one loads their database with slapadd, which includes indexing the database. If you need to change the indexing for a specific attribute, then you slapindex *just that attribute*.
If you are doing slapadd followed by slapindex you're wasting resources, assuming your indexing hasn't changed.
It's unfortunate you cannot share your indexing since it's possible that there unnecessary indexing involved.
--Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Thursday, July 20, 2023 4:14 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
The database already exists as an mdb, I could dump and restore it with slapadd, but I expect that'd take as much time as the slapindex.
If I load the mdb from an x86 instance of openldap on an arm64 index, queries return zero results until I do a slapindex, I suspect the way indexes is encoded is inconsistent between architectures.
It certainly would've saved me some time experimenting with tool threads if I was aware of that limitation.
Do you see the same load time issue on x86_64 as on arm64?
Also it's not clear to me why you're indexing the entire database with slapindex if it was already loaded via slapadd, which would have created the indices as they existed at the time the DB was loaded. You should only have to slapindex any changes made since that time.
Are you using cn=config or slapd.conf would be another question of mine. I hit a serious bug in OpenLDAP 2.6.4 in regards to cn=config and adding indexing that slapindex couldn't fix (ITS#9993, ITS#10047).
--Quanah
The last time slapadd was used on this database was many years ago, and yeah as I said, slapindex is my mitigation for queries not working after reloading the mdb with arm64. we're using cn=config. we see the same indexing performance on 2.6.2 though.
i've not tested loading an arm64 mdb with an x86 instance, i'll try that tomorrow and report back.
i may have to accept running the process through the day, then sync forwards after switching over. not ideal but not intolerable. it would be nice to know why indexes get messed up by the architecture swap though.
Sent from Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Thursday, July 20, 2023 4:54:56 PM To: Maud Parratt Maud.Parratt@bjss.com; openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Thursday, July 20, 2023 4:14 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
The database already exists as an mdb, I could dump and restore it with slapadd, but I expect that'd take as much time as the slapindex.
If I load the mdb from an x86 instance of openldap on an arm64 index, queries return zero results until I do a slapindex, I suspect the way indexes is encoded is inconsistent between architectures.
It certainly would've saved me some time experimenting with tool threads if I was aware of that limitation.
Do you see the same load time issue on x86_64 as on arm64?
Also it's not clear to me why you're indexing the entire database with slapindex if it was already loaded via slapadd, which would have created the indices as they existed at the time the DB was loaded. You should only have to slapindex any changes made since that time.
Are you using cn=config or slapd.conf would be another question of mine. I hit a serious bug in OpenLDAP 2.6.4 in regards to cn=config and adding indexing that slapindex couldn't fix (ITS#9993, ITS#10047).
--Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Thursday, July 20, 2023 5:32 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
The last time slapadd was used on this database was many years ago, and yeah as I said, slapindex is my mitigation for queries not working after reloading the mdb with arm64. we're using cn=config. we see the same indexing performance on 2.6.2 though.
i've not tested loading an arm64 mdb with an x86 instance, i'll try that tomorrow and report back.
i may have to accept running the process through the day, then sync forwards after switching over. not ideal but not intolerable. it would be nice to know why indexes get messed up by the architecture swap though.
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
--Quanah
Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 5:32 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
The last time slapadd was used on this database was many years ago, and yeah as I said, slapindex is my mitigation for queries not working after reloading the mdb with arm64. we're using cn=config. we see the same indexing performance on 2.6.2 though.
i've not tested loading an arm64 mdb with an x86 instance, i'll try that tomorrow and report back.
i may have to accept running the process through the day, then sync forwards after switching over. not ideal but not intolerable. it would be nice to know why indexes get messed up by the architecture swap though.
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
--Quanah
Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this.
I’ve configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
The indexes are still broken though, is this the configuration you’re referring to? Given my mdb is from an amd64 box, it’ll be 32 bit, so I want to match the configuration.
From: Howard Chu hyc@symas.com Date: Thursday, 20 July 2023 at 20:38 To: Quanah Gibson-Mount quanah@fast-mail.org, Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
I also tried
olcIndexIntLen: 4
But it’s still the same
From: Maud Parratt Maud.Parratt@bjss.com Date: Friday, 21 July 2023 at 12:01 To: Howard Chu hyc@symas.com, Quanah Gibson-Mount quanah@fast-mail.org, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time I’ve configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
The indexes are still broken though, is this the configuration you’re referring to? Given my mdb is from an amd64 box, it’ll be 32 bit, so I want to match the configuration.
From: Howard Chu hyc@symas.com Date: Thursday, 20 July 2023 at 20:38 To: Quanah Gibson-Mount quanah@fast-mail.org, Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Friday, July 21, 2023 12:11 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
I also tried
olcIndexIntLen: 4
You don't want to do that.
But it's still the same
From: Maud Parratt Maud.Parratt@bjss.com Date: Friday, 21 July 2023 at 12:01 To: Howard Chu hyc@symas.com, Quanah Gibson-Mount quanah@fast-mail.org, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
I've configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
With a database your size, you most definitely want 64-bit index hashes everywhere. It's scheduled to become the default start in OpenLDAP 2.7.
-Quanah
why? to be clear I’m experimenting on a smaller ephemeral test instance with non prod data, so there’s no risk to trying things.
Sent from Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, July 21, 2023 3:27:16 PM To: Maud Parratt Maud.Parratt@bjss.com; Howard Chu hyc@symas.com; openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Friday, July 21, 2023 12:11 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
I also tried
olcIndexIntLen: 4
You don't want to do that.
But it's still the same
From: Maud Parratt Maud.Parratt@bjss.com Date: Friday, 21 July 2023 at 12:01 To: Howard Chu hyc@symas.com, Quanah Gibson-Mount quanah@fast-mail.org, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
I've configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
With a database your size, you most definitely want 64-bit index hashes everywhere. It's scheduled to become the default start in OpenLDAP 2.7.
-Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Friday, July 21, 2023 3:32 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
why? to be clear I'm experimenting on a smaller ephemeral test instance with non prod data, so there's no risk to trying things.
The man page spells it out pretty clearly:
index_hash64 { on | off } Use a 64 bit hash for indexing. The default is to use 32 bit hashes. These hashes are used for equality and substring indexing. The 64 bit version may be needed to avoid index collisions when the number of indexed values exceeds ~64 million. (Note that substring indexing generates multiple index values per actual attribute value.) Indices generated with 32 bit hashes are incompatible with the 64 bit version, and vice versa. Any existing databases must be fully reloaded when changing this setting. This directive is only supported on 64 bit CPUs.
I'm assuming that you have substring indices, and given the large size of your database you may start having hash collissions.
You most likely also want to configure olcBkMdbIdlExp, sortvals, and multival if you haven't.
--Quanah
i’ll look into that, though i’m most interested if there’s any way to avoid rebuilding indexes with the architecture switch, by making the configuration match the amd64 defaults
Sent from Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Quanah Gibson-Mount quanah@fast-mail.org Sent: Friday, July 21, 2023 3:38:13 PM To: Maud Parratt Maud.Parratt@bjss.com; openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Friday, July 21, 2023 3:32 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
why? to be clear I'm experimenting on a smaller ephemeral test instance with non prod data, so there's no risk to trying things.
The man page spells it out pretty clearly:
index_hash64 { on | off } Use a 64 bit hash for indexing. The default is to use 32 bit hashes. These hashes are used for equality and substring indexing. The 64 bit version may be needed to avoid index collisions when the number of indexed values exceeds ~64 million. (Note that substring indexing generates multiple index values per actual attribute value.) Indices generated with 32 bit hashes are incompatible with the 64 bit version, and vice versa. Any existing databases must be fully reloaded when changing this setting. This directive is only supported on 64 bit CPUs.
I'm assuming that you have substring indices, and given the large size of your database you may start having hash collissions.
You most likely also want to configure olcBkMdbIdlExp, sortvals, and multival if you haven't.
--Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Friday, July 21, 2023 4:03 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
i'll look into that, though i'm most interested if there's any way to avoid rebuilding indexes with the architecture switch, by making the configuration match the amd64 defaults
Did you export your amd64 configuration via slapcat (assuming you're using cn=config) to see what value it has for the index hash?
--Quanah
Maud Parratt wrote:
I’ve configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
The indexes are still broken though, is this the configuration you’re referring to? Given my mdb is from an amd64 box, it’ll be 32 bit, so I want to match the configuration.
That is not what I wrote in my reply to you.
*From: *Howard Chu hyc@symas.com *Date: *Thursday, 20 July 2023 at 20:38 *To: *Quanah Gibson-Mount quanah@fast-mail.org, Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org *Subject: *Re: slapindex a 60GB mdb in reasonable time
Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this.
which configuration were you referring to exactly?
Sent from Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Howard Chu hyc@symas.com Sent: Saturday, July 22, 2023 8:25:43 PM To: Maud Parratt Maud.Parratt@bjss.com; Quanah Gibson-Mount quanah@fast-mail.org; openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
Maud Parratt wrote:
I’ve configured my arm64 instance with: dn: cn=config olcIndexHash64: FALSE
The indexes are still broken though, is this the configuration you’re referring to? Given my mdb is from an amd64 box, it’ll be 32 bit, so I want to match the configuration.
That is not what I wrote in my reply to you.
*From: *Howard Chu hyc@symas.com *Date: *Thursday, 20 July 2023 at 20:38 *To: *Quanah Gibson-Mount quanah@fast-mail.org, Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org *Subject: *Re: slapindex a 60GB mdb in reasonable time
Quanah Gibson-Mount wrote:
--On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu hyc@symas.com wrote:
Pretty sure they're not compatible. I.e., you must load from LDIF when switching architectures.
There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though.
Hm, not different page sizes perhaps? But if this is 64-bit on both ends, and the amd64 generated index databases don't work on ARM64, seems to indicate something's not compatible?
I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
--On Sunday, July 23, 2023 8:38 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
which configuration were you referring to exactly?
Did you read the man page on the setting?
'Indices generated with 32 bit hashes are incompatible with the 64 bit version, and vice versa. Any existing databases must be fully reloaded when changing this setting. This directive is only supported on 64 bit CPUs.'
You need to change it to 64-bit on the AMD64 box, regenerate the indices there, and then use the database on the ARM64 system. Simply changing the setting solves nothing and you want 64-bit anyhow.
--Quanah
Yes I did read the man page, nothing in it says that an mdb from an amd64 server which leaves the setting on it’s default shouldn’t work on an arm64 server with the setting explicitly set false, I’d hoped that it would but it certainly doesn’t.
You seem to be all but saying that for some reason I can’t run 32 bit indexes on my arm64 server with the mdb from the amd64 server, It’d have been easier if you’d just said that if that is indeed the case.
It would be significantly desirable for us to port to arm64 first, with a quick rollback position should the arm64 hosted server have performance issues in prod, which it may, then optimise indexes later which is unlikely to have any potential downsides. If that’s not possible I accept that. I’d just like to understand the options, or lack of options.
From: Quanah Gibson-Mount quanah@fast-mail.org Date: Sunday, 23 July 2023 at 20:43 To: Maud Parratt Maud.Parratt@bjss.com, openldap-technical@openldap.org openldap-technical@openldap.org Subject: Re: slapindex a 60GB mdb in reasonable time
--On Sunday, July 23, 2023 8:38 PM +0000 Maud Parratt Maud.Parratt@bjss.com wrote:
which configuration were you referring to exactly?
Did you read the man page on the setting?
'Indices generated with 32 bit hashes are incompatible with the 64 bit version, and vice versa. Any existing databases must be fully reloaded when changing this setting. This directive is only supported on 64 bit CPUs.'
You need to change it to 64-bit on the AMD64 box, regenerate the indices there, and then use the database on the ARM64 system. Simply changing the setting solves nothing and you want 64-bit anyhow.
--Quanah
The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
openldap-technical@openldap.org
-
Howard Chu -
Maud Parratt -
maud.parratt＠bjss.com
-
Quanah Gibson-Mount