JVM Parameters in Configtool

Everyone,
Can somebody explain me how to change JVM paramters in Configtool step by step.
I opened configtool and Instance_IDXXXXX,Right side i see Servers General and Java Parameters.
I changed the parameters,saved and restarted the cluster. But,the settings are not getting applied.
Have I missed any steps? i didn't switch it to edit mode since i was lready able to change it here.
And i am using <SID>adm. In edit mode,configtool changed to tree structure.
Can somebody explain me what exactly missing and how to change JVM step by step ? Kindly help..

Hi. Instead of the path Cluster_data - Instance_ID### - Servers General, follow the path cluster_data - instance_ID### - server_ID#### - 'General' tab - java parameters. Enter the VM settings there.
Repeat for each server in under the instance_ID### node.
Save your changes and restart the instance

Similar Messages

Setting JVM parameters....

Hi SDN,

I want to check the JVM parameters set for the portal.
The version of the portal is EP 6.0 SP19.
Where can I get the information?????

regards
Brahmachaitanya

Hi
You can change the JVM Settings in the ConfigTool.
Enter the "Java parameters" field for your desired input.
Save and restart the cluster and you are done!
You can also check by looking at the instance.properties file.
Cheers.
Please award points for helpful answers.

New FAQ Entry on JVM Parameters for Large Cache Sizes

I've posted a new [FAQ entry|http://www.oracle.com/technology/products/berkeley-db/faq/je_faq.html#60] on JVM parameters for large cache sizes. The text of it is as follows:
What JVM parameters should I consider when tuning an application with a large cache size?
If your application has a large cache size, tuning the Java GC may be necessary. You will almost certainly be using a 64b JVM (i.e. -d64), the -server option, and setting your heap and stack sizes with -Xmx and -Xms. Be sure that you don't set the cache size too close to the heap size so that your application has plenty of room for its data and to avoided excessive full GC's. We have found that the Concurrent Mark Sweep GC is generally the best in this environment since it yields more predictable GC results. This can be enabled with -XX:+UseConcMarkSweepGC.
Best practices dictates that you disable System.gc() calls with -XX:-DisableExplicitGC.
Other JVM options which may prove useful are -XX:NewSize (start with 512m or 1024m as a value), -XX:MaxNewSize (try 1024m as a value), and -XX:CMSInitiatingOccupancyFraction=55. NewSize is typically tuned in relationship to the overall heap size so if you specify this parameter you will also need to provide a -Xmx value. A convenient way of specifying this in relative terms is to use -XX:NewRatio. The values we've suggested are only starting points. The actual values will vary depending on the runtime characteristics of the application.
You may also want to refer to the following articles:
* Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning
* The most complete list of -XX options for Java 6 JVM
* My Favorite Hotspot JVM Flags
Edited by: Charles Lamb on Oct 22, 2009 9:13 AM

First of all please be aware HSODBC V10 has been desupported and DG4ODBC should be used instead.
The root cause the problem you describe could be related to a timeout of the ODBC driver (especially while taking care of the comment: it happens only for larger tables):
(0) [MySQL][ODBC 3.51 Driver]MySQL server has gone away (SQL State: S1T00; SQL
(0) Code: 2006)
indicates the Driver or the DB abends the connection due to a timeout.
Check out the wait_timeout mysql variable on the server and increase it.

JVM parameters in MANIFEST file

I deployed my Swing app in a JAR file wih the following manifest file:
Manifest-Version: 1.0
Created-By: 1.4.0 (Sun Microsystems Inc.)
Main-Class: MainApplication
Class-Path: . jarfile1.jar ................ jarfilen.jar
Everything is ok except I don't know how to specify the following JVM parameters: -Xmx256M -Xms128M -Xss1M. Can someone help me, please ?
Thanks in advance

Probably these parameters ( -Xmx256M -Xms128M -Xss1M ) must be specified in the properties of the link that launch java -jar yourJar...
Fabio

