ch39_12.htm

the unix power tools

></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="UPT-ART-67-SECT-1.3"
>39.12.3 The I/O Subsystem </A
></H3
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-44348"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44350"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44353"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44355"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44358"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44361"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44363"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44365"
></A
>The I/O subsystem is a common source of resource contention problems.
A finite amount of I/O bandwidth must be shared by all the programs
(including the UNIX kernel) that currently run. The system's
I/O buses can transfer only so many megabytes per second; individual
devices are even more limited. Each kind of device has its own
peculiarities and, therefore, its own problems. Unfortunately, 
UNIX has poor tools for analyzing the I/O subsystem.
Under BSD UNIX, <EM
CLASS="emphasis"
>iostat</EM
> can give you information about the
transfer rates for 
each disk drive; <EM
CLASS="emphasis"
>ps</EM
> and <EM
CLASS="emphasis"
>vmstat</EM
> can give some information
about how many processes are blocked waiting for I/O; and
<EM
CLASS="emphasis"
>netstat</EM
> and <EM
CLASS="emphasis"
>nfsstat</EM
> report various network statistics.
Under System V, <EM
CLASS="emphasis"
>sar</EM
> can provide voluminous information about I/O
efficiency, and <EM
CLASS="emphasis"
>sadp</EM
> (V.4) can give detailed information about
disk access patterns. However, there is no standard tool to measure
the I/O subsystem's response to a heavy load.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-44375"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44378"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44380"
></A
>The disk and network subsystems are particularly important to overall
performance. Disk bandwidth issues have two general forms:
maximizing per-process
transfer rates and maximizing aggregate transfer rates. The
per-process transfer rate is the rate at which a single program can
read or write data. The aggregate transfer rate is the maximum total
bandwidth that the system can provide to all programs that run.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-44383"
></A
>Network I/O problems have two basic forms: a network can be
overloaded or a network can lose data integrity. When a network is
overloaded, the amount of data that needs to be transferred across the
network is greater than the network's capacity; therefore, the actual
transfer rate for any task is relatively slow. Network load problems
can usually be solved by changing the network's configuration.
Integrity problems occur when the network is faulty and
intermittently transfers data incorrectly. In order to deliver
correct data to the applications using the network, the network
protocols may have to transmit each block of data many times.
Consequently, programs using the network will run very
slowly. The only way to solve a data integrity problem is to isolate
the faulty part of the network and replace it.</P
></DIV
><DIV
CLASS="sect2"
><H3
CLASS="sect2"
><A
CLASS="title"
NAME="UPT-ART-67-SECT-1.4"
>39.12.4 User Communities </A
></H3
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-44388"
></A
><A
CLASS="indexterm"
NAME="AUTOID-44391"
></A
>So far we have discussed the different factors that contribute to
overall system performance. But we have ignored one of the most
important factors: the users who submit the jobs.</P
><P
CLASS="para"
>In talking about the relationship between users and performance, it is
easy to start seeing users as problems: the creatures who keep your
system from running the way it ought to. Nothing is further from the
truth.
Computers are tools: they exist to help users
do their work and not vice versa.</P
><P
CLASS="para"
>Limitations on memory requirements, file size, job
priorities, etc., are effective only when everyone cooperates.
Likewise, you can't force people to submit their jobs to a
<SPAN
CLASS="link"
>batch queue (<A
CLASS="linkend"
HREF="ch40_06.htm"
TITLE="System V.4 Batch Queues "
>40.6</A
>)</SPAN
>.
Most people will cooperate when they understand a problem and what
they can do to solve it. Most people will resist a solution
that is imposed from above, that they don't understand, or that
seems to get in the way of their work.</P
><P
CLASS="para"
><A
CLASS="indexterm"
NAME="AUTOID-44398"
></A
>The nature of your system's users has a big effect on your
system's performance.
We can divide users into several classes:</P
><UL
CLASS="itemizedlist"
><LI
CLASS="listitem"
><P
CLASS="para"
>Users who run a large number of relatively small jobs: for example,
users who spend most of their time editing or running UNIX utilities.</P
></LI
><LI
CLASS="listitem"
><P
CLASS="para"
>Users who run a small number of relatively large jobs: for example,
users who run large simulation programs with huge data files.</P
></LI
><LI
CLASS="listitem"
><P
CLASS="para"
>Users who run a small number of CPU-intensive jobs that don't require
a lot of I/O but do require a lot of memory and CPU time.  Program
developers fall into this category. Compilers tend to be large
programs that build large data structures and can be a source of
memory contention problems.</P
></LI
></UL
><P
CLASS="para"
>All three groups can cause problems. Several dozen users running
<EM
CLASS="emphasis"
>grep</EM
> and accessing remote filesystems can be as bad for overall
performance as a few users accessing gigabyte files. However, the
types of problems these groups cause are not the same. For example,
setting up a &quot;striped filesystem&quot; will help disk performance for
large, I/O-bound jobs but won't help (and may hurt) users who run many
small jobs. Setting up batch queues will help reduce contention among
large jobs, which can often be run overnight, but it won't help the
system if its problems arise from users typing at their 
text editors and reading their mail.</P
><P
CLASS="para"
>Modern systems with
<SPAN
CLASS="link"
>network facilities (<A
CLASS="linkend"
HREF="ch01_33.htm"
TITLE="UNIX Networking and Communications "
>1.33</A
>)</SPAN
>
complicate the picture even more.  In addition to knowing what kinds
of work users do, you also need to know what kind of equipment they
use: a standard terminal over an RS-232 line, an X terminal over
Ethernet, or
a diskless workstation? The X Window System requires a lot of memory
and puts a heavy load on the network. Likewise, diskless workstations
place a load on the network. Similarly, do users access local files or
remote files via NFS or RFS?</P
></DIV
><DIV
CLASS="sect1info"
><P
CLASS="SECT1INFO"
>- <SPAN
CLASS="authorinitials"
>ML</SPAN
> <SPAN
CLASS="bibliomisc"
>from O'Reilly &amp; Associates' <CITE
CLASS="citetitle"
>System Performance Tuning</CITE
>, Chapter 1</SPAN
></P
></DIV
></DIV
><DIV
CLASS="htmlnav"
><P
></P
><HR
ALIGN="LEFT"
WIDTH="515"
TITLE="footer"><TABLE
WIDTH="515"
BORDER="0"
CELLSPACING="0"
CELLPADDING="0"
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="172"
><A
CLASS="SECT1"
HREF="ch39_11.htm"
TITLE="39.11 Changing a Job's Priority Under BSD UNIX "
><IMG
SRC="gifs/txtpreva.gif"
SRC="gifs/txtpreva.gif"
ALT="Previous: 39.11 Changing a Job's Priority Under BSD UNIX "
BORDER="0"></A
></TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="171"
><A
CLASS="book"
HREF="index.htm"
TITLE="UNIX Power Tools"
><IMG
SRC="gifs/txthome.gif"
SRC="gifs/txthome.gif"
ALT="UNIX Power Tools"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="172"
><A
CLASS="CHAPTER"
HREF="ch40_01.htm"
TITLE="40. Delayed Execution"
><IMG
SRC="gifs/txtnexta.gif"
SRC="gifs/txtnexta.gif"
ALT="Next: 40. Delayed Execution"
BORDER="0"></A
></TD
></TR
><TR
><TD
ALIGN="LEFT"
VALIGN="TOP"
WIDTH="172"
>39.11 Changing a Job's Priority Under BSD UNIX </TD
><TD
ALIGN="CENTER"
VALIGN="TOP"
WIDTH="171"
><A
CLASS="index"
HREF="index/idx_0.htm"
TITLE="Book Index"
><IMG
SRC="gifs/index.gif"
SRC="gifs/index.gif"
ALT="Book Index"
BORDER="0"></A
></TD
><TD
ALIGN="RIGHT"
VALIGN="TOP"
WIDTH="172"
>40. Delayed Execution</TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="515"
TITLE="footer"><IMG
SRC="gifs/smnavbar.gif"
SRC="gifs/smnavbar.gif"
USEMAP="#map"
BORDER="0"
ALT="The UNIX CD Bookshelf Navigation"><MAP
NAME="map"
><AREA
SHAPE="RECT"
COORDS="0,0,73,21"
HREF="../index.htm"
ALT="The UNIX CD Bookshelf"><AREA
SHAPE="RECT"
COORDS="74,0,163,21"
HREF="index.htm"
ALT="UNIX Power Tools"><AREA
SHAPE="RECT"
COORDS="164,0,257,21"
HREF="../unixnut/index.htm"
ALT="UNIX in a Nutshell"><AREA
SHAPE="RECT"
COORDS="258,0,321,21"
HREF="../vi/index.htm"
ALT="Learning the vi Editor"><AREA
SHAPE="RECT"
COORDS="322,0,378,21"
HREF="../sedawk/index.htm"
ALT="sed &amp; awk"><AREA
SHAPE="RECT"
COORDS="379,0,438,21"
HREF="../ksh/index.htm"
ALT="Learning the Korn Shell"><AREA
SHAPE="RECT"
COORDS="439,0,514,21"
HREF="../lrnunix/index.htm"
ALT="Learning the UNIX Operating System"></MAP
></DIV
></BODY
></HTML
>