Slow CTS during the deletions of the expired tokens

This topic has 1 reply, 2 voices, and was last updated 3 years, 2 months ago by JnRouvignac.

  • Author
    Posts
  • #17222
     Gentjan Kocaqi
    Participant

    Hi,

    I am doing some tests with OpenAM 13.5 that is using OpenDJ 3.0.0 as config store, user data store and CTS store.
    Basically I have 3 OpenDJs where everything is in replication. The dbcache is set to 50% (I can’t increase it to 90% in this configuration).

    The JDK used is OpenJDK 8 and the JVM parameters for the CTS are:  -server -Xms4096m -Xmx4096m -Xmn1024m. No indexes for coreToken attributes.

    Once that a token is expired in OpenDJ, then OpenDJ takes care of deleting it. I have around 100.000 expired core tokens, total number of user entries around 500.000.

    Well, I noticed that this deleting operation takes etimes between 200-400ms a piece (around 3 deletes per second). And it seems that it takes 30MB/s write to disk. No other activities at all agains OpenDJ.

    Do you have any idea why I am having this performance?

    Thanks

    #17496
     JnRouvignac
    Participant

    Try reducing the delay between CTS Reaper runs.

    Main problem of the CTS Reaper is that it does deletes in batches. When a lot of deletes are accumulating, it overloads OpenDJ with tens of thousands of deletes which increases etime for these operations. It also reduces availability for other concurrent operations.

    Reducing the delay between CTS Reaper runs means it will try to delete less tokens at the same time, thus reducing these “bursty” loads on OpenDJ.
    It will also help OpenDJ replication a lot.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

©2020 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?