Recommended JVM Parameters for Master and ClientManager (v 6.1.0)

What are the recommened JVM parameters for a master and client manager running on the same Linux machine?
Current VM Specs:
OS: Suse Linux
Processor Count: 4
Physical Memory: 8GB
Using Java: jdk1.6.0_13
Current Master Params: JVMARGS=-Xms2048m -Xmx2048m
Current Client Manager Params: JVMARGS=-Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m
Recommendations would be appreciated.
Thanks!
Grant Alexander

What are the recommened JVM parameters for a master and client manager running on the same Linux machine?
Current VM Specs:
OS: Suse Linux
Processor Count: 4
Physical Memory: 8GB
Using Java: jdk1.6.0_13
Current Master Params: JVMARGS=-Xms2048m -Xmx2048m
Current Client Manager Params: JVMARGS=-Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m
Recommendations would be appreciated.
Thanks!
Grant Alexander

Where to find docs for JVM parameters for JDK 1.4?

Can somebody tell me where to find a complete documentation for JVM parameters for jdk 1.4?
Thanks in advance

Start here:
Performance Documentation for the Java HotSpot VM
http://java.sun.com/docs/hotspot/
One of this documents you will find there is:
JavaTM HotSpot VM Options
http://java.sun.com/docs/hotspot/VMOptions.html
Hope this helps.

JVM parameters from Executable JAR

Is it possible to utilize JVM parameters when running an executable JAR?
I have an application that process a large amount of data. If I run the application from the command prompt I can use the JVM directive -mx512M to allocate 512MB of memory to the JVM.
Is there a way of doing the same thing when using an executable JAR?

In which way are you running a jar without a batch file?
If you want to make a Java App run with launching according to the operating system's style, unzip JAVA_HOME/src.zip and study the java.exe c source code. Start your own custom java.exe changing its name to yourapp.exe. You can then adorn it with all the things expected on a given operating system.

Monitoring JVM Parameters

Hi All,
Is there a ways to monitor/change JVM parameters at runtime?
Example
If I pass a custom jvm parameter in the following way:
java -Dmy.custom.argument=myvalue -jar Stylepad.jarIs there a way to monitor this argument (-Dmy.custom.argument=myvalue) at runtime with both read and write permissions?
As far as I know the platform management mbeans only allows us to view such jvm parameters in read only mode (via java.lang.Runtime MBean).
Could any one help me to solve this problem?
Thanks in Advance!
Jini

Hi,
You could write your own MBean to do so.
However you should be careful about security: if your MBean allows to change just
any System property and isn't protected then you would be creating a security hole.
There's also a second consideration, which is that changing the value of a System
property at runtime might have no effect: it would mostly depends on how the code
that depends on that System property uses it.
Most applications will read their property only once, at initialization time. Changing
a property after such an application has performed its initialization phase has usually
no effect on that application.
On a pure conceptual/general level I would be tempted to qualify what you are
asking for as 'fragile' (best case) or 'dangerous' (worst case).
If however you still want to proceed in this direction you may be interested by this
blog entry:
http://weblogs.java.net/blog/emcmanus/archive/2006/11/a_real_example.html
It isn't exactly what you are asking for but it may help you on your way.
Hope this helps,
-- daniel
JMX, SNMP, Java, etc...
http://blogs.sun.com/jmxetc

JVM Parameters in Applets

Hi,
I need to set the jvm parameter in an applet for instance "file.encoding" and
System.setProperty("file.encoding","UTF8") doesnt work, is there any other way to set the parameters?
Thanks in advance...

