On 05/16/2012 11:19 AM, Brad Schuetz wrote:
On 05/16/2012 06:16 AM, Paul Robert Marino wrote:
The exact timing of the issue is to strange is there a backup job
running at midnight. Or some other timed job that could be eating the
ram or disk IO. Possibly one that is reliant on ldap queries that
would otherwise be inocuious.
It doesn't happen at midnight, it's 24 hours from when the process was
started, so I can restart dirsrv at 3:17pm on Wednesday and at right
around 3:17pm on Thursday that server will go to 100% disk IO usage.
The default tombstone purge interval is 1 day, which seems to fit what
you are seeing. The tombstone reap thread will start every 24 hours to
find tombstone entries that can be deleted. The default retention
period for tombstones is 1 week. It is possible that you have a large
number of tombstone entries that need to be deleted. This will occur
independently on all of your server instances. This is controlled by
the "nsDS5ReplicaTombstonePurgeInterval" and "nsDS5ReplicaPurgeDelay"
attributes in your "cn=replica,cn=<suffixDN>,cn=mapping tree,cn=config"
entry.
You can search for "(objectclass=nstombstone)" as Directory Manager to
see how many tombstone entries you have.
I've restarted the servers at totally random times to reproduce this
issue, and currently restart, via cron, all my ldap servers twice per
day at randomly selected times of the day to make sure that both they
are restarted before the 24 hours hits, and so that no more than 1
dirsrv process is being restarted at the same time.
Keep in mind, the ldap queries load has not changed from the setup I was
running prior to this which was running (much) older versions of the 389
server software. In fact, as part of this system upgrade, additional
servers were added to reduce the individual load on each server.
--
Brad
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
