Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount quanah@symas.com a écrit :
--On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter dieter@dkluenter.de wrote:
olcDbMaxSize defined for this database? Thanks!
Depending on the number of operations you may set logpurge to a appropriate value.
Yeah, I think the question is, what happens if you have so many operations in an <interval> that it maxes out the DB, where the interval is smaller than the logpurge interval.
Hi all,
Thank you Quanah for your answers (and Dieter too, it seems :)). This was indeed the question.
But it's a good point, one could (if using
cn=config) do an on-the-fly modification of the logpurge interval so that the DB gets purged more frequently to accomodate the rate of change.
--Quanah
Would a small logpurge interval strongly influence the system's performance? If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event. If it wouldn't, setting a small enough interval from the beggining would do the trick.
Regards,
Manuela
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Le mer. 15 mai 2019 à 06:33, Manuela Mandache manuela.mandache.mm@gmail.com a écrit :
Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount quanah@symas.com a écrit :
--On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter dieter@dkluenter.de wrote:
olcDbMaxSize defined for this database? Thanks!
Depending on the number of operations you may set logpurge to a appropriate value.
Yeah, I think the question is, what happens if you have so many operations in an <interval> that it maxes out the DB, where the interval is smaller than the logpurge interval.
Hi all,
Thank you Quanah for your answers (and Dieter too, it seems :)). This was indeed the question.
But it's a good point, one could (if using
cn=config) do an on-the-fly modification of the logpurge interval so that the DB gets purged more frequently to accomodate the rate of change.
--Quanah
Would a small logpurge interval strongly influence the system's performance? If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event.
Or even an automatic both ways on-the-fly adjustment of olcDbMaxSize for the accesslog DB, wouldn't this be better?
If it wouldn't, setting a small enough interval from the beggining would do the trick.
Regards,
Manuela
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, May 15, 2019 11:21 AM +0200 Manuela Mandache manuela.mandache.mm@gmail.com wrote:
Or even an automatic both ways on-the-fly adjustment of olcDbMaxSize for the accesslog DB, wouldn't this be better?
The point of the maxsize setting is to set it to a very large value you never anticipate hitting even under a large number of changes. I.e., I usually tend to set it to 80GB. I would note that since the accesslog db only stores deltas, and it routinely purges data, one generally should not hit any max size limitation if configured correctly. One exception would be perhaps if you were to add several million entries to the LDAP DB at once during a single day or something.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Manuela Mandache manuela.mandache.mm@gmail.com writes:
Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount quanah@symas.com a écrit :
--On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter dieter@dkluenter.de wrote:
olcDbMaxSize defined for this database? Thanks!
Depending on the number of operations you may set logpurge to a appropriate value.
Yeah, I think the question is, what happens if you have so many operations in an <interval> that it maxes out the DB, where the interval is smaller than the logpurge interval.
Hi all,
Thank you Quanah for your answers (and Dieter too, it seems :)). This was indeed the question.
But it's a good point, one could (if using cn=config) do an on-the-fly modification of the logpurge interval so that the DB gets purged more frequently to accomodate the rate of change.
--Quanah
Would a small logpurge interval strongly influence the system's performance? If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event. If it wouldn't, setting a small enough interval from the beggining would do the trick.
It all depends on the syncrepl intervals. The logpurge interval should consider the timegap between 2 synchronization operations. It is hard to say to what extend performance will be influenced, you should find out yourself and set the system optimum, it might vary between a few ours and a few days.
-Dieter
Le mer. 15 mai 2019 11:37, Dieter Kluenter dieter@dkluenter.de a écrit :
Manuela Mandache manuela.mandache.mm@gmail.com writes:
Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount quanah@symas.com a
écrit :
--On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter dieter@dkluenter.de wrote:
olcDbMaxSize defined for this database? Thanks!
Depending on the number of operations you may set logpurge to a appropriate value.
Yeah, I think the question is, what happens if you have so many
operations
in an <interval> that it maxes out the DB, where the interval is
smaller
than the logpurge interval.
Hi all,
Thank you Quanah for your answers (and Dieter too, it seems :)). This
was indeed the question.
But it's a good point, one could (if using cn=config) do an on-the-fly modification of the logpurge interval so
that
the DB gets purged more frequently to accomodate the rate of change.
--Quanah
Would a small logpurge interval strongly influence the system's
performance?
If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event. If it wouldn't, setting a small enough interval from the beggining would
do the trick.
It all depends on the syncrepl intervals. The logpurge interval should consider the timegap between 2 synchronization operations.
Actually, the replication is in refreshAndPersist mode.
It is hard to
say to what extend performance will be influenced, you should find out yourself and set the system optimum, it might vary between a few ours and a few days.
Thanks again,
Manuela
--On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache manuela.mandache.mm@gmail.com wrote:
Actually, the replication is in refreshAndPersist mode.
Replication mode is immaterial.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Wednesday, May 15, 2019 12:33 PM +0200 Dieter Kluenter dieter@dkluenter.de wrote:
Would a small logpurge interval strongly influence the system's performance? If it would, a both ways on-the-fly change based on automatic watch of the actual size of the accesslog database might be interesting if the high rate writes are a seldom event. If it wouldn't, setting a small enough interval from the beggining would do the trick.
It all depends on the syncrepl intervals. The logpurge interval should consider the timegap between 2 synchronization operations. It is hard to say to what extend performance will be influenced, you should find out yourself and set the system optimum, it might vary between a few ours and a few days.
It depends on how many changes fit within a time period. I always suggest a frequent log purge setting, as this significantly reduces the impact on the system. For example, say that the log purge deletes all entries > 1 day old. If you have 10,000 changes per day that are about evenly distributed, then we end up with purges like this (depending on purge interval):
Purge once a day: 10,000 deletes per purge
Purge twice a day: 5,000 deletes per purge
Purge four times a day: 2,500 deletes per purge
etc.
I usually have the log purge interval set to 4 hours (6 times a day). As I've discussed before, it's better to purge frequently, as server processing comes to a halt while the purge is ongoing. With a single daily purge interval in a production environment that has thousands of changes, I've seen slapd pause for several minutes (I.e., stop processing requests). Changing the configuration to have a purge interval of every 4 hours made it so slapd only paused for less than a second and was not noticable to applications.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Dieter Kluenter -
Manuela Mandache -
Quanah Gibson-Mount