This content has been marked as final. Show 5 replies
one of the reasons why a DS instance 'slows-down' in the long term COULD BE due to the page fragmentation/occupation and/or the presence of tombstones (and empty graves: segments with deleted entries) in the underlying DB.
If you have a huge DB with a lot of writes (ADD/MOD/DEL) it's reasonable that after a long amount of time the DB may become a bit fragmented. Depending on the version, there could be different approaches and techniques to overcome this problem: repacking is one of them (with a long and troubled history, this feature has been available originally since 6.x, disabled in 7.x, re-enabled in 18.104.22.168).
Re-initializing the DB, COULD BE a good idea, but it strongly depends on WHAT you use to re-init: if you use an LDIF WITH the replica information, you'll be mostly rebuilding the DB and indexes, so reducing the fragmentation at 'filesystem level', but you'll still keep a lot of 'garbage' (tombstones and graves) in the DB and indexes themselves.
IMHO the only way to completely refresh the content of a Directory Server instance would be exporting to LDIF WITHOUT the replica information, and then re-init with that: this will generate a 'new and compact' DB and set of indexes not only reducing the fragmentation at 'filesystem level', but also it will be 'purged' of all the tombstones and empty graves left over by previous MOD/DEL operations.
The non-trivial downside of this approach is that if you're dealing with a replicated environment (which is very common), you'll also have to perform a full top-down topology re-initialization.
Thanks a lot for your explanation.
As we have a big topology, just started doing only for spoke servers (not done for masters yet).
But now I understand that a complete top-down topology re-initialisation should be performed in order to refresh the DB completely.
So do we need to start from masters?