purge-historical cleans up old ds-sync-hist attributes from entries
The way this task finds entries that need attention is by running an internal search with an unlimited size and time limit, with a signature like this:
If it has never run before it uses a 0 CSN to start from as per the above example, otherwise it may start from a later CSN.
In any case, if the number of results from this search is large, an inappropriate amount of memory will quickly be consumed, running the server out of resources.
The number of results may be large because the server is very high in traffic and the time between purges is long. Or simply because the server has run for some time, has a lot of ds-sync-hist attributes on entries and then purge-historical is run for the first time.
purge-historical does have a 'maxDuration' that can be specified, but this is not helpful in this case.
The purge historical task should probably be modified to get results in a more incremental fashion, e.g 1000 at a time, process them and repeat. This would be a lot more robust and less resource intensive. It would also allow the 'maxDuration' to be more meaningful/effective.
To reproduce this the following steps are enough to clearly highlight the problem:
1) Setup a server with 200k test data and replication enabled.
2) Run a modify on every entry so each one gets a ds-sync-hist
3) Run ./dsreplication purge-historical