These settings tune the Java virtual machine (JVM) that runs Java code in the server. These settings have a large effect on applications that are implemented with Java, EJB, or Web components. Since many of the server internal components are implemented in Java, these settings have some effect on applications that are implemented in other languages such as PowerBuilder.
Check the CLASSPATH and BOOTCLASSPATH for the server to ensure that they does not include unnecessary entries. You can check the runtime values on the General tab in the EAServer Manager Server Properties dialog box.
The server start scripts assemble the CLASSPATH from the required files in the EAServer installation and existing settings from your environment. The scripts then set BOOTCLASSPATH to include the CLASSPATH settings.
You can set these variables in the bin\user_setenv.bat file (for Windows platforms) or bin/user_setenv.sh script (for UNIX platforms). Create the file if it does not already exist. If you require no additional CLASSPATH or BOOTCLASSPATH entries, unset these variables. Otherwise, set them to include the minimum required settings.
You can also configure the server class path by modifying the following server properties, using the advanced tab in the EAServer Manager server properties dialog box:
com.sybase.jaguar.server.jvm.classpath to configure the CLASSPATH setting.
com.sybase.jaguar.server.jvm.classpath.jars to specify JAR files in the java/lib directory to add to the CLASSPATH setting.
com.sybase.jaguar.server.jvm.bootclasspath to configure the BOOTCLASSPATH setting.
com.sybase.jaguar.server.jvm.bootclasspath.jars to specify JAR files in the java/lib directory to add to the BOOTCLASSPATH setting.
For syntax information, see the reference pages in Appendix B, “Repository Properties Reference,” in the EAServer System Administration Guide.
EAServer uses custom Java class loaders to allow refreshing the Web application classes and Java components, and to load classes from directories and JAR files that are not specified in the CLASSPATH environment variable. During the development cycle, this feature allows you to add or modify classes without restarting the server. However, duplicate in the custom class list for different components can waste memory by loading duplicate class instances. Chapter 30, “Configuring Custom Java Class Lists,” in the EAServer Programmer’s Guide describes how to configure common class lists for components and Web applications.
Minimize Refresh in production servers
Refreshing components loads additional copies of all implementation
classes. EAServer leaves the previous implementation in memory for
use by existing client sessions. For this reason, it is best to
restart your production server after deploying a large number of
new implementation classes, ensuring that the memory required to
load new classes is not reallocated.
EAServer supports several JDK versions, and each JDK version can support multiple VM types such as Server Hotspot, Client Hotspot, and Classic. You specify the JDK version and VM type when starting the server from the command line, or for servers that run as Windows services, with the command that you run to install the service. For details, see “Starting the server” in the EAServer System Administration Guide.
As a general rule, you should use the Server Hotspot VM in the latest supported JDK version. However, always consult the EAServer Release Bulletin for your platform for updated recommendations.
For more information on Java Hotspot technology, see the Sun Microsystems white paper Java HotSpot Performance Engine Architecture.
The Java just-in-time (JIT) compiler converts Java bytecode
into native machine code, which can run much faster than the interpreted
bytecode. You should enable the JIT compiler for the server, unless
advised not to in the EAServer Release Bulletin for
your platform. You can set the property on the Java
VM tab in the EAServer Manager server properties dialog box,
or by using jagtool to set server property com.sybase.jaguar.server.jvm.nojit to false.
The Java virtual machine uses its heap storage for dynamic allocation memory. In addition, each thread requires reserved memory for the stack used to pass method parameters. You can tune the memory used by setting these properties of the EAServer Manager Server Properties dialog box, or by using jagtool. To set these properties, use the syntax documented in their reference pages in Appendix B, “Repository Properties Reference,” in the EAServer System Administration Guide:
com.sybase.jaguar.server.jvm.maxHeapSize specifies the maximum heap size. The JVM reserves this much memory at start-up. The memory used for object allocation cannot exceed this amount. If the heap size is exceeded, you see request failures accompanied by java.lang.OutOfMemoryError errors in the error log.
com.sybase.jaguar.server.jvm.minHeapSize specifies the minimum, or initial heap size. While the maximum size is reserved at start-up, only the minimum size is monitored and allocated from by the JVM. Set this value to the same size as the maximum heap size. The maximum heap size is reserved at server start-up regardless of the minimum size, and using equal sizes avoids the CPU overhead of dynamically growing the heap.
com.sybase.jaguar.server.jvm.options configures
additional start-up options for the Java VM. The -XssStackSize parameter
can be tuned to configure the stack size for Java threads. StackSize is
the amount of virtual memory reserved for the stack of each Java
thread.
Optionally set com.sybase.jaguar.server.jvm.verboseGC to true to enable trace output from the Java garbage collector. The trace output describes how often the garbage collector runs, how long it takes, and what objects are deallocated. For information on the encoding of the output, see the documentation for the JDK version that you are running the server with.
The optimum heap size depends on your application and machine configuration. To tune the value, first verify that you have removed any memory leaks from your own code. Then test under expected peak load conditions to determine the minimum size that allows the application to run without errors. If the heap size is too large, it uses memory that could otherwise be used for the call stack required to run each thread. Large heap sizes can also incur a larger delay when the Java garbage collector runs. Never set the heap size larger than the machine’s physical memory; if you do, the system will swap memory to disk. Set the minimum and maximum sizes to equal values, using the syntax described in the reference pages for these properties in the EAServer System Administration Guide, Appendix B, “Repository Properties Reference.”
Set the Java thread stack size to the smallest value that still allows the application to run. Usual values are 256K or 512K for the applications used for internal stress testing at Sybase. Most applications should never require more than 1Mb. The stack must be large enough to accommodate parameters passed in component dispatcher and intercomponent calls. However, if the value is too high, it limits the maximum number of threads that can be spawned. To run N threads, there must at least N x StackSize of free memory available.
You can configure additional Java VM options by adding them to the options set in the server property com.sybase.jaguar.server.jvm.options, set on the Advanced tab in the EAServer Manager Server Properties dialog box or using jagtool. Use the syntax described in the com.sybase.jaguar.server.jvm.options reference page in the EAServer System Administration Guide, Appendix B, “Repository Properties Reference.”
To verify the Java VM options, set the server property com.sybase.jaguar.server.jvm.displayOptions to true, then restart the server. The server logs all the options at start-up, including those that are configured by dedicated properties such as the Heap Size settings discussed above.
| Copyright © 2005. Sybase Inc. All rights reserved. |
|
|