|
Pro/INTRALINK seems slow or non-responsive, and you suspect the network may be the reason. But where do you start? The network can become the limiting factor for I/O performance and problems with other systems can cause bad performance on your system. This article explains how to check your UNIX data and file servers’ network connection and configuration using a few simple commands, and then how to interpret the results. A future article will address how to do the same for Windows NT systems.
Before beginning, we need to make some basic assumptions. First, both our data and file servers are UNIX. Second, for optimal performance, the network needs to meet three conditions:
- It must be able to transfer data correctly (data integrity).
- It must provide enough bandwidth to meet the needs of the users on the network.
- Each system on the network must be fast enough to handle the network traffic addressed to it.
1. Start with one of the most basic UNIX commands, netstat, which is commonly used to display detailed statistics about each network interface, network sockets, and the network routing table. Enter the command netstat –in. The –i option tells netstat to display the status of the configured network interfaces. The –n tells netstat to display its output in numeric format. You should see something similar to the table below.
ilink1 <root> 34# netstat –in
|
Name
|
Mtu
|
Network
|
Address
|
Ipkts
|
Ierrs
|
Opkts
|
Oerrs
|
Coll
|
|
ni0*
|
0
|
none
|
none
|
0
|
0
|
0
|
0
|
0
|
|
ni1*
|
0
|
none
|
none
|
0
|
0
|
0
|
0
|
0
|
|
lo0
|
4608
|
127
|
127.0.0.1
|
4549065
|
0
|
4549061
|
0
|
0
|
|
atm0
|
18432
|
none
|
none
|
0
|
0
|
0
|
0
|
0
|
|
ipa0*
|
9180
|
none
|
none
|
0
|
0
|
0
|
0
|
0
|
|
lan0*
|
1500
|
none
|
none
|
1
|
0
|
0
|
0
|
0
|
|
ela1
|
1500
|
10.2
|
10.2.3.24
|
2234039
|
485
|
6448
|
0
|
0
|
|
ela2
|
1500
|
10.3
|
10.3.3.24
|
2654970
|
232375
|
108992
|
0
|
0
|
|
ela3
|
1500
|
10.4
|
10.4.3.24
|
3212806
|
359263
|
29961
|
0
|
0
|
|
ela4
|
1500
|
10.5
|
10.5.3.24
|
2009472
|
64256
|
8934
|
0
|
0
|
|
ela5
|
1500
|
10.6
|
10.6.3.24
|
22921161
|
10083
|
9528324
|
12
|
0
|
|
ela6
|
1500
|
10.7
|
10.7.3.24
|
3275791
|
472885
|
17026
|
0
|
0
|
|
ela7
|
1500
|
10.11
|
10.11.3.24
|
201821
|
15
|
2751
|
0
|
0
|
2. There are three things to look for from this output: the number of input errors (Ierrs), output errors (Oerrs), and collisions (Coll). Here’s how it works. Both input and output errors should be less than %2 _ of their parent columns (Ipkts) and (Opkts). For the number of collisions, you should have a value less than %10 of the total number of output packets (Opkts).
3. In this example, we have some good and some not-so-good network connections. Note the very high number of input errors (Ierrs) from several of interfaces. Input errors usually indicate faulty hardware, which can be anything from another computer that is generating bad packets to a bad connector or terminator. If I saw a large number of output errors (Oerrs), I would be concerned that the system’s network interface was bad.
The drawback to netstat is that the counters reflect your system’s activity since the last time it was booted. You can write a script to take and store netstat readings at regular intervals, and then report any changes between the current and previous readings.
An excellent resource book for tuning your UNIX system is the second edition of “System Performance Tuning,” published by O’Reilly & Associates. 
Duane Roach is a senior server engineer at Steelcase, Inc. in Grand Rapids, Michigan, USA. He can be reached by e-mail at droach@steelcase.com.
|
