Moin,
ah! The no-xmx-mistake! If you ommit the memory limitation, java uses (on
server-class machines) as default 1/4 of the physical memory.
(I found this blog entry
https://blog.openj9.org/2020/04/30/default-java-maximum-heap-size-is-changed-for-java-8/)
Ciao,
Andreas
-----Ursprüngliche Nachricht-----
Von: Arshiya Shariff <arshiya.shar...@ericsson.com.INVALID>
Gesendet: Montag, 14. September 2020 10:17
An: Tomcat Users List <users@tomcat.apache.org>
Betreff: RE: Track native memory of a Tomcat application
Hi All,
Thank you for the response Christopher .
* A single request, or a single *type* of request?
A single request (http/https) that is hit once per day
* Does it increase as the request is processed, or does the JVM take that 4GiB
immediately upon startup?
The tomcat process was started 3 months back , but the memory has
increased gradually to 4GB though it does not process requests continuously
(one request per day).
* The first thing to do would be to post the effective command-line options
that are being used when launching your JVM. One of the easiest ways to do that
is to run "ps | grep catalina" which will give you the full command-line for
the process.
There is no Xmx set:
ogw 30853 0.1 3.1 22048736 2068856 ? Sl Jun09 154:10
/opt/java//jdk1.8.0_201-amd64/bin/java
-Djava.util.logging.config.file=/opt/webstart//conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=false
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=false
-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=false
-Dorg.apache.catalina.connector.RECYCLE_FACADES=false -Dignore.endorsed.dirs=
-classpath /opt/webstart//bin/bootstrap.jar:/opt/webstart//bin/tomcat-juli.jar
-Dcatalina.base=/opt/webstart/ -Dcatalina.home=/opt/webstart/
-Djava.io.tmpdir=/opt/webstart//temp org.apache.catalina.startup.Bootstrap start
Thanks and Regards
Arshiya Shariff
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, September 11, 2020 10:54 PM
To: users@tomcat.apache.org
Subject: Re: Track native memory of a Tomcat application
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Arshiya,
On 9/11/20 13:06, Arshiya Shariff wrote:
> We have a standalone tomcat web application(Version 9.0.22) which runs
> on Linux . The application is used to process only a single http
> request.
A single request, or a single *type* of request?
> But the physical memory usage of the application has increased to 4GB
> (output from the "top" command of Linux) , of which the heap has only
> 16 MB of live data.
Does it increase as the request is processed, or does the JVM take that 4GiB
immediately upon startup?
Remember that the heap is only a part of the JVM's memory usage.
Examples of things that don't go into the heap are the native memory used by
the JVM itself (thinking of the JVM itself as a usual OS process), stacks for
each native thread, compiled Java code produced by the JIT, and various I/O
buffers.
> Is there a way to track the native memory of a tomcat process ?
The native memory of a Java application is very difficult to inspect, etc.
unless you are *very* familiar with JVMs, the memory manager being used by your
JVM, and the platform and architecture on which the JVM is running.
The first thing to do would be to post the effective command-line options that
are being used when launching your JVM. One of the easiest ways to do that is
to run "ps | grep catalina" which will give you the full command-line for the
process.
That will show any memory parameters you may have specified on the JVM at
launch time, which will definitely affect the amount of native memory your JVM
process might end up taking up.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird -
https://urldefense.proofpoint.com/v2/url?u=https-3A__protect2.fireeye.com_v1_url-3Fk-3Dafccd87f-2Df17c45e5-2Dafcc98e4-2D867b36d1634c-2D0bbd1bba405711b0-26q-3D1-26e-3D6321ad9b-2D27ed-2D403c-2D8d47-2D1699f85d092b-26u-3Dhttps-253A-252F-252Fwww.enigmail.net-252F&d=DwIFAg&c=xu_5lAfKHjInGFR3ndoZrw&r=N4b05szNzfzzBzdbzV7Q3p9SBOn_HZzSPs2tWonR2w4&m=yTRL9WIPqtP9RANn6t-iknJaPpQ-ZKPy785Odqn87SE&s=_DCyphjSrtIWDUlNeetiTF90ZuyoLkG4mzR_9jErg_c&e=
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9bsqoACgkQHPApP6U8
pFhfOA//cb427EP07vqPihuQUNWZtbfRyiDn+9B1AWEXLxKChpomSznUDmZWXs/t
w7YE6v6h741M8MiHKCJeUNz537DRxzMMCdoIlFFE48mZ/SFrg6xPgpMr2wQksz5S
zyKmInSXRmjKFfv1VUZ1tS6nF8dSxC+iSgC+axyBxU3cywVdJ/hCq8ylgq1mc9F7
JllfyxpQ2cRyioYkJWSR04BVDtXMFlyIhuBat8/OrXAEtsqhXCDXvM3cp8RvcIp6
Sg05MCb3nNM2495xt/m8jc1ffcyho5S4CDD1mfNfTLGG5vie5D81i95ExkPt6Voj
8TTI+Yk9MhauSyeroAX67SVJaTDMPqK3fUMuz+IX31tFo/5YMaQAMIe+XF+LW6Kz
EsbSDMRB460j8zAigPIt/9KTSfA8xT8R0t3dMPZytaB01tZZi7atq89QcoR+irrP
bFiFmErEcTdtyNZWWFeBQiEy1qZ+0J5GZSr7+6ZUwED20RNeWeZ1czHy/JaAsXMQ
kNZqx3iXDWbYq6yTTPdC2tJkl5TST+TW62zdJqpjh7L7hh7P9hJSwjwcDvyOdrXD
0uTaU8j+4b2W7Ex7DPO7XVVaYnhFMRJPc0cgKHXyrlz8/5HOTNDxLafHyPXS7dya
ffdyNz0k88OawGKXlWrvDQggi82tVInsEJoJID56qEp7x9tUuyQ=
=MuBQ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
