|
| |
| Sun Java System Application Server Enterprise Edition 7 2004Q2 System Deployment Guide | |
Appendix A
Checklist for DeploymentThis appendix provides a checklist to get started on the evaluation and production with Sun Java System Application Server 7 2004Q2.
Table 0-1 Checklist
Component/Feature
Description
Application
Determine the following requirements for the application to be deployed.
1. The required/acceptable response time.
2. Peak load characteristics.
3. Necessary persistence scope and frequency.
4. Session timeout in web.xml.
5. The failover and availability requirements.
For more information on planning for your requirements, see Chapter 2, "Planning your Environment" and “About Application Server Performance” in Sun Java System Application Server 7 Performance and Tuning Guide.
Hardware
Determine the following hardware requirements for deploying the application:
1. The same type of hardware should be used to host HADB nodes.
2. Have necessary amounts of hard disk space and memory installed.
3. Use the sizing exercise to identify the requirements for your deployment.
For detailed information on the minimum system requirements, see Sun Java System Application Server 7 Release Notes at the product documentation web site at http://docs.sun.com/db/prod/s1appsrv#hic
Operating System
1. Ensure that the product is being installed on a supported platform.
2. Ensure that the patch levels are up-to-date and accurate.
For more information on the supported platforms, see Sun Java System Application Server 7 Release Notes at the product documentation web site at http://docs.sun.com/db/prod/s1appsrv#hic
Network Infrastructure
1. Identify single points of failures and address them.
2. Make sure that the NIC cards and other network components are correctly configured.
3. Run ttcp benchmark test to determine if the throughput meets the requirements/expected result.
4. Setup rsh/ssh based on your preference so that HADB nodes can be installed.
For more information on the required network infrastructure, setting up rsh/ssh, see Sun Java System Application Server 7 Installation Guide.
Back-ends and other external datasources
Check with your domain expert/vendor to ensure that these datasources are configured appropriately.
System Changes/Configuration
1. Make sure that changes to /etc/system and its equivalent on Linux are completed before running any performance/stress tests.
2. Make sure you have completed changes to TCP/IP settings.
3. By default, the system comes with lots of services pre-configured. Not all of them are required to be running. Turning off services that you do not need and thereby conserve system resources.
4. On Solaris, use Setoolkit to determine the behavior of the system. Resolve any flags that show up.
For more information on optimum system configuration, see “About Application Server Performance” in Sun Java System Application Server 7 Performance and Tuning Guide.
Application Server and HADB Installation
1. Ensure that these servers are not installed on NFS mounted volumes.
2. Check for enough disk space and RAM when installing both Application Server and the HADB nodes on the same machine.
3. Check for enough independent disks when installing multiple HADB nodes on the same system.
For more information on installing the Application Server and the HADB, see Sun Java System Application Server 7 Installation Guide.
HADB Configuration
1. Set the size of the HADB Data Device.
2. Define the DataBufferPoolSize.
3. Define the LogBufferSize.
4. Define the InternalBufferSize.
5. Set the NumberOfLocks.
6. Set optimum time-out values for various Application Server components.
7. Create the Physical layout of HADB nodes on the filesystem.
For more information on installing the HADB, see chapter on “Preparing for HADB Setup” in Sun Java System Application Server Installation Guide.
For more information on tuning the HADB, see chapter on “Tuning for High-Availability” in Sun Java System Application Server Performance and Tuning Guide.
Application Server Configuration
1. If sso is not required, then it can be turned off via <sso-enabled = false /> property in server.xml configuration file.
2. Similarly, if MDB are not being used, then jms-service can be turned off.
3. Logging: Enable access log rotation.
4. Choose the right logging level, WARNING would be appropriate most of the times.
5. Configure J2EE containers using Admin Console.
6. Configure HTTP listeners using Admin Console.
7. Configure ORB threadpool using Admin Console.
8. If the application to be deployed has EJB's, then ensure that the UtilDelegate flag is used. For information on using this flag, see “Enabling the High Performance CORBA Util Delegate,” in Sun Java System Application Server Performance and Tuning Guide.
9. If using Type2 Drivers or calls involving native code, ensure that mtmalloc.so is specified in the LD_LIBRARY_PATH.
10. Consider disabling server.policy file if performance is critical.
11. Ensure that the appropriate persistence scope and frequency are used and they are not overridden underneath in the individual Web/EJB modules.
12. Ensure that only critical methods in the SFSB are checkpointed.
For more information on tuning Application Server settings, see Sun Java System Application Server 7 Performance and Tuning Guide.
For more information on configuring various Application Server components and services, see Sun Java System Application Server 7 Administration Guide.
Load balancer Configuration
1. Make sure you have installed the Web Server.
2. Make sure you have installed the load balancer plug-in. For more information on installing load balancer plug-in, see chapter, “Installing Standard and Enterprise Edition Software” in Sun Java System Application Server 7 Installation Guide.
3. Ensure to turn off unnecessary functions.
4. Make sure you have disabled patch checks.
5. Make sure you have configured RqThrottle, KeepAliveQuery* parameters. Lower the KeepAliveQuery* values; lower the value, latency will be lower on lightly loaded systems. Higher the values, higher will be the throughput on highly loaded systems.
6. Make sure you have enabled and configured perfdump in instancename-obj.conf file.
For more information on load balancer configuration, see chapter “Configuring HTTP Load Balancing and Failover” in Sun Java System Application Server 7 Administration Guide.
JVM Configuration
1. At a minimum, specify the minimum and maximum heap sizes to be the same, and equal to one GB for each instance.
2. Refer to documentation on http://java.sun.com for configurable options in Java Hotspot JVM.
3. When running multiple instances of Application Server, consider creating a processor set and bind the Application Server to it. This helps in cases where the CMS collector is used to sweep the old generation.
Configuring time-outs in Load balancer
1. Response-time-out-in-seconds: Determines how much time the load balancer will wait before declaring an Application Server instance as unhealthy. This value needs to be set based on the response time characteristics of your application. If this value is too high, then the Web Server/Load balancer plug-in is going to wait for a long time before marking that Application Server instance as unhealthy. If the value for Response-time-out-in-seconds is set too low and if the Application Server’s response time crosses this threshold, the instance will be incorrectly marked as unhealthy.
2. Interval-in-seconds: Specifies the time interval in seconds after which unhealthy instances will be checked to find out if they have returned to a healthy state. Too low a value will generate extra traffic from the load balancer plug-in to Application Server instances and too high a value will delay the routing of requests to the instance that has turned healthy.
3. Timeout-in-seconds: Specifies the duration for a response to be obtained for a health check request. This value needs to be adjusted based on the traffic among the systems in the cluster to ensure that the health check succeeds.
For more information on these load balancer configuration parameters, see chapter, “Configuring HTTP Load Balancing and Failover” in Sun Java System Application Server 7 Administration Guide.
Configuring time-outs in Application Server
1. Max-wait-time-millis: Defines the wait time to get a connection from the pool before throwing an exception. Default is 60000 milli seconds. Consider changing this value in case of highly loaded systems where the size of the data being persisted is greater than 50 Kb.
2. Cache-idle-timeout-in-seconds: Applies to entity beans and stateful session beans. Defines the time the bean is allowed to be idle in the cache before it gets passivated.
3. Removal-timeout-in-seconds: The amount of time that the bean remains passivated, that is, idle in the backup store, is controlled by removal-timeout-in-seconds parameter. The default value is 60 minutes. This value needs to be adjusted based on the need for SFSB failover.
4. All of these values should be set by paying attention to the HADB’s JDBC connection pool setting max-wait-time-in-millis.
For more information on tuning the timeout parameters, see chapter, “Tuning the Application Server” in Sun Java System Application Server 7 Performance and Tuning Guide.
HADB time-outs
1. sql_client_timeout: This variable controls the wait time of SQLSUB for an idle client. For example, a client which has logged on, sends some requests, and then waits for user input. A client that has been idle for more than 30 minutes is assumed to be dead, and the session is terminated. Setting the value too low may cause SQL sessions to be aborted prematurely, while setting it too high may cause SQL sessions that are not idle, but has exited, to occupy resources. This in turn may prevent other SQL clients from logging on. When tuning this variable also consider the settings of “nsessions.” The default value is 1800 seconds and it can be changed by editing the configuration file. If the HADB JDBC connection pool steady-pool-size is greater than(>) max-pool-size, then idle-timeout-in-seconds should be set lower than the sql_client_timeout, so that the Application Server itself will close the connection before HADB closes the connection.
2. lock_timeout: Specifies the maximum time a transaction waits for access to data. When this time is exceeded, the transaction generates the error message: ”The transaction timed out.” Such time-outs are caused by transactions waiting for locks held by other transactions (i.e. deadlocks), and causing high server load. The default value is 5000 ms. Do not set this value to below 500 ms. If you see the “transaction timed out” messages in the server log, then it is a good idea to increase this value. The lock timeout value can be set by adding a property to the ha jdbc connection pool as: <property name=lockTimeout value=”x” /> where x is in milliseconds.
3. Querytimeout: This is the maximum time in milliseconds that the HADB waits for a query to execute. The default value is 30 seconds. If you see exceptions in the server log consistently indicating the query time out, you should consider increasing this value. This value can be set by adding a property to the ha jdbc connection pool as: <property name=QueryTimeout value=”x” /> where x is in milliseconds.
4. loginTimeout: This is the maximum time that the client waits to login to the HADB. This can be set by adding a property to the ha jdbc connection pool as: <property name=loginTimeout value=”x” /> where x is in seconds. Default value is 10sec.
5. MaxTransIdle: The maximum time a transaction can be idle (msec) between sending a reply to the client and receiving the next request. The default value is 40sec. This can be changed by adding a property to the ha jdbc connection pool as: <property name=maxtransIdle value=”x” /> where x is in milliseconds.
For more information on these timeout parameters, see chapter, “Tuning for High-Availability” in Sun Java System Application Server 7 Performance and Tuning Guide.
Implications of GC in Application Server, Enterprise Edition
GC pauses if they are long enough, that is greater than or equal to (>=) 4sec, which can cause intermittent problems in persisting session state into HADB. To avoid this problem, It is recommended to tune the vm heap. In cases where even a single failure to persist data is not acceptable and also in cases where the system is not fully loaded, using CMS collector can help. Other option is to use the throughput collector.
These can be enabled by adding:
<jvm-options>-XX:+UseConcMarkSweepGC</jvm-options>
<jvm-options> -XX:SoftRefLRUPolicyMSPerMB=1</jvm-options>
Note that with the use of this option, you might experience a drop in throughput.
For any late-breaking updates to the GC parameters, see Sun Java System Application Server 7 Release Notes at the product documentation web site at http://docs.sun.com/db/prod/s1appsrv#hic
Common documents that can help
1. JVM options: http://java.sun.com/docs/hotspot/gc1.4.2/index.html
The following documents are available at http://docs.sun.com/db/prod/s1appsrv#hic
1. Sun Java System Application Server 7 Installation Guide
2. Sun Java System Application Server 7 System Deployment Guide
3. Sun Java System Application Server 7 System Performance and Tuning Guide
4. Sun Java System Application Server 7 Error Messages Guide
5. Sun Java System Application Server 7 Release Notes