[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here HP TCP/IP Services for OpenVMS

HP TCP/IP Services for OpenVMS
Tuning and Troubleshooting


Previous Contents Index

2.1.7 Displaying Socket Statistics

The socket subsystem has three attributes that monitor socket listen queue events:

  • The sobacklog_hiwat attribute counts the maximum number of pending requests to any server socket.
  • The sobacklog_drops attribute counts the number of times the system dropped a received SYN packet because the number of queued SYN_RCVD connections for a socket equaled the socket's backlog limit.
  • The somaxconn_drops attribute counts the number of times the system dropped a received SYN packet because the number of queued SYN_RCVD connections for the socket equaled the upper limit on the backlog length ( somaxconn attribute).

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 sominconn 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 sobacklog_drops may increase at a rate that is faster than the rate at which the somaxconn_drops counter increases. If this occurs, you may want to increase the value of the sominconn attribute. See Section 2.1.5.2 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:

  • Ensuring adequate memory configuration
  • Logging IP addresses

2.2.1 Configuring Memory for High Performance

Each connection to an Internet server requires enough memory resources for the following:

  • Kernel socket structure
  • Internet protocol control block ( inpcb ) structure
  • TCP control block structure
  • Any socket buffer space that is needed as packets arrive and are consumed

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 netstat -m command to monitor the memory that is currently being used by the network subsystem. See Section 1.2.4 for information about displaying memory statistics.

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.

Table 2-5 net Subsystem Attributes
Attribute Description
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.
ovms_unit_fast_credel 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 impact of the device list scan on the CPU cache.
  • The time that the I/O mutex is held for write access during the SYS$ASSIGN() and SYS$DASSGN() system services.

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.

To modify ovms_unit_fast_credel , ovms_unit_minimum , and ovms_unit_maximum , define them in the SYSCONFIGTAB.DAT file, as described in Section 2.1.2.

2.3 Solving Performance Problems

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:

  • Monitor the server.
    See Section 1.2.4 for information about monitoring the network, the virtual memory subsystem, and network socket statistics.
  • Apply any patches recommended for your operating system.
    See the Recommended Patch Table for information about operating system patches that can improve performance.
  • Apply the kernel attribute values that are recommended for your type of system.
    See Section 2.3.1 for a list of attributes that can be tuned to improve performance.
  • Prevent "forbidden" and "url could not load" messages on Netscape enterprise server systems.

2.3.1 Tuning Recommendations for a Primary Server

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:

  • Tune the following socket subsystem attributes:


         somaxconn = 65535
         sominconn = 65535
    
  • Tune the following inet subsystem attributes:


              pmtu_enabled = 0
    

For proxy servers, gateway systems, and firewall systems, also apply these additional recommendations:

  • Modify the following socket subsystem attribute as follows:


         sbcompress_threshold = 600
    
  • Modify the following inet subsystem attribute as follows:


         ipport_userreserved = 65000
    

2.3.2 Improving Gigabit Ethernet Performance

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:

  • Including the following LANCP command in SYSTARTUP_VMS.COM:


    $ mcr lancp set dev ewa/jumbo ! enable jumbo frames for GbE.
    
  • Setting the SYSGEN parameter LAN_FLAGS in MODPARAMS.DAT and running AUTOGEN. For example:


    LAN_FLAGS=64   ! Set bit 6 to enable jumbo frames on GbE, a dynamic parameter
    

    Restart TCP/IP Services after you enable jumbo frames dynamically.

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.


Appendix A
Troubleshooting Utilities Reference

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.


arp

Displays and controls Address Resolution Protocol (ARP) tables.


Format

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

description

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.


Flags

-a

Displays all current ARP entries.

-d hostname

Deletes the entry for hostname if the user entering the command is a privileged user.

-f filename

Reads 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 hostname

Sends a gratuitous ARP packet. The value for hostname can be a local host name, alias, or IP address.

-i hostname

Displays the interface with which the ARP entry is associated.

-n hostname

Displays 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.

-u

Displays 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.


Examples

The following examples show how to use the arp command.
#1

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.

#2

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.

#3

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.

#4

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.

#5

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.


Previous Next Contents Index