Mircea,
If your employer allows it, upload your GC logs to
https://gceasy.io/gc-index.jsp. One benefit of this tool over some of the
others is that it actually gives you qualitative feedback on what might be
wrong, if anything.
Thanks
From: Mircea Butmalai <mircea.butma...@radcom.ro>
Sent: Tuesday, July 29, 2025 8:21 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: memory leak analysis
Hello,
I have analyzed java memory heap for approximately default tomcat 10.1.43
installation.
Approximately default tomcat 10.1.43 installation means:
* Installation of tomcat is done on CentOS 9 with uname output as:
Linux centos9dev1.local 5.14.0-533.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 22
15:05:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
* Java environment is Eclipse Temurin JDK 21.0.7
* Apache Tomcat 10.1.43 archive tar.gz obtained from official tomcat site
and installed under special folder inside /opt specific to our project
* No .bat files in tomcat bin folder
* no examples and docs webapps, only default ROOT, manager and host-manager
webapps are delivered from official tomcat archive. No other custom webapps are
present in this heap memory test.
* tomcat file conf/tomcat-users.xml contains user with roles
manager-script, manager-status, manager-jmx, manager-gui
* Custom startup / shutdown / check bash scripts that basically launch
catalina.sh with custom java options.
* The check script verifies tomcat process and if ok it checks using
manager URL /manager/text/serverinfo in order to decide if tomcat is ok. The
client http access is done using system application curl.
* These custom scripts launch process under custom created system user and
all tomcat and java files are owned by this custom system user
The heap memory analysis was done as follows:
* Due to the fact that server info manager URL is already accessed by our
custom check script at a rate of 0.1 requests per second it was decided that
first test was to inject a bigger rate (5 requests per second) into tomcat
server from this manager URL /manager/text/serverinfo. Only this requests where
inside tomcat.
* Before injecting these requests a jstat process was started in order to
monitor heap memory at a rate of 5s. So we have a text file output from this
java application that offers stats about java memory collections.
* Data was collected for a duration of 265k seconds = aprox. 3 days
Graphical representation of EU (eden space utilization in KB), OU (old space
utilization KB) and MU (metaspace utilization KB) are attached inside this
email.
The questions are:
1. Why we have a constant increase for OU during this test.
1. The slope is significant and should be zero during this kind of test at
least after some reasonable time period like some minutes.
1. It is there a problem? When the slope is going to change to zero?
1. It seems like there is a very little slope even for MU which increases
from 16793.6 KB at 39k seconds to 16809 KB at 265k seconds. (diff is 15.4 KB).
The increase here is linearly distributed over the time interval. It is a
problem even here?
Thanks,
Mircea Butmalai
