Uploaded image for project: 'OpenDJ'
  1. OpenDJ
  2. OPENDJ-2446

dsreplication purge-historical uses an inappropriate amount of server memory if many entries match search criteria

    Details

    • Support Ticket IDs:
    • Sprint:
      DJ Sustaining Sprint 16, DJ Sustaining Sprint 19, DJ Sustaining Sprint 20, DJ Sustaining Sprint 21

      Description

      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:

      [04/Nov/2015:20:15:10 +0000] SEARCH REQ conn=-1 op=333 msgID=334 base="dc=example,dc=com" scope=wholeSubtree filter="(ds-sync-hist>=dummy:0000000000000000000000000000)" attrs="ds-sync-hist,entryuuid,*"
      

      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

        Attachments

          Activity

            People

            • Assignee:
              ian.packer Ian Packer [X] (Inactive)
              Reporter:
              ian.packer Ian Packer [X] (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: