WebSphere Performance Settings and daily maintenance (reprint)

First, confirm whether disk space meets the requirements
1, the WebSphere application server's own code occupies space. This space is generally around 1G, with a slight difference on different system platforms.
2. The space occupied by the profile. There are 3 basic types of profiles created by WebSphere Application Server V6.1, with each profile occupying the following space: Application Server (Application Server): When installing a sample program is not selected in the WebSphere Application Server installation This profile occupies approximately 200m;deployment manager:30m of disk space; custom profile (custom, node agent): 10M.
3. If you are installing a Web server, reserve the disk space occupied by the Web server on the server where the Web server resides. IBM HTTP servers typically occupy about 110M of space.
4. If you install a Web server, you will typically install the Web server plug-in component on the same machine as the Web servers, which takes up about 200M of disk space.
5. The usage space of WebSphere Application Server system log. The estimation of log space should be combined with the system configuration of logs. The primary log for WebSphere Application server is Systemout.log,systemerr.log. We can set the size of the log file and the number of saved history log files, thus estimating the space needed.
6, if you have a Web server, you need to consider the Web server log space. If the customer opens the Web server's access log access.log (which is turned on by default), the log grows very fast and reserves enough space.
7. The space required for backup files. The WebSphere Application Server provides a backup command (BACKUPCONFIG.BAT/SH) to back up the application server's configuration and its application. We recommend that you back up your system as soon as it is stable. For a typical production system, the WebSphere Application server configuration file often exceeds 100M. When issuing the Backupconfig command, use the-logfile parameter to specify where the backup file will be stored.
8, system error time log, for example, the JVM in the event of OutOfMemory, on most platforms the WebSphere Application server will default to write Javacore files and heapdump files, log the JVM Heap when the error occurs, the thread condition, in case of error diagnosis use. Although you can adjust the application server parameters so that they do not produce such files, it is often necessary to start with such files in order to analyze the problem. Such files are usually particularly large, such as heapdump files, which can reach hundreds of M. If Outofmemroy occurs more than once, the disk space is occupied very quickly. Therefore, you must consider reserving disk space for this type of file.
9. The was installer also needs to have more than 100M of free space in the system's TEMP directory/tmp.
10. The user publishes to all applications on the WebSphere application server and the application log footprint of the app itself. This size is related to the actual application and can vary widely.
Two performance settings
1. The Java Virtual machine heap size (JVM heap size): Controls the heap size that the JVM code can use, in units of M. This parameter is set in the server-by-application server > process definition >java virtual machine. JVM maximum heap size by default is 256M, in the production environment is usually based on the physical memory of the machine, the application run characteristics to set, and in most cases, this parameter is adjusted. Based on experience, when memory is sufficient, the usual adjustments are between 500M and 1024M. It is important to note that the maximum recommended JVM heap is not more than 1024M, and if the JVM heap size is too large, it may cause memory paging or cause the JVM garbage collection to take too long to affect application server performance. Refer to tuning JVM parameters for specific information on Java Virtual Machine tuning.
2. Web container thread pool: This parameter is set in Webcontainer, Server > Application server > Server1 > Thread pool, and the default value is 10 to 50. If the hardware resources allow, the maximum size of the thread pool is usually tuned to 100.
3. Data source Connection pool: This parameter is set in the resource->jdbc-> data source name, select connection pool settings, and the default size is 1 to 10. Depending on the queue principle of the resource settings, from the Web container thread pool to the data source connection pool parameter settings, it should be from the large to the small pipeline. Before we listed the maximum value of the Web container thread pool setting 100, the maximum value set for the data source connection pool is usually no more than 50. In most cases the adjustment is 30. This parameter value can be modified in the actual run to see if the adjustment has a positive effect on performance. Note that if the maximum size of the database connection pool is too large, the limited resources of the JVM are spent on maintaining the connection pool, processing and database connections, which may result in a decrease in the performance of was.
4. Was process log parameter: Was process log is commonly used with SystemOut.log and SystemErr.log. The default size of these two logs is 1M, and the number of history log files is 1 copies. In a production environment, such settings are usually insufficient to adequately save the error message when a problem occurs. We can save more information by modifying the log default size and the number of history log files. Note that it is not possible to set a single log file size too large (for example, more than 10M), or it may affect the performance of was. In addition, we recommend that you separate the application log from the was log. Server performance can also be affected if the application state log is saved in large numbers in System.out.print or System.err.print.
5. heapdump file: We mentioned earlier that the Heapdump file is very fast on disk space, so you can set the Ibm_heapdump parameter to store the Heapdump file in the specified directory.
6. The access log of the Web server Access.log:IBM HTTP Server access log access.log is open by default, which logs the request information through the HTTP server. In highly concurrent systems, this log grows too much, when logs are too large, may take up too much disk space or cause performance degradation, and if your system does not require this log, or if you have other technical means to save user access information, you can close the log. To do this: Open the IBM Http Server installation directory/conf directory httpd.conf file, search for Customlog, the Customlog line with the # comment out.
Iii. Common daily management tasks
1. View/Change the application server port
? Change the app access port
By default, the administration console and app access for was is two different ports. Access to the management console of was or to the application deployed on was, the port used is determined by the application server port and the virtual host. Suppose we want to change the port from 9080 to 9082 (the actual work, if there is no Web server, some environment would like to turn the application access port into 80, similar method), then proceed as follows: Log in to the was Management console, select the left menu server-Application Server, click Server1, select "Port", click "Wc_defaulthost" (8), modify the port for any port you want (note avoid port conflicts), for example, 9082. Then click "OK". Then "Save".
? Change the was Management console port
Log on to the was Management console, select the left menu server-application server, click Server1 to select "Ports". Then change the wc_adminhost for the management console port that you want. Then click "OK", "save". Select the left menu environment-Virtual host, click on it, then select Admin_host and select "Host Alias". Change the original port 9060 to a port that is consistent with the previous application server/port/wc_adminhost, for example, 9063. or click "New" to create a host alias *, 9063. Then "OK", "save". The goal is to have the port of the application server/port/wc_adminhost out of the host name list of the virtual host/admin_host.
2. Management Security
(1) Enable administrative security
Enabling administrative security activates the settings that are used to prevent unauthorized users from using the server, simply by entering the administrative console, changing the application server configuration, and stopping the application server process these administrative tasks require entering a predefined user name and password to complete. By default, administrative security is enabled when you create profiles (Figure 9). If you did not select Enable administrative security when you created the profile, and you want to enable it later in the process, you can do this as follows:
First enter the console, for example: http://was_ip:9060/admin, note that the user who logged in here must be the user who set up security. For example, admin. Select Security > Security Management, Applications and infrastructure, and then tap the Security Configuration Wizard (Figure 10). For ease of configuration, in specify protection scope, you can not select Use Java 2 security to restrict application access to local resources, accept the default option in Select User Repository, user repository as "federated repository", click "Next", and fill in user name and password in the configuration user repository. If you are enabling administrative security for the first time, enter a new user name (the user name that you logged into the admin console) and password. This user name password is arbitrary and does not require an operating system user because the Federated repository's default user entry is from the file, and if administrative security has been previously enabled using the repository, use the user name and password in the repository that holds administrator privileges. Click "Next", "done". After saving to restart the application server, login to the management console and so on will need to provide your pre-defined username/password.
(2) Deactivate management security
Disabling the admin console is simple, in the page shown in Figure 10, do not select "Enable Admin Security", click "Apply", save and restart the application server. In a special case, if you forget the administrator password, we cannot log in to the admin console and disable administrative security in the admin console. At this point, you can issue the following command from the $was_home/profiles/xxx profile file name/bin directory: Wsadmin-conntype NONE. When the command-line window for wsadmin appears, issue the following command: Securityoff. The above actions can be issued on the application server starting or stopping state. When you enable was again, the state of administrative security is deactivated.
(3) Change the Administrator password
When we need to change the administrator password, you can select "Users and Groups" > "Manage Users", 11, click "Search" when the search content is "*", will list all the users in that repository. Select the administrative user ID to change the user's password. Changes take effect immediately.
(4) Deactivate management security
Disabling the admin console is simple, in the page shown in Figure 10, do not select "Enable Admin Security", click "Apply", save and restart the application server. In a special case, if you forget the administrator password, we cannot log in to the admin console and disable administrative security in the admin console. At this point, you can issue the following command from the $was_home/profiles/xxx profile file name/bin directory: Wsadmin-conntype NONE. When the command-line window for wsadmin appears, issue the following command: Securityoff. The above actions can be issued on the application server starting or stopping state. When you enable was again, the state of administrative security is deactivated.
(5) Change the Administrator password
When we need to change the administrator password, you can select "Users and Groups" > "Manage Users", 11, click "Search" when the search content is "*", will list all the users in that repository. Select the administrative user ID to change the user's password. Changes take effect immediately.
(6) Forgot admin password
If you forget the administrator password, we cannot change the password into the admin console. At this point, you need to deactivate administrative security by using the Wsadmin command in the "Deactivate administrative Security" section, and then "Change the administrator password" to "Enable administrative security" again.
(7) Create more administrative users
When using the was environment with administrative security enabled, there is only one administrator ID by default, which means that only one person can log on to the admin console at the same time. This is not convenient for multi-person development teams to publish tests in the same was environment. You can create a user in the repository first, and then assign the appropriate management role to the user ID. The steps are as follows: 1) Select "Users and Groups" > "Manage Users", 24, click "Add" to add a user ID, for example, Admin1. Save. 2) Select users and Groups > Manage user roles, 25, fill in the user name (must be a user name that already exists in the repository), select the appropriate management role, for example, Administrator. Click "OK" to save. This way, the next time you restart was, two users can log on to the admin console at the same time.
3. Backup/Restore Profiles
When the production environment, profile configuration is too complex or changes frequently, we need to back up the profile regularly so that it recovers quickly if necessary. You can use the Backupconfig command to back up the configuration file. For example, to back up the current configuration of the profile AppSrv01, you can issue a command backupconfig from the $was_home/profiles/appsrv01/bin directory, which will generate a compressed package by default APPSRV01 the current profile. You can also specify the name of the compressed package, for example: Backupconfig websphereconfig_2007_05_30.zip. When restoring the configuration, use Restoreconfig websphereconfig_2007_05_30.zip.
4. Properly uninstalled was
It should be recalled that the uninstall process of was did not delete the directory directly, and if you did, you might not be able to install was successfully on the same machine the next time. Before uninstalling was, stop the was process on the machine and use Ps–ef |grep Java to ensure that no was process is running. Then, execute the was_home/uninstall/uninstall.sh command to uninstall was. If, for some special reason, the uninstallation process is not successful (for example, if you deleted the was installation directory directly), or if you want to install was again in the same directory, please refer to the recommendations given by the InfoCenter "manual Uninstall".
Application deployment typically involves the following tasks: Configure the environment that your app requires: System variables, virtual hosts, classpath, security, and so on, and configure the resources that your app needs, such as JMS resources, data sources, and so on. Among them, it should be noted that:
(1) Application Packaging: Applications deployed on WebSphere application servers can be packaged *.ear/*.war files or components that are not packaged but meet the requirements of the Java EE specification. In a production environment, it is recommended to use packaged *.ear/*.war files for versioning and management purposes. For packaging multiple Java EE components in a complex project, see the article "Management of the Java EE Application Development Project package".
(2) Manage Utility jar Package: Most of the Java EE applications will have some common Utility jar packages, the first thing to emphasize is: Be sure to avoid having multiple versions of the same class in the same class loading path! This can lead to many puzzling and difficult to diagnose problems in the actual operation. Second, for the JDBC driver this kind of general-purpose high-level utility jar package, can be placed in the <was_home>/lib/ext directory, for multiple applications shared utility jar, can be placed in the <was_home>/lib/ EXT, it can also be placed in the shared library, it is recommended to be placed in the shared library, for a single application to use the utility Jar, can be packaged with the application, or into the shared library. The use of shared libraries avoids the clutter of multiple versions of the utility jar package and conflicts with utility jar packages. The shared library configuration method is described in the Red Book sg247304 12.5.4 Step 4:sharing utility JARs using shared libraries section.
(3) Jar package conflict: Jar Package conflicts are often encountered in large-scale Java software development, in short, when the common utility jar package used by different applications, the application server underlying JAR package has the same name and different versions of the class, we call the jar package conflict. The solution to this problem can be referred to in how the article resolves jar package conflicts in WebSphere.
(4) Session timeout: Depending on the scenario, the desired session timeout for different applications varies. Session Management for WebSphere application servers is divided into application server, application, and Web module three levels. As the name implies, the configuration of the session management changed at each specific level, which works on the current level. The default session time-out is 30 minutes for apps deployed on WebSphere application servers, and the default session management level is application Server. If you expect to change your app, for example, Defaultapplication's session time-out, follow these steps: Select Application > Application name > Session management (Figure 13), select "Overwrite Session Management" and fill in the desired session timeout in "set timeout". Click "OK" to save.
(5) Environment variable setting
When an application needs to configure some variables in a way that writes Java environment variables, it can be specified in the Application server startup script with the-d parameter, or in the Application Server > Application server name (for example, server1) > process definition > Java virtual machine Settings " Generic JVM parameter "-daaa=xxx.

For example, when Oracle drives are missing, seconds and minutes are a workaround
Application Server > Server1 > Process definition > Java virtual machine > Custom properties
Under new
-doracle.jdbc.v8compatible=true
Solve Chinese garbled problem
Set autorequestencoding= "true" autoresponseencoding= "true" in the Ibm-web-ext.xmi file
Application Server > Server1 > Process definition > Java virtual machine, specifying-DDEFAULT.CLIENT.ENCODING=GBK for generic JVM arguments

WebSphere Performance Settings and daily maintenance (reprint)