System.setProperty("file.encoding","UTF8")
Will throw an exception because the applet is not allowed to do that
java.security.AccessControlException: access denied (java.util.PropertyPermission file.encoding write)
You need to sign the applet and the consumer of your applet needs to trust the signature
or the consumer of your applet needs to set up a policy for your applet.
Or
The consumer of your applet sets up runtime parameters.
Here is something I copied and pasted to pass parameters that will force the jre to
generate a full trace everytime.
To turn the full trace on (windows) you can start the java console, to be found here:
C:\Program Files\Java\j2re1.4...\bin\jpicpl32.exe
In the advanced tab you can fill in something for runtime parameters fill in this:
-Djavaplugin.trace=true -Djavaplugin.trace.option=basic|net|security|ext|liveconnect
if you cannot start the java console check here:
C:\Documents and Settings\userName\Application Data\Sun\Java\Deployment\deployment.properties
I think for linux this is somewhere in youruserdir/java (hidden directory)
add or change the following line:
javaplugin.jre.params=-Djavaplugin.trace\=true -Djavaplugin.trace.option\=basic|net|security|ext|liveconnect
for 1.5:
deployment.javapi.jre.1.5.0.args=-Djavaplugin.trace\=true -Djavaplugin.trace.option\=basic|net|security|ext|liveconnect
The trace is here:
C:\Documents and Settings\your user\Application Data\Sun\Java\Deployment\log\plugin...log
I think for linux this is somewhere in youruserdir/java (hidden directory)
I think the main question is why do you need to set this property? If you want to write
something to the local filesystem you should sign or set up policy for the applet
anyway so I would go with that sollution. Or better yet use an URL object and send the
data that needs to be saved to a server that does something with it (store it in
a database).

JVM multithreading parameters

Could you please tell me if there are JVM parameters to determine number of threads when JVM is starting up?
thanks so much

Your code must start threads. See http://java.sun.com/docs/books/tutorial/essential/concurrency/index.html

How to give jar at runtime as JVM parameter in Config tool

Hi
I am executing java spring based webservice on WS navigator CE7.1 . I am getting the follwing error. To avoid this i have to provide the spring-agent.jar at runtime to the javm , I tried to configure the Configtool jvm parameters as specified in the sap help.
Is is possible to give the jar as JVM param via config tool.
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
 <ns2:po1ProcessingResponse xmlns:ns2="http://metering.com/greams/flowmanagement/inbound/">
 <return status="TECHNICAL_ERROR">
 <technicalErrors>
 <code>TECHNICAL_ERROR</code>
 <description>org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.context.weaving.AspectJWeavingEnabler#0': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'loadTimeWeaver': Initialization of bean failed; nested exception is java.lang.IllegalStateException: ClassLoader [com.sap.engine.boot.loader.ResourceMultiParentClassLoader] does NOT provide an 'addTransformer(ClassFileTransformer)' method. Specify a custom LoadTimeWeaver or start your Java virtual machine with Spring's agent: -javaagent:spring-agent.jar</description>
 <additionalInformation>org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.context.weaving.AspectJWeavingEnabler#0': Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'loadTimeWeaver': Initialization of bean failed; nested exception is java.lang.IllegalStateException: ClassLoader [com.sap.engine.boot.loader.ResourceMultiParentClassLoader] does NOT provide an 'addTransformer(ClassFileTransformer)' method. Specify a custom LoadTimeWeaver or start your Java virtual machine with Spring's agent: -javaagent:spring-agent.jar</additionalInformation>
 <responseMessageCode>TECHNICAL_ERROR</responseMessageCode>
 </technicalErrors>
 </return>
 </ns2:po1ProcessingResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Have you checked note 1363755 - Integration of third party zipping library with 6.40 Engine
It might be helpful for for your issue..
Or check parameter -Xrun<library>[:options] load native agent library
Kind regards,
Mark
Edited by: M. Dijsselbloem on Apr 8, 2010 3:02 PM

Siginficance of max heap size mentioned in configtool

