High CPU in DS 5, 5.5, 5.5.1 and OpenDJ 3.5.2, 3.5.3 when RS is writing to another RS

Last updated Apr 8, 2021

The purpose of this article is to provide assistance if you observe high CPU in DS/OpenDJ when one Replication Server (RS) is writing to another RS.


This article has been archived and is no longer maintained by ForgeRock.


You observe high CPU utilization on one or more replication servers. Restarting the DS/OpenDJ service and/or server does not resolve it.

An error similar to the following is shown in the stack trace (jstack) when this happens:

CPU = 99.9 "Replication server RS(1000) writing to Replication server RS(2000) for domain "dc=example,dc=com" at" #111 prio=5 os_prio=0 tid=0x0007fbaf01c71800 nid=0x617d runnable [0x00007f6f7fbf9000] java.lang.Thread.State: RUNNABLE at Method) at at org.opends.server.replication.server.changelog.file.BlockLogReader.readNextRecord( at org.opends.server.replication.server.changelog.file.BlockLogReader.readRecord( at org.opends.server.replication.server.changelog.file.BlockLogReader.searchClosestBlockStartToKey( at org.opends.server.replication.server.changelog.file.BlockLogReader.seekToRecord( at org.opends.server.replication.server.changelog.file.LogFile$LogFileCursor.positionTo( at org.opends.server.replication.server.changelog.file.Log$InternalLogCursor.positionTo( at org.opends.server.replication.server.changelog.file.Log$AbortableLogCursor.positionTo( at org.opends.server.replication.server.changelog.file.FileReplicaDBCursor.nextWhenCursorIsExhaustedOrNotCorrectlyPositionned( at at at org.opends.server.replication.server.changelog.file.CompositeDBCursor.addCursor( at org.opends.server.replication.server.changelog.file.CompositeDBCursor.recycleExhaustedCursors( at at

You can collect a stack trace as shown in How do I collect JVM data for troubleshooting DS?

In the changelogDb, you may notice DSID.server files for obsolete servers. Alternatively, you will have a large number of directory servers in your replication topology. 

Recent Changes

Upgraded to, or installed DS 5, 5.5 or 5.5.1.

Upgraded to, or installed OpenDJ 3.5.2 or 3.5.3.

Repeatedly enabled and disabled replication (using dsreplication configure/unconfigure or dsreplication enable/disable depending on your version).


When you repeatedly enable and disable replication, old replica ID data (DSID.server) remains in the changelogDb. Due to the obsolete DSID.server data and/or the sheer number of directory servers, the changelogDb will contain a lot of data. When one RS is writing to another and iterating through the changelogDb files, this data is constantly being opened and read, which results in high CPU.


This issue can be resolved by upgrading to DS 5.5.2 or later; you can download this from BackStage.


Please raise a ticket for assistance; the procedure to workaround this issue should only be performed under support supervision.

See Also

How do I collect data for troubleshooting high CPU utilization on DS (All versions) servers?

How do I find which thread is consuming CPU in a Java process in DS?

How do I migrate an existing DS+RS replication topology to a DS to RS topology in DS 6.x?

Troubleshooting DS

Related Training


Related Issue Tracker IDs

OPENDJ-4598 (Replication Server cursoring through obsolete replica ID's causing high CPU spin)

Copyright and Trademarks Copyright © 2021 ForgeRock, all rights reserved.