Hi,
Thank you for your interesting feedback.
Indeed we should improve the https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html FAQ
Clearly we should add more detail about nsslapd-mdb-max-size as it is the main configuration parameters.
Yes it is the maximum database file size on disk (and also in memory as the file is memory mapped)
So yes if you greatly oversize the size, the memory map creation needs more time to write the db file
and the system is likely to swap.
If the size limit is reached, any further writes operation will fail until the size has been increased and the instance restarted.
The main change between 2.5 and 3.0.1 is the database type that is used by default when creating a new instance (now mdb instead of bdb)
So yes, instances created with bdb are still using bdb after migrating to 3.0.1
And in 3.0.1 dscreate can still create a new instance with bdb
But beware that the underlying libdb library that we are relying on, has been tagged obsolete in 2020
Thank you for your interesting feedback.
Indeed we should improve the https://www.port389.org/docs/389ds/FAQ/Berkeley-DB-deprecation.html FAQ
Clearly we should add more detail about nsslapd-mdb-max-size as it is the main configuration parameters.
Yes it is the maximum database file size on disk (and also in memory as the file is memory mapped)
So yes if you greatly oversize the size, the memory map creation needs more time to write the db file
and the system is likely to swap.
If the size limit is reached, any further writes operation will fail until the size has been increased and the instance restarted.
The main change between 2.5 and 3.0.1 is the database type that is used by default when creating a new instance (now mdb instead of bdb)
So yes, instances created with bdb are still using bdb after migrating to 3.0.1
And in 3.0.1 dscreate can still create a new instance with bdb
But beware that the underlying libdb library that we are relying on, has been tagged obsolete in 2020
and will disappear soon.
Regards,
Pierre
Regards,
Pierre
On Mon, Jul 1, 2024 at 7:34 PM <tdarby@arizona.edu> wrote:
The mdb change came as a worrying surprise when the container pulled down 3.0.1 without me realizing it. I've read as much as I can find (which is not much), but I don't understand all the changes. Questions:
1. Is there a way to continue to pull the 2.5 version of the container?
2. If I update an existing 2.5 container instance to 3.0.1, will it continue to use bdb?
3. The nsslapd-mdb-max-size attribute:
- Does this only set the size of the db on disk? What if it exceeds that limit?
- I was going to set it to "use all available space" until I saw these comments, but not sure what to make of them and I don't feel any closer to understanding what I should do with this attribute:
- the file will tend to grow up to its maximum
- if real memory is smaller than the file then pages will be swappped
- My first experience about configuring oversized database was interresting:
at first I did not capped the value to 1Gb and the basic import scenario was spending
hours before failing because disk was full (with a real db size around 10Gb on the test VM)
while once capped to 1 GB the import was successful in less than 10 minutes
==> *Correct sizing matters*"
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
389 Directory Server Development Team
389 Directory Server Development Team
No comments:
Post a Comment