Hi all,
could anyone please tell me the exact significance of
max heap size mentioned in configtool in SAP Netweaver in
1)Instance_ID
-servers general
-message servers and bootstrap
2)Dispatcher_ID
-general
-bootstrap
3)Server_ID
-general
-bootstrap
Which of these do i change to improve the performance?
I tried changing the max heap size specified in
Server_ID
-general
but i got the following error while trying to start the server in std_server0.out:
node name : server0
pid : 3452
system name : N02
system nr. : 01
started at : Tue Mar 20 21:53:37 2007
Reserved 1610612736 (0x60000000) bytes before loading DLLs.
[Thr 1912] MtxInit: -2 0 0
Error occurred during initialization of VM
Could not reserve enough space for object heap
Regards,
Namrata.

Hi,
The biggest impact to runtime performance will be adjusting the heap size of the server JVM. This is done in Server_ID->general. The JVM parameters entered here take precedence over parameters in Instance_ID->servers general. The server job by far do the most work in the Java engine and so it is very important that the JVM for the server node is tuned to handle the workload. Tuning the server JVM or even adding additional server nodes is dependent on the workload and the amount of work on the system.
Adjusting the heap for the other JVMs will have much less of an impact than adjusting the heap in the server JVM.
The dispatcher JVM heap settings may have a slight impact during runtime, but compared to the server jobs the dispatcher does relatively little work. Depending on your situation you may need to tune the dispatcher a little, but my experience has been that the default value for the dispatcher is usually sufficient.
The values for all of the bootstrap jobs may have an impact on startup time, but they will have no impact on runtime since these jobs go away once the system is up. From what I have seen the defaults values for the bootstrap jobs are sufficent.
I never adjust anything under Instance_ID, I'm not sure what these parameters are used for except for maybe default values when adding server nodes. Maybe someone out there knows.
Hope this helps.
Regards,
Kolby

Checking JVM settings on Unix level..

hi all,
I am in a situation where unable to open config tool because SecStore.properties file is missing in our solaris server..
can anybody explain me how can i check the JVM parameters from the os level on solaris 10..( or any other possible options )
would appreciate your help and rewarded.
Thanks!
Addy

Hello ,
Can you please specify whether your system in ABAP+JAVA or JAVA only.
so based on that you can locate the files in
for ABAP+JAVA
/usr/sap/<SID>/DVEMGS<inst. NR.>/j2ee/cluster/server/cmdline.properties and /configtool/service.ini
or
JAVA only
in /usr/sap/<SID>/JC<inst Nr.>/j2ee/cluster/server/cmdline.properties
Regards,
Ramkrishna

Kernell parameters of Java stack

Hi,
I´ve installed an abap and java stacks. In the post-installation guide, explains that we should change some kernell parameters (146289 and 835474), but this steps I´ve done in the abap stack but in the java stack i don´t know how to check the parameters.
How can i do this?
Or in the kernell config of java stack is the step JVM Settings?
More thanks

Hi,
With the Java system you don't have to worry about kernel parameters, the jvm parameters are important though and note 723909 is valid for your system as mentioned earlier. These parameters get set at installation, its worth just double checking them via the configtool (particulary the memory parameters). Note 723909 covers sun/oracle and HP-UX jvms, if you use an IBM jdk note 1024539 has the recommended parameters.
Kind regards,
Cathal

Slow starup of Java application - best practices for fine tuning JVM?

