Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

Prod Author performance issue


Level 2

Hello Everyone,

We have an issue facing since an year or so with the Prod. We are on 6.1 SP2 with the instances being managed by Adobe. Author and Publish both are on SSD. Author is experiencing high CPU writes and the replication log is filling up with lots of workflow replication process logs. This happens whenever we do a restore from the backup and it affecting the Author performance. For time being we have bumped up the size of the author instance to put it in safer condition and restarting the author instance when ever it's getting into a critical condition. We also tried disabling the specific workflow which is running in the background and generating the logs, it helped for a while but we are still experiencing the performance issues upon activation of pages or activation of assets after the restart. We do a cleanup task every weekend and we do a monthly maintenance on PROD. We are now planning to do a bi-weekly maintenance, but still unsure if this gonna help us.

We are in the process of upgrading to 6.3, it should be happening in next 15days.

Really appreciate your time in going through this question, and would like to hear suggestions/inputs on what we did or on what needs to be done.

Thanks in advance.



0 Replies


Employee Advisor


Technically a restore from a backup shouldn't be any different from a simple restart of AEM with a repository in a certain state. The only difference might be, that this state is quite recent (when restarting) compared to restore (it's more distant in the past).

You should analyze the logst to see at which point during startup (or after startup) the difference between a restart and that condition you describe becomes obvious. It might be after the start of a certain service, and then check that service. Or it might get visible in threaddumps.

Anyway, I haven't observed such a behaviour in my experience, so I would assume it is caused by custom code. And in that case any upgrade to a more recent version of AEM will not change that behaviour.