Monitoring and tuning Java applications deployed on SCP
The aim of this post is to explain how to help you monitoring Java applications deployed on SCP.
First of all, let’s go through the main monitoring built-in functionalities available and clearly visible and then we will go through the advanced functionalities which may be a bit hidden but are very important and valuable to use.
Step1 : Using the main monitoring built-in functionalities available and clearly visible
- Monitoring physical resources such CPU, Memory, Disk I/O:
In order to monitor such metrics, that’s the probably easiest to get.
They are available within the cockpit whenever a Java application is deployed:
First of all, go to the Java applications:
Click on your Java application that you need to monitor. Then the following navigation menu displays as per below:
Then, this is where the interesting part starts 🙂
Clicking on the Application Monitoring will display the following graphs:
- Average Response Time (ms)
- Busy Threads
- CPU Load (%)
- Disk I/O (B/s)
- Free EBS Space (%)
- Heap Memory Usage (%)
- OS Memory Usage (%)
- Requests per Minute (requests)
- Used Disc Space (%)
Each graph can be zoomed-in in order to check for a specific timeframe or sometimes, it is useful whenver it is required to adjust the scale such for example once a very high response time appeared and it is not then possible to see the details later on.
Step 2 : Using advanced monitoring built-in functionalities available and not visible cleary
There is a huge of valuable monitoring information avaiable from the JMX console.
The JMX console is accessible in the navigation as below:
Then, a folder hierarchy like structure will appear.
Now, let’s go the most important metrics from the JMX console (… or at least the ones I could find the most useful for me once monitoring) .
- Monitoring the JDBC connection pool:
Once monitoring a live system or also a system where we put some load for example for performance and stress tests, it is always a good idea to monitor it and make sure we do not run into a performance bottleneck in this area.
In order to monitor it, you need to browser into the following level:
com.sap.cloud.jmx -> Persistence -ConnectionPools:
Once monitoring a system, these information above are very precious.
Below, the most critical metrics in my view:
- MaxConnections is the maximum number of connection the pool will open.
- BorrowedConnectionsCount is the number of connections “borrowed” to the application.
- PooledConnectionsCount is the number of connections available in the pool.
There are others metrics which can also show how much time threads have been waiting to get a connection and which could also be a good indicator to help you sizing properly the number of maxium connections to set in the pool.
- Triggering thread dumps:
As for all Java applications, it is sometimes required to be able to trigger thread dumps to analyze locking situation issues/hanging situations. Therefore, it is also possible
The previous KBA/Note will also explain you how to download the thread dumps then and analyze them.
In order to analyze them, I will then recommend you to use the SAP Thread Dump Viewer tha you can also find below:
- Analyzing Garbage Collections:
It is possible to analyze the Garbage Collections. To do so, you can review them from the SCP cockpit from the Logging and then in the section ‘Garbage Collection Logs’:
You can the either visualize it online from the cockpit or download the file itself and open it with your prefered GC viewer log.
- Setting JVM arguments (neo command line)
Below, is the reference guide how to configure VM arguments:
You can for example fine tune the JVM parameters if you wish to increase the heap memory/resize the new area, etc…
Another useful guide is the one to deploy using the neo command line:
I will keep enriching this blog… therefore stay tuned…