> On 2025 Jul 29, at 08:20, Mircea Butmalai <mircea.butma...@radcom.ro> wrote: > > 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.
Or not. The mailing list strips attachments, so you’ll need to post them somewhere public for anyone to look at them, or display the information as text. > The questions are: > Why we have a constant increase for OU during this test. > The slope is significant and should be zero during this kind of test at least > after some reasonable time period like some minutes. > It is there a problem? When the slope is going to change to zero? > 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? Do you know if garbage collection occurred during this interval? Do you have GC logging enabled? - Chuck
