AEM Author is very slow | Community
Skip to main content
adivj95
Level 2
November 2, 2023
Solved

AEM Author is very slow

  • November 2, 2023
  • 3 replies
  • 2631 views

Hi Community

 

Our AEM author environment is very slow, even a simple operation like deleting page or editing a page is taking 10-20 mins
Currently repository size is 113 GB

We have already enabled maintenance activities like revision cleanup, lucene binary cleanup, version purge, workflow purge , data storage garbage collection

Please Help

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by MarkusBullaAdobe

Hi @adivj95!

There's very little information provided to give qualified advice. Just in general, a repository size of 113 GB is not considered very large and should not cause performance issues by itself.

There are a couple of things to check as a starting point for your analysis:

  • When did the performance started to degrade?
    Was there anything changed?
  • (How) Do you measure performance?
  • What version of AEM are you running?
    Is this on-premise, AMS, Cloud Services?
  • What does your general monitoring tell you about the host running AEM?
    Looking at CPU load, memory, file system stats, etc.?
    What about JVM stats, such as heap usage, garbage collections, etc?
  • Did you check different vectors to access AEM? Is the AEM Java process slow? Is it the overall host? Might there be an issue on a network layer (slow connection)?

These are some very generic starting points for further investigation.

 

Hope that helps!

3 replies

aanchal-sikka
Community Advisor
Community Advisor
November 2, 2023

Hello @adivj95 

 

Please consider running offline compaction

Revision Cleanup | Adobe Experience Manager

https://helpx.adobe.com/experience-manager/kb/oak-offline-compaction---improve-performance--avoid-memory-issue.html

 

Also, please take a thread and heap dump, before stopping server. It will help you analyze issues in the application code.

check for sessions that might be open for too long.

 

Also, please refer to https://helpx.adobe.com/experience-manager/kb/AnalyzeSlowAndBlockedProcesses.html 

Aanchal Sikka
MarkusBullaAdobe
Adobe Employee
MarkusBullaAdobeAdobe EmployeeAccepted solution
Adobe Employee
November 2, 2023

Hi @adivj95!

There's very little information provided to give qualified advice. Just in general, a repository size of 113 GB is not considered very large and should not cause performance issues by itself.

There are a couple of things to check as a starting point for your analysis:

  • When did the performance started to degrade?
    Was there anything changed?
  • (How) Do you measure performance?
  • What version of AEM are you running?
    Is this on-premise, AMS, Cloud Services?
  • What does your general monitoring tell you about the host running AEM?
    Looking at CPU load, memory, file system stats, etc.?
    What about JVM stats, such as heap usage, garbage collections, etc?
  • Did you check different vectors to access AEM? Is the AEM Java process slow? Is it the overall host? Might there be an issue on a network layer (slow connection)?

These are some very generic starting points for further investigation.

 

Hope that helps!

Sudheer_Sundalam
Community Advisor
Community Advisor
November 2, 2023

@adivj95 ,

 

I would start with observing error.log and any other custom logs to see any pattern of error logging into the log files.

This will help if AEM Author is trying to do some operation which is failing again and again and the system is stuck in that loop.

Definitely take thread and heap dumps to analyze any blocked or memory consuming threads.

- Take a look the replication and other queues if they are blocked or having huge number of scheduled jobs trying to execute.

- If you have access to the machine where you are running this AEM instance, try running "top" command and see the vital of machine itself like memory usage, cpu usage, AEM instance memory and cpu usage with respect to total available CPU cores and Memory GB.

- We can't ignore the network connectivity aspect here. If you can ssh into the machine, try running some simple curl commands to various urls to see the response time.

 

Hope these suggestions help!