March 16, 2020
Estimated Post Reading Time ~

Miscellaneous Administration

Thread Dump
Symptom:
§ System is performing slow
§ Response time is slow
§ Some of the requests is responding slow
There is the various way you can find a set of currently running threads in CQ:
Within CQ:
Go to HOST: PORT/system/console/config and navigate to the thread tab to find all running threads.


Using java tool:
§ first find the process ID of the CQ process. You can use command ps -ef | grep java | grep <author or publish> in UNIX based system and Ctrl + Shift + Esc in window
§ Then you can use jstack tool to get thread dump using command jstack <PID> >> thread.txt and run the same command for 10 times an interval of 2 seconds.
§ Once you have thread dump you can use any thread analyzer tool to find a long-running thread
You can use any of the following tools to analyze thread dump
1. http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
2. http://www.jroller.com/dumpster/entry/tda_as_jconsole_plugin
3. https://tda.dev.java.net/files/documents/4691/113000/tda-bin-2.1.zip
4. http://docs.day.com/en/home/docutools/javadump_exe.html
5. http://yusuke.homeip.net/samurai/en/samurai.jar
Some Useful Links:
1. http://helpx.adobe.com/cq/kb/TakeThreadDump.html
2. http://planet.jboss.org/post/simple_tools_to_analyze_thread_dumps
Heap Dump
Symptoms:

§ Application is running out of memory
§ Application is performing slowly because of frequent Garbage collection
There are various way you can take a heap dump of CQ application:
Automatic Heap Dump:
§ Using Command line argument:
You can use following JVM_OPTS to take automatic heap dump -XX:+HeapDumpOnOutOfMemoryError and
-XX:HeapDumpPath=/path/to/generate/heapdump more information about argument is here
§ Through CQ Console:
Manual thread dump:
§ Using CQ Console
§ Using jmap
1. First, find the process ID of the CQ process using ps -ef | grep java | grep <author or publish> command
2. Then you can run jmap command to get heap dump jmap -dump:format=b,file=/path/to/generate/heapdumpfile.hprof <PID>
Once you have a heap dump you can use any heap dump analyzer tool to analyze the heap dump.
1. http://www.eclipse.org/mat/
Some Useful links:
1. http://helpx.adobe.com/crx/kb/AnalyzeMemoryProblems.html
2. http://docs.oracle.com/javase/6/docs/technotes/tools/share/jhat.html

CQ Profiler
Symptom:
§ System is performing slow
§ Some of the pages is responding very slow
Taking Profiler Dump:
§ Go to HOST:PORT/system/console/profiler
§ Select options (Optional)
§ Click on start collecting
§ More time you wait more data will be collected
§ Click on stop to show data. The output will show all current thread running in detail which is useful to find out which process is taking more time.
§ Save Page as html to refer it later

Analyze Open Session
Symptom:

§ System is performing slow
§ There is a lot of open session error in the log
§ System runs out of memory after some time
Any writes or update in a repository through API is done through the JCR session. But sometimes developers forget to close sessions causing the session to remain open. A number of open sessions grows it cause performance issue. The system eventually comes to a point where it does not respond anymore.
How to find Open Session:
§ First find PID of CQ process using ps -ef | grep java | grep <author | publish> or jps -l or control + shift + U (In windows) command.
§ Once you have process ID you can use jmap -histo <PID> | grep "CRXSessionImpl" command to find all open sessions. If output count is more than 100 that means there could be some issue.
How to find code, not closing session:
§ In order to start CQ in session debug mode, you can use -Dcrx.debug.sessions=true JVM_OPTS while starting CQ
§ Then use following command to analyze log file java -jar session_analyzer.jar <log_file> | sort > output.txt
§ You can find session_analyzer.jar from here
§ You can then analyze output.txt to find an open session  

Example:
com.day.crx.j2ee.JCRExplorerServlet.login(JCRExplorerServlet.java:521)
ResourceServlet.spoolResource(ResourceServlet.java:148)
java.lang.Thread.run(Thread.java:595): session# 10023
This example means session #10023 was not closed, and the stack trace included the given lines when the session was opened.
Some Useful Link:
§ http://helpx.adobe.com/crx/kb/AnalyzeUnclosedSessions.html

Collecting Configuration Data
Use Case:

§ Collect Data to debug product issue
§ Compare two instances
§ Find version of bundle installed
You might often have a situation where you need to share your instance data with Adobe to debug certain issues. You can do the following to collect configuration data
§ Go to HOST:PORT/system/console/config
§ Click on Download as text or Download as Zip



By aem4beginner

No comments:

Post a Comment

If you have any doubts or questions, please let us know.