Oracle® Traffic Director Administrator's Guide 11g Release 1 (11.1.1.7.0) Part Number E21036-04 |
|
|
PDF · Mobi · ePub |
This section provides tuning information that is specific to Solaris. Note that these are platform-specific tuning tips and any changes that you make could affect other process on the system.
Different platforms have different limits on the number of files that can be open in a single process at one time. For busy sites, increase that number. On Solaris systems, control this limit by setting rlim_fd_max
and rlim_fd_cur
in the /etc/system
file. For Solaris 11, the default for rlim_fd_max
is 65536 and the default value for rlim_fd_cur
is 256.
After making this or any change in the /etc/system
file, reboot Solaris for the new settings to take effect. In addition, if you upgrade to a new version of Solaris, remove any line added to /etc/system
and add it again only after verifying that it is still valid.
An alternative way to make this change is by using the ulimit –n <value>
command. Using this command does not require a system restart. However, this command only changes the login shell, whereas editing the etc/system
file affects all shells.
If clients experience connection timeouts when an Oracle Traffic Director instance is heavily loaded, you can increase the size of the HTTP listener backlog queue. To increase this setting, edit the HTTP listener's listen queue value.
In addition to this, you must also increase the limits within the Solaris TCP/IP networking code. There are two parameters that are changed by executing the following commands:
ipadm set-prop -p _conn_req_max_q=4096 tcp ipadm set-prop -p _conn_req_max_q0=4096 tcp
These two settings increase the maximum number of two Solaris listen queues that can fill up with waiting connections. The setting _conn_req_max_q
increases the number of completed connections waiting to return from an accept()
call. The setting _conn_req_max_q0
increases the maximum number of connections with the handshake incomplete. The default values for _conn_req_max_q
and _conn_req_max_q0
are 128 and 1024, respectively.
You can monitor the effect of these changes by using the netstat -s
command and looking at the tcpListenDrop
, tcpListenDropQ0
, and tcpHalfOpenDrop
values. Review them before adjusting these values. If the counters are not zero, adjust the value to 2048 initially, and continue monitoring the netstat
output.
Do not accept more connections than Oracle Traffic Director is able to process. The value of 2048 for the parameters tcpListenDrop
, tcpListenDropQ0
, and tcpHalfOpenDrop
typically reduces connection request failures, and improvement has been seen with values as high as 4096.
The HTTP listener's listen queue setting and the related Solaris _conn_req_max_q
and _conn_req_max_q0
settings are meant to match the throughput of Oracle Traffic Director. These queues act as a buffer to manage the irregular rate of connections coming from web users. These queues allow Solaris to accept the connections and hold them until they are processed by Oracle Traffic Director.
TCP buffering can be tuned by using the send_buf
and recv_buf
parameters. For more information about these parameters, see Table 15-1, "Tuning Solaris for Performance Benchmarking".
UNIX file system (UFS) volumes maintain the time that each file was accessed. If the file access time updates are not important in your environment, you can turn them off by adding the noatime
parameter to the data volume's mount point in /etc/vfstab
. For example:
/dev/dsk/c0t5d0s6 /dev/rdsk/c0t5d0s6 /data0 ufs 1 yes noatime
Note:
The noatime
parameter does not turn off the access time updates when the file is modified, but only when the file is accessed.
For ZFS, you can use the zfs set
command to modify any settable dataset property. The following example sets the atime
property to off
for tank/home
.
zfs set atime=off tank/home
An Oracle Traffic Director instance's responsiveness depends greatly on the performance of the disk subsystem. The iostat
utility can be used to monitor how busy the disks are and how rapidly they complete I/O requests (the %b
and svc_t columns
, respectively). Service times are not important for disks that are less than 30% busy. However, for busier disks, service times should not exceed about 20 milliseconds. If busy disks have slower service times, improving disk performance can help performance substantially.If some disks are busy while others are lightly loaded, balance the load by moving some files from the busy disks to the idle disks.
Solaris offers several tools for keeping track of system behavior. Although you can capture their output in files for later analysis, the tools listed below are primarily meant for monitoring system behavior in real time:
The iostat -x 60
command reports disk performance statistics at 60-second intervals.
To see how busy each disk is, take a look at the %b
column. For any disk that is busy more than 20% of the time, pay attention to the service time as reported in the svct
column. Other columns provide information about I/O operation rates, amount of data transferred, and so on.
The vmstat 60
command summarizes virtual memory activity and some CPU statistics at 60-second intervals.
Take a look at the sr
column to keep track of the page scan rate and take action if it is too high. In addition, monitor the us
, sy
, and id
columns to see how heavily the CPUs are being used. Note that you need to keep plenty of CPU power in reserve to handle sudden bursts of activity. Also keep track of the r
column to see how many threads are competing for CPU time. If this remains higher than about four times the number of CPUs, reduce the server's concurrency.
The mpstat 60
command provides detailed view of the CPU statistics, while the dlstat show-link -i 60
command summarizes network activity.
While it is important to monitor system performance with the tools mentioned above, collecting longer-term performance histories is equally important, as it can help you detect trends. For example, a baseline record of a system will help you find out what has changed if the system starts behaving poorly. Enable the system activity reporting package by doing the following:
Run the following command:
svcadm enable system/sar
Run the command crontab -e sys
and remove the #
comment characters from the lines with the sa1
and sa2
commands. You can adjust how often the commands run and the time depending on your site's activity profile. For an explanation of the format of this file see the crontab
man page.
This command causes the system to store performance data in files in the /var/adm/sa
directory, where they are retained for one month by default. You can then use the sar
command to examine the statistics for time periods of interest.
The following table shows the operating system tuning for Solaris used when benchmarking for performance and scalability. These values are an example of how you can tune your system to achieve the desired result.
Table 15-1 Tuning Solaris for Performance Benchmarking
Parameter | Scope | Default Value | Tuned Value | Comments |
---|---|---|---|---|
|
|
256 |
65536 |
Soft limit |
|
|
65536 |
65536 |
Process open file descriptors limit; accounts for the expected load (for the associated sockets, files, and pipes if any). |
|
|
60000 |
600000 |
Set on clients as well. |
|
|
128 |
1024 |
|
|
|
1024 |
4096 |
|
|
|
300000 |
600000 |
|
|
|
7200000 |
9000000 |
For high traffic web sites, lower this value. |
|
|
1000 |
3000 |
If re-transmission is greater than 30-40%, increase this value. |
|
|
60000 |
100000 |
|
|
|
200 |
3000 |
|
|
|
32768 |
65535 |
Set on clients as well. |
|
|
49152 |
128000 |
To increase the transmit buffer. |
|
|
128000 |
1048576 |
To increase the receive buffer. |