(ZOS) UNIX System Services (USS) tuning tips for z/OS
Use these tips to tune your z/OS operating system to optimize WebSphere Application Server performance.
WAS for z/OS no longer requires or recommends the shared file system for the configuration files, since it maintains its own mechanism for managing this data in a cluster. However, WebSphere for z/OS does require the shared files system for XA partner logs. The application may also use the shared file system. This article provides some basic tuning information for the shared file system.
For basic z/OS UNIX System Services performance information, refer to the following website: http://www.ibm.com/servers/eserver/zseries/ebusiness/perform.html
- Consider using zFS.
z/OS has introduced a new file system called zFS which should provide improved file system access. You may benefit from using the zFS for our UNIX file system. See z/OS UNIX System Services Planning for more information.
- Decide whether to mount the shared file system R/W or R/O.
Starting with z/OS Version 1.13, if zFS is used as the file system in a sysplex, all of the systems in that sysplex have direct access to that file system. In this situation, we can mount the WAS file system R/W in a shared file system environment without negatively impacting performance.
If we are running in a sysplex environment on z/OS Version 1.12 or earlier, or if zFS is not used as the file system for our sysplex, we must give special consideration to how you mount the WAS file system. When a file system is mounted R/W in a shared file system environment on these operating systems, only one system has local access to the files. All other systems have remote access to the files which negatively affects performance. Therefore, we might want to put all of the files for WebSphere in their own mountable file system and mount it R/O to improve performance. However, to change your current application or install new applications, the file system must be mounted R/W. You will need to put operational procedures in place to ensure that the file system is mounted R/W when updating or installing applications.
- Determine which files are good candidates for HFS files caching.
HFS Files Caching Read/Write files are cached in kernel data spaces. In order to determine what files would be good candidates for file caching we can use SMF 92 records.
Initial cache size is defined in BPXPRMxx.
- Use the filecache command.
High activity, read-only files can be cached in the USS kernel using the filecache command. Access to files in the filecache can be more efficient than access to files in the shared file system, even if the shared file system files are cached in dataspaces. GRS latch contention, which sometimes is an issue for frequently accessed files shared file system, will not affect files in the filecache.
To filecache important files at startup, we can add filecache command to your /etc/rc file. Unfortunately, files which are modified after being added to the filecache may not be eligible for caching until the file system is unmounted and remounted, or until the system is re-IPLed. Refer to z/OS UNIX System Services Command Reference for more information about the filecache command.
Example of using the filecache command:
/usr/sbin/filecache -a /usr/lpp/WebSphere/V5R0M0/ QSeries/java/samples/base/de_DE/mqsample.html- Do not enable global audit ALWAYS on the RACF (SAF) classes that control access to objects in the UNIX file system. If audit ALWAYS is specified in the SETR LOGOPTIONS for DIRACC, DIRSRCH, FSOBJ or FSSEC very severe performance degradation might occur. If auditing is required, audit only failures using SETR LOGOPTIONS, and audit successes for only selected objects that require it. After enabling any auditing on these classes, verify that the change did not cause an unacceptable impact on response times and CPU usage.
Tune the z/OS operating system Tune operating systems