HP OpenVMS Systems Documentation
HP TCP/IP Services for OpenVMS
The socket subsystem has three attributes that monitor socket listen queue events:
The initial value of these attributes is 0. Use the sysconfig -q socket command to display the current attribute values. If the values show that the queues are overflowing, you may need to increase the socket listen queue limit.
The value of the sominconn attribute should equal the value of the somaxconn attribute. When these two attributes are equal, the value of somaxconn_drops will have the same value as sobacklog_drops .
However, if the value of the
attribute is 0 (the default), and if one or more server applications
uses an inadequate value for the backlog argument to its listen system
call, the value of
may increase at a rate that is faster than the rate at which the
counter increases. If this occurs, you may want to increase the value
attribute. See Section 22.214.171.124 for more information.
2.2 Tuning Server Applications
In addition to tuning TCP/IP Services kernel attributes, performance improvements can be made to server applications by:
Each connection to an Internet server requires enough memory resources for the following:
These memory resources total 1 KB for each connection endpoint (not including the socket buffer space), which means 10 MB of memory is required in order to accommodate 10,000 connections.
Your server must have enough memory to handle demanding peak loads. As a rule of thumb, if you configure ten times more memory than the server requires on a busy day, you will have sufficient memory to handle occasional spikes of activity.
There are no limitations on a server's ability to handle millions of
TCP connections if memory resources are available to service the
connections. If memory is insufficient, the server will reject new
connection requests until memory is available. Use the
command to monitor the memory that is currently being used by the
network subsystem. See Section 1.2.4 for information about displaying
2.2.2 Logging IP Addresses
If your server application logs client host names, the application software may force the system to perform a reverse DNS lookup to obtain the client's host name. Reverse DNS lookups are time-intensive and can cause performance problems on servers with many clients.
Many applications can be modified to log client IP addresses instead of client host names. Logging IP addresses instead of host names may significantly improve the efficiency of the server. Consult the documentation provided by the server software vendor to determine how to disable the logging of client host names.
For example, you can obtain information about modifying Apache HTTP
Server software from the Apache HTTP Server documentation site.
2.2.3 Increasing the Auxiliary Server Connection Limit
The auxiliary server handles a limited number of service invocations in a one-minute period of time. The default is a maximum of 500 connection requests. If the number of requests exceeds this limit, the auxiliary server will not accept additional requests for that service.
If your server receives more than eight requests per second for a service that is spawned by the auxiliary server (for example, POP-3, FTP, and SMTP servers), increase the default connection request limit. You can check the service's log file to determine if a service has been shut down. For example, the file SYS$SYSDEVICE:[TCPIP$POP]TCPIP$POP_RUN.LOG will contain information about the POP service.
Because the auxiliary server does not spawn any known HTTP server, the
connection request limit does not affect HTTP service.
2.2.4 Increasing the Maximum Number of BG Devices
You can configure TCP/IP Services to create more than 10,000 devices. This is useful if the system is a web server.
The net subsystem attributes the provide information about allow you to modify the way TCP/IP Services handles BG devices are described in Table 2-5.
|ovms_unit_count||Informational attribute that shows the number of BG devices that exist in the system. You cannot modify this attribute.|
|ovms_unit_creates||Information attribute that shows a running total of all the BG devices created since TCP/IP Services was started. You can use this information to see how often devices are being used. You cannot modify this attribute.|
Specifies fast creation and deletion of BG devices, useful on a system
that uses many BG devices. Modifying this attribute can improve
performance by reducing:
The default setting for this attribute is 0, or OFF.
This attribute can affect the amount of virtual memory used. To calculate the effect of this attribute on virtual memory usage, add one to the the number of BG devices ( ovms_unit_maximum ) and multiply by 4. For example, with the default setting of 9999, the virtual memory is 40,000 bytes. At its maximum value of 32767, the virtual memory is 131,072 bytes.
You can modify this attribute.
|ovms_unit_limit||This informational attribute shows the calculated maximum number of concurrent BG device units that can coexist at any time given the values of the ovms_unit_maximum and ovms_unit_minimum attributes. Note that BG0 and BG1 are always reserved. You cannot modify this attribute.|
|ovms_unit_minimum||Specifies the lowest numbered device unit. All BG devices after BG0 will begin with this unit number. You can modify this attribute.|
|ovms_unit_maximum||Specifies the highest numbered device unit. It is possible there will be BG device numbers above this, but they are not available to users. You can specify a value from 9999 to 32767. You can modify this attribute.|
|ovms_unit_seed||This informational attribute shows the next BG unit number that will be created. If ovms_unit_fast_credel is enabled, a duplicate BG device unit is sensed immediately and the unit seed incremented. If ovms_unit_fast_credel is not enabled, a device scan will occur as it normally does with cloned devices.|
This section contains information that you can use to identify and solve server performance problems.
The following tasks can help you to solve performance problems:
This section provides recommendations for tuning a server for optimal performance. These recommendations are applicable to most configurations and include the attribute value and a reference to additional information.
The primary recommendations for servers, (including web servers, proxy servers, gateway systems, and firewall systems) are as follows:
somaxconn = 65535 sominconn = 65535
pmtu_enabled = 0
For proxy servers, gateway systems, and firewall systems, also apply these additional recommendations:
sbcompress_threshold = 600
ipport_userreserved = 65000
You can improve the performance of TCP/IP Services over Gigabit Ethernet (GbE) by configuring the system to use jumbo frames.
Jumbo frames (frames larger than the 1518 octets specified by the IEEE 802.3 standard) improve performance because more data can be transmitted in each frame, hence reducing the frame rate and interrupt load on a system. Jumbo frames must be configured on both the Gigabit Ethernet switch as well as the Gigabit Ethernet controllers on the host systems. Configure jumbo frames before you start TCP/IP Services on the OpenVMS server.
There are two ways to configure jumbo frames for Gigabit Ethernet controllers on OpenVMS:
$ mcr lancp set dev ewa/jumbo ! enable jumbo frames for GbE.
LAN_FLAGS=64 ! Set bit 6 to enable jumbo frames on GbE, a dynamic parameter
To verify that TCP/IP Services now sees a jumbo frame size IPMTU, use a command similar to:
$ ifconfig we0 WE0: flags=c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX> *inet 10.0.0.4 netmask ffff0000 broadcast 10.0.255.255 ipmtu 9000
You can verify jumbo frame configuration using the tcpdump command. For example, consider two systems connected with Gigabit Ethernet, GIGA1 and GIGA2:
On GIGA1, enter the following command:
$ tcpdump -c 2 -t port telnet
On GIGA2, enter the following command:
$ TELNET giga1
The tcpdump command displays the two packets from the TCP connection establishment and reveals the negotiated maximum segment size ( mss ). For example, on a correctly configured system the tcpdump trace from the TELNET command shows:
$ tcpdump -c 2 -t port telnet tcpdump: listening on Filtering in user process GIGA2.49188 > GIGA1.23: S 165176320:165176320(0) win 3000 <mss 8960,nop,wscale 0> GIGA1.23 > GIGA2.49188: S 1890602256:1890602256(0) ack 165176321 win 3000 <mss 8960,nop,wscale 0> 2 packets (out of 5 examined)
Note that the requested mss of 8960 in the SYN packet is also accepted by the server in the SYN ACK packket. On earlier versions of OpenVMS, the jumbo-frame mss may be less than 8960 bytes.
If one of the systems is not configured with jumbo frames, the tcpdump utility shows the following:
$ tcpdump -c 2 -t port telnet tcpdump: listening on Filtering in user process GIGA2.49187 > GIGA1.23: S 142920192:142920192(0) win 3000 <mss 8960,nop,wscale 0> GIGA1.23 > GIGA2.49187: S 2953104448:2953104448(0) ack 142920193 win 4380 <mss 1460,nop,wscale 0> 2 packets (out of 5 examined)
The TELNET client requests an mss of 8960 bytes in the SYN packet, but the server responds with an mss of 1460 bytes in the SYN ACK packet. Therefore, GIGA1 is not correctly configured for jumbo frames.
This appendix provides more information about the troubleshooting utilities described in this manual. It also describes the utilities used for isolating and resolving problems with your network and network software.
To invoke a utility as a command at the system prompt, execute the SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM file. Execution of this file defines each utility as a foreign command.
Displays and controls Address Resolution Protocol (ARP) tables.
arp [-u] [-n] hostname
arp -a [-u] [-n] [-i] hostname
arp -d hostname
arp -g hostname
arp -s [-u] hostname hardware_addr [temp] [pub] [trail]
arp -f filename
The arp command displays or modifies the current ARP entry for the host specified by hostname. The hostname value can be specified by name or IP address, using dotted-decimal notation.
With no flags, the program displays the current ARP entry for hostname .
The ARP tables can be displayed by any user, but only privileged users can modify them.
-aDisplays all current ARP entries.
-d hostnameDeletes the entry for hostname if the user entering the command is a privileged user.
-f filenameReads entries from filename and adds those entries to the ARP tables. Use of this flag requires system privileges. Entries in the file have the following format:
hostname hardware_addr [temp] [pub] [trail]
Fields in this format are:
Option Description hostname Specifies the remote host identified by the entry. hardware_addr Specifies the hardware address of the remote host. The address is given as 6 hexadecimal bytes separated by colons. temp Specifies that this ARP table entry is temporary. When this argument is not used, the table entry is permanent. pub Indicates that the table entry will be published and that the current system will act as an ARP server, responding to requests for hostname even though the host address is not its own. trail Indicates that the trailer encapsulation can be sent to this host.
-g hostnameSends a gratuitous ARP packet. The value for hostname can be a local host name, alias, or IP address.
-i hostnameDisplays the interface with which the ARP entry is associated.
-n hostnameDisplays numeric IP addresses and hardware addresses only. When this flag is not specified, arp displays hostnames, numeric IP addresses, and hardware addresses.
-s hostname hardware_addr [temp] [pub]Creates a single ARP entry for hostname. Use of this flag requires privileges. Fields in the format are:
hostname Specifies the remote host identified by the entry. hardware_addr Specifies the hardware address of the remote given as 6 hexadecimal bytes separated by colons. temp Specifies that this ARP table entry is temporary. When this argument is not used, the table entry is permanent. pub Indicates that the table entry will be published and the current system will act as an ARP server, responding to requests for hostname even though the host address is not its own.
-uDisplays the MAC address in noncanonical form, with address bytes reversed and separated by a colon character (:). By default, all addresses are displayed in canonical form with address bytes separated by the hyphen character (-).
When used with the -s flag, this indicates the hardware_addr is specified in noncanonical form.
The following examples show how to use the arp command.
TCPIP> arp -a a71kt.lkg.dec.com (10.10.2.1) at aa-00-04-00-71-f8 stale v71kt.lkg.dec.com (10.10.2.3) at aa-00-04-00-70-f8 stale v72kt.lkg.dec.com (10.10.2.4) at aa-00-04-00-6d-f8 tlab9.lkg.dec.com (10.10.2.11) at aa-00-04-00-42-11 timber.lkg.dec.com (10.10.2.14) at aa-00-04-00-c9-f8
This example shows how to display the ARP address-mapping tables for the local host.
TCPIP> arp -a -i a71kt.lkg.dec.com (10.10.2.1) at aa-00-04-00-71-f8 stale (WE0) v71kt.lkg.dec.com (10.10.2.3) at aa-00-04-00-70-f8 (WE0) v72kt.lkg.dec.com (10.10.2.4) at aa-00-04-00-6d-f8 stale (WE0) tlab9.lkg.dec.com (10.10.2.11) at aa-00-04-00-42-11 (WE0) timber.lkg.dec.com (10.10.2.14) at aa-00-04-00-c9-f8 (WE0)
This example shows how to display the ARP address-mapping tables for the local host and the interface.
TCPIP> arp -s laszlo 08:00:2b:0f:44:23 temp
This example shows how to add a single entry for the remote host laszlo to the ARP mapping tables temporarily. The address is considered canonical even though the bytes are separated by colons. For input, the arp command does not use the colon (:) and hyphen (-) characters to indicate whether the address is canonical or noncanonical. You must have system privileges to execute this command.
TCPIP> arp -u -s laszlo 10:00:d4:f0:22:c4 temp
This example shows how to add a single entry for the remote host laszlo to the arp mapping tables temporarily. The -u flag indicates the address is noncanonical. You must have system privileges to execute this command.
TCPIP> arp -f newentries
This example shows how to add multiple entries to the ARP mapping tables from a file named newentries . You must have system privileges to execute this command.