Hi.
Understood.
Make sure that you are looking at the "Java" tab.
I have an old installation of Tomcat 6 on my laptop, and took a screenshot of
that tab.
I am not sure that the image that I attach will make it on the list however (it strips
most attachments).
If not, here are the parameters which I see in the Java tab, in the box "Java
Options" :
-Djava.io.tmpdir=C:\apache-tomcat-6.0.24\temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=C:\apache-tomcat-6.0.24\conf\logging.properties
There is nothing about memory there, but this is where you should add the relevant
switches for the Java PermGen, one per line.
Further down, there are 3 more boxes :
Initial memory pool : 128 MB
Maximum memory pool : 256 MB
Thread stack size : (blank)
The first 2 are the Java Heap size (which is not your problem).
On my laptop, the JVM for the above is Sun's jdk7_u45.
Your mileage may vary..
There may be more to find out searching Google for "java default memory
settings" or similar.
This link provides an example of a setting for Java 6 / Tomcat 7 :
http://stackoverflow.com/questions/21104340/increase-windows-installer-based-tomcat-permgen-space
I saw something somewhere which mentioned 64 MB as the default PermGen (no
guarantees).
Another proviso : at this point, I am not quite sure if the PermGen is or not a part of
the Heap (Chuck ?).
If it is, and you increase the PermGen, you may need to also increase the Heap size
accordingly (see the 2 boxes above).
For maximum performance, it is also recommended to set the "initial" and "maximum" Heap
size values above to the same value (use the maximum of course), as this avoids the JVM
spending some time resizing the heap dynamically.
In any case, and still without guarantees or liability of any kind,
if you have enough memory on that server, it would probably not hurt to set the
following :
Initial memory pool : 1024 MB
Maximum memory pool : 1024 MB
and add the options
-XX:PermSize=128m
-XX:MaxPermSize=128m
to the Java Options.
On 21.10.2016 16:25, Moore, Jon, Vodafone UK wrote:
Thanks Andre.
When I open up tomcat6w.exe the fields are all blank, hence trying to find out
what the defaults are before I enter anything in them as I don't want to put in
a lesser value then the defaults.
-----Original Message-----
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: 21 October 2016 09:34
To: users@tomcat.apache.org
Subject: Re: java.lang.OutOfMemoryError: PermGen space
On 21.10.2016 09:46, Moore, Jon, Vodafone UK wrote:
Thanks Chris. (and to everyone else who has replied)
Yes I am a novice at Java as well. I support the IVR system that points to the
application servers and have ended up trying to resolve this issue as our
developers of the applications can't help.
The way we are told on the training to deploy the application in the IVR is to
use the deploy/un-deploy options in tomcat manager. I have also seen a
colleague make a copy of the applications war file away from its normal folder
(webapps), stop the tomcat Windows service, delete the applications deployed
folder and restart the tomcat windows service to re-deploy the application.
I have tried to run the commands you suggested from a CMD box but nothing gets
outputted.
Some additional info :
When Tomcat is running as a Service under Windows, the Java command-line switches (which
allow to control the Java memory sizes among other tings), are stored in the Windows
Registry. The Windows Tomcat-as-a-Service installation includes a program (named
"tomcat(version)w.exe", which is a kind of GUI Registry Editor, specially for
these Java/Tomcat related parameters. Normally, this program is running, and appears as
a small Apache icon at the bottom right of the console.
That is the program that you should use, to change the Java startup parameters,
and stop/start Tomcat.
As explained in previous posts here on this list, and in some of the articles
to which I pointed you in Google, it may be that your issue is only that the
default PermGen size, is insufficient for your application(s), and that just
increasing the Java PermGen size would solve the problem definitely.
Or not, if the application is flawed. But you can at least try.
For the full story about tomcat(x)w.exe, try the Tomcat FAQ (which does not seem to be
on-line right now, or very slow), and look for an article entitled "what are
tomcatx.exe and tomcatxw.exe".
Ah, here : http://wiki.apache.org/tomcat/FAQ/Windows
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 20 October 2016 17:40
To: Tomcat Users List
Subject: Re: java.lang.OutOfMemoryError: PermGen space
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jon,
On 10/20/16 6:00 AM, Moore, Jon, Vodafone UK wrote:
I have a problem where our customers application server stops working
intermittently and when we check the Tomcat logs we get the message "
java.lang.OutOfMemoryError: PermGen space" but the Tomcat service is
still running, and we have to restart the Tomcat service. I am a
complete novice when it comes to Tomcat but am expected to resolve
this issue as this server is part of the Avaya telephony solution.
I have 2 questions please.
1 - What would be causing this.
Are you also a Java novice as well? No judgement... I just want to
adjust my level of snark appropriately :)
Java has a special heap space called the "permanent generation" (a term which
becomes less descriptive as time goes on) but basically all java.lang.Class objects
loaded by the JVM go there. The more libraries and other stuff that gets loaded, the more
space in permgen is used.
The defaults for the size of permgen are often fairly small, and you may have
to raise them. This is especially true for applications that use large
frameworks like Spring.
Raising the permgen space is almost always the right decision under normal
circumstances when you get an OOME:permgen error. I would double whatever its
current value is and monitor the application for a while to see if that
improves things.
The only situation I know of where raising the permgen size is not the right move is when
there is a "classloader-pinning leak". That happens when you hot-deploy an
application many times, but the old versions of the application are not undeploying
cleanly. This situation is quite the rabbit-hole, so I'll stop there unless you can
confirm that you do hot-deployments without restarting Tomcat and the JVM.
If you instead get OOME for other reasons, it's frequently NOT the
right decision to increase the heap size because it usually indicates
that there is a memory leak in the application and giving it more heap
just means you'll wait longer between failures. Instead, the
application should be fixed to not leak memory :)
2 - What are the default Java memory settings for Initial memory
pool, maximum memory pool size and thread stack size when the fields
are blank when you use the "Configure Tomcat" interface on Windows. I
was wondering if changing one or more of these settings would help ?
The default depends upon the JVM and the OS.
We are running Tomcat 6.0.26 on Windows Server 2008 R2 standard and
JVM version is 1.6.0_20-b02
Best way to find out for sure[1] is:
C:\> java -XX:+PrintFlagsFinal -version 2>&1 | findstr HeapSize
The two settings you are looking for are MaxHeapSize and InitialHeapSize. Those values
are in bytes, so you'll probably have to divide by 1024 a couple of times to get at the
"real" value in human-readable terms.
The best way to find the default permgen size is:
C:\> java -XX:+PrintFlagsFinal -version 2>&1 | findstr PermSize
Hope that helps,
- -chris
[1]
http://stackoverflow.com/questions/2915276/what-is-the-default-maximum
-h
eap-size-for-suns-jvm-from-java-se-6
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYCPN3AAoJEBzwKT+lPKRYCXEQAK3AKioa7kRPTvs24yj+1vq6
SFo20WtjFhBrqyhSRdcvcwUjoDAIS6d6wqjDQ13v919jFRTsqCrDh9FQg1MeCWVB
UJVmcV33XjTQUmqEY03YUPwOVjgQe6RJM+FJAE60werkHEEirg85gL/WamQ+QtfW
C39sp2NO6kHpD7VWnBKPhToNmcy7lz2EK6Ye8aEXkn2mk2PZhJFRysgTqeJ/CChA
KnUzWAqrDBM3OtHerivHuIEHhJB7+43bD9kiX7JZXDlcVkubAz6bep3m2sXO3T9O
VYZs0ACKvnzuc6kqkStMcsGUeLWvYc5+xhCDNcxGhYXjrIWOaW5aS9QipZmAXze7
IoY2UC4vxyajRNuFmLeUWaeICDtYZaf/5d3wrlsbCIWF/vf2C+NpuynEidq6N6Yv
pFvTqRd+ZsNEbsKaQwaHSHsfQVxtQbPlFfUlYWvu7vz+Y5xCyTSFoct2UqDcBedi
Bo+vdHVoih/i9+4Zhg+Bieh5lygcoE9VS0KX2yu+4kwaaSohFoxwHcHXoD1SjXTU
FDq2H+GXV/3bS/hAek+5WzQuPJC5etsqcMUfIcf8YjrDmR6BabEvQFk5p9APYV+x
7lcODhWFlF3tEOvKiIRmPuQz/d4/hR5ETo6h12g2UMsfY9ogEZF7I8SP1uNK3bpO
cH97Lssd2MS5qj/Kd/m5
=JBc2
-----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
---------------------------------------------------------------------
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