We are having problems with a java application, which takes a long time to startup.
In order to understand our question we better start with some background info. You will find the question(s) after that.
Background:
The setup is as follows:
In a client-server solution we have a win xp, fat client running java 1.6.0.18.
(Sun JRE). The fat client containt a lot of GUI, and connects to a server for DB access. Client machines are typical 1 to 3 years old (there are problems even on brand new machines). They have the client version of JRE - standard edition installed (Java SE 6 update 10 or better) Pretty much usual stuff so far.
We have done a lot of profiling on the client code, and yes we have found parts of our own Java code that needs improving. we are all over this. Server side seems ok with good response times. So far, we havent found anything about shaky net connections or endless loops in the java client code or similiar.
Still, things are not good. Starting the application takes a long time. too long.
There are many complicating factors, but here is what we think we have observed:
There is a problem with cold vs. varm starts of the application. Apparently, after a reboot of the client PC - things are really, really bad - and it takes (sometimes) up to 30-40 secs to start the application (until we arrive at the start GUI in our app).
If we run our application, close it down, and then restart
without rebooting, things are a lot better. It then usually takes
something like 15 - 20 sec. which is "acceptable". Not good, but acceptable,
Any ideas why?
I have googled it, and some links seems to suggest that the reason could be disk cache. Where vital jar are already in disk cache on th warm start? Does that make any sense? Virus scanners presumable runs in both cases.
People still think that 15 - 20 sec in start up on the warm start is an awful long time, even though there is a lot, a lot, of functionality in the application.
We got a suggestion to use IBMs JRE - as it can do some tricks (not sure what) our SUN JRE cant do concerning the warm and cold start problem. But thats is not an option for us. And noone has come up with any really good suggestions with the SUN JRE so far?
On the Java Quick Starter (JQS) -
improves initial startup time for most java applets and applications.
Which might be helpful? People on the internet seem more interested
in uninstalling the thing than actually installing it though?
And it seems very proprietary, where we cant give our Jar files to it?
We could obviously try to "hide" the problem in some way and make it "seem" quicker. Where perceived performance can be just as good as actual performance. But it does seem a bad solution. So for the cold start we will probably try reading the jar files and thereby have them in disk cache before startup of our application. And see if that helps us.
Still, ok the cold start is the real killer, but warm start isn't exactly wonderfull either.
People have suggested that we read more on the JVM and performance.
java.sun.com.javase/technologies/performance.jsp
java.sun.com.docs/hotspot/gc5.0/gc_tuning_5.html
the use of JVM flags "-Xms" "-Xmx" etc etc.
And here comes the question .. da da ...
Concerning various suggested reading material.
it is very much appreciated - but we will like to ask people here - if it is possibe to get more specific pointers. to where the gold might be buried.
I.e. in a an ideal world we would have time to read and understand all of these documents in depth. However, in this less than ideal world we are also doing a lot of very timeconsuming profiling in our own java code.
E.g. java garbage collection is is a huge subject - and JVm settings also. Sure, in the end we will probably have to do this all very thoroughly. But for now we are hoping for some heuristics on what other people are doing when facing a problem like ours..?
Young generation, large memory pages, garbage collection threads ect. all sounds interesting - but what would you start with?
If you don't have info to decide - what kind of profiling would you be running and then adjust what JVM setting in your trials?
In this pressed for time scenario. Ignorance is not bliss. But makes it hard to pinpoint the or those JVM parameters to adjust. So some good pointers from experienced JVM "configurators" will be much appreciated!
Actually, If we can establish that finetuning of these parameters is a good idea, it will certainly also be much easier to allocate the time for doing so. - reading, experimenting etc. in our project.
So, All in all , what kinds of performance improvements can we hope for? 5 out of 20 secs on the warm start? Or is it 10 % nitpicking? Whats the ball park figure for what we can hope to achieve here given our setup? What do you think based on above?
Maybe someone out there have done some finetuning of JVM parameters in a similiar PC environments like, with similiar fat clients...? Finetuning so and so - gave 5 secs. So start your work with these one-two parameters?
Something like that - some best practices? Thats what we are hoping for.
best wishes
-Simon

Thanks for helpful answer from both you and kajbj.
The app doesn't use shared network drives.
What are you doing between main starts to get executed and the UI is
displayed?
Basicly, Calculating what to show in the UI. Accessing server - not so much, there are some reads from a cache, but the profiling doesnt indicate that it should be a problem. Sure, I could shift the startup time to some other slot, but sofar I havent found a place where the end-user wouldnt be annoyed.> Caching of something would seem most obvious. Normal VM stuff >seems unlikely. With profiling i basicly find that ''everything'' takes a lot longer in the cold start scenario. Some of our local java methods are going to be rewritten following our review. But what else can be tuned?You guys dont think the Java Quick Start approach, with more jars in disk cache will give something? And how should that be done/ what does people do?I.e. For the class loader I read something about
1.Bootstrap class loader
2.Extensions class loader
3.System class loader
and is wondering if this has something to do with the cold start problem?
The extensions class loader loads the code in the extensions directories (<JAVA_HOME>/lib/ext
So, we should move app classes to ext? Put them in one jar file? (We have many). Best practice about that?
Otherwise it seems to me that it must be about finetuning the JVM?
I imagine that it is a question about:
1. the right heap size
2. the right garbage collection scheme
Googling heap size for XP
CHE22 writes:
You are right; -Xms1600M works well, but -Xms1700M bombs
Thats one best practice or what?
On garbage collection, there are numerous posts, and much "masters of Java black art" IMHO, And according to profiling GC is not really that much of a problem anyway? Still,
Based on my description I was hoping for a short reply like "try setting these two parameters on your xp box, it worked for me" ...or something like that. With no takers on that one, I fear people are saying that there is nothing to be gained there?
we read:
[ -Xmx3800m -Xms3800m
Configures a large Java heap to take advantage of the large memory system.
-Xmn2g
Configures a large heap for the young generation (which can be collected in parallel), again taking advantage of the large memory system. It helps prevent short lived objects from being prematurely promoted to the old generation, where garbage collection is more expensive.
Unless you have problems with pauses, try granting as much memory as possible to the virtual machine. The default size (64MB) is often too small.
Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice.
The -XX:+AggressiveHeap+ option inspects the machine resources (size of memory and number of processors) and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs]
So is Setting -Xms and -Xmx and -XX:AggressiveHeap
best practice? What kind of performance improvement should we expect?
Concerning JIT:
I read this one
[the impact of the JIT compiler is obvious on the graph: at startup the time taken is around 500us for the first few values, then quickly drops to 130us, before falling again to 70us, where it stays for 30 minutes,
for this specific issue, I greatly improved my performances by configuring another VM argument: I set -XX:CompileThreshold=50]
The size of the cache can be changed with
-Xmaxjitcodesize
This sounds like you should do something with JIT args, but reading
// We disable the JIT during toolkit initialization. This
// tends to touch lots of classes that aren't needed again
// later and therefore JITing is counter-productiive.
java.lang.Compiler.disable();
However, finding
the sweet spots for compilation thresholds has been tricky, so we're
still experimenting with the recompilation policy. Work on it
continues.
sounds like there is no such straigth forward path, it all depends...
Ok, its good, when
[Small methods that can be more easily analyzed, optimized, and inlined where necessary (and not inlined where not necessary). Clearly delineated uses of data so that usage patterns and lifetimes are apparent. ]
but when I read this:
[The virtual machine is responsible for byte code execution, storage allocation, thread synchronization, etc. Running with the virtual machine are native code libraries that handle input and output through the operating system, especially graphics operations through the window system. Programs that spend significant portions of their time in those native code libraries will not see their performance on HotSpot improved as much as programs that spend most of their time executing byte codes.]
I have the feeling that we might not able to improve performance that way?
Any comments?
otherwise i was wondering about
-XX:CompileThreshold=50 -Xmaxjitcodesize (large, how large?)
Somehow, we still feel that someone out there should have experienced similiar problems? But obviously there is no guarantee that the someone should surf by here!
In c++ we used to just write everything ourselves. Here it does seem to be a question about the right use of other peoples stuff?
Where you are kind of hoping for a shortcut, so you dont have to read endless number of documents, but can find a short document that actually addresses your problem ... well.
-Simon
Edited by: simoncpm on Mar 15, 2010 3:43 PM
Edited by: simoncpm on Mar 15, 2010 3:53 PM

JVM Parameters in Configtool

Similar Messages

Maybe you are looking for