unx39.htm

Linux Unix揭密.高质量电子书籍.对学习Linux有大帮助,欢迎下载学习.

<TR>

<TD>

<P>sy</P>

<TD>

<P>System time</P>

<TR>

<TD>

<P>id</P>

<TD>

<P>Idle time</P></TABLE>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> The vmstat command's first line is rarely of any use. When reviewing the output from the command, always start at the second line and go forward for pertinent data.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>Let's look at some of these fields for clues about system performance. As far as memory performance goes, po and w are very important. For people using the -S option so is similarly important. These fields all clearly show when a system is paging and 
swapping. If w is non-zero and so continually indicates swapping, the system probably has a serious memory problem. If, likewise, po consistently has large numbers present, the system probably has a significant memory resource problem.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>If your version of vmstat doesn't specifically provide swapping information, you can infer the swapping by watching the relationship between the w and the fre fields. An increase in w, the swapped-out 
processes, followed by an increase in fre, the number of pages on the free list, can provide the same information in a different manner.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>Other fields from the vmstat output are helpful, as well. The number of runnable and blocked processes can provide a good indication of the flow of processes, or lack thereof, through the system. Similarly, comparing each percentage CPU idle versus CPU 

in system state, and versus CPU in user state, can provide information about the overall composition of the workload. As the load increases on the system, it is a good sign if the CPU is spending the majority of the time in the user state. Loads of 60 or 
70 percent for CPU user state are ok. Idle CPU should drop as the user load picks up, and under heavy load may well fall to 0.

<BR></P>

<P>If paging and swapping are occurring at an unusually high rate, it may be due to the number and types of jobs that are running. Usually you can turn to ps to determine what those jobs are.

<BR></P>

<P>Imagine that ps shows a large number of jobs that require significant memory resources. (You saw how to determine this in the ps discussion in the previous section.) That would confirm the vmstat report. To resolve the problem, you would have to 
restrict memory-intensive jobs, or the use of memory, or add more memory physically.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>You can see that having a history of several vmstat and ps reports during normal system operation can be extremely helpful in determining what the usual conditions are, and, subsequently, what the 
unusual ones are. Also, one or two vmstat reports may indicate a temporary condition, rather than a permanent problem. Sample the system multiple times before deciding that you have the answer to your system's performance problems.

<BR></NOTE>

<HR ALIGN=CENTER>

<H4 ALIGN="CENTER">

<CENTER><A ID="I15" NAME="I15">

<FONT SIZE=3><B>Monitoring Memory Performance with </B><B><I>sar -wpgr</I></B>

<BR></FONT></A></CENTER></H4>

<P>More information about the system's utilization of memory resources can be obtained by using sar -wpgr.

<BR></P>

<PRE>% sar -wpgr 5 5

07:42:30 swpin/s pswin/s swpot/s bswot/s pswch/s

          atch/s  pgin/s ppgin/s  pflt/s  vflt/s slock/s

          pgout/s ppgout/s pgfree/s pgscan/s %s5ipf

          freemem freeswp

07:42:35    0.00    0.0    0.00    0.0    504

            0.00    0.00   0.00    0.00   6.20   11.78

            0.00    0.00   0.00    0.00   0.00

           33139  183023

   

...

Average     0.00     0.0    0.00     0.0     515

Average     0.00    0.32    0.40    2.54    5.56   16.83

Average     0.00     0.00     0.00     0.00   0.00

Average    32926 183015</PRE>

<P>The fields in the report are the following:

<BR></P>

<TABLE BORDER>

<TR>

<TD>

<P>swpin/s</P>

<TD>

<P>Number of transfers into memory per second.</P>

<TR>

<TD>

<P>bswin/s</P>

<TD>

<P>Number of blocks transferred for swap-ins per second.</P>

<TR>

<TD>

<P>swpot/s</P>

<TD>

<P>Number of transfers from memory to swap area per second. (More memory may be needed if the value is greater than 1.)</P>

<TR>

<TD>

<P>bswot/s</P>

<TD>

<P>Number of blocks transferred for swap-outs per second.</P>

<TR>

<TD>

<P>pswch/s</P>

<TD>

<P>Number of process switches per second.</P>

<TR>

<TD>

<P>atch/s</P>

<TD>

<P>Number of attaches per second (that is, page faults where the page is reclaimed from memory).</P>

<TR>

<TD>

<P>pgin/s</P>

<TD>

<P>Number of times per second that file systems get page-in requests.</P>

<TR>

<TD>

<P>ppgin/s</P>

<TD>

<P>Number of pages paged in per second.</P>

<TR>

<TD>

<P>pflt/s</P>

<TD>

<P>Number of page faults from protection errors per second.</P>

<TR>

<TD>

<P>vflt/s</P>

<TD>

<P>Number of address translation page (validity) faults per second.</P>

<TR>

<TD>

<P>slock/s</P>

<TD>

<P>Number of faults per second caused by software lock requests requiring I/O.</P>

<TR>

<TD>

<P>pgout/s</P>

<TD>

<P>Number of times per second that file systems get page-out requests.</P>

<TR>

<TD>

<P>ppgout/s</P>

<TD>

<P>Number of pages paged out per second.</P>

<TR>

<TD>

<P>pgfree/s</P>

<TD>

<P>Number of pages that are put on the free list by the page-stealing daemon. (More memory may be needed if this is a large value.)</P>

<TR>

<TD>

<P>pgscan/s</P>

<TD>

<P>Number of pages scanned by the page-stealing daemon. (More memory may be needed if this is a large value, because it shows that the daemon is checking for free memory more than it should need to.)</P>

<TR>

<TD>

<P>%ufs_ipf</P>

<TD>

<P>Percentage of the ufs inodes that were taken off the free list that had reusable pages associated with them. (Large values indicate that ufs inodes should be increased, so that the free list of inodes will not be page bound.) This will be %s5ipf for 
System V file systems, like in the example.</P>

<TR>

<TD>

<P>freemem</P>

<TD>

<P>The average number of pages, over this interval, of memory available to user processes.</P>

<TR>

<TD>

<P>freeswp</P>

<TD>

<P>The number of disk blocks available for page swapping.</P></TABLE>

<P>You should use the report to examine each of the following conditions. Any one of them would imply that you may have a memory problem. Combinations of them increase the likelihood all the more.

<BR></P>

<P>Check for page-outs, and watch for their consistent occurrence. Look for a high incidence of address translation faults. Check for swap-outs. If they are occasional, it may not be a cause for concern as some number of them is normal (for example, 
inactive jobs). However, consistent swap-outs are usually bad news, indicating that the system is very low on memory and is probably sacrificing active jobs. If you find memory shortage evidence in any of these, you can use ps to look for memory-intensive 

jobs, as you saw in the section on ps.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I16" NAME="I16">

<FONT SIZE=3><B>Multiprocessor Implications of </B><B><I>vmstat</I></B>

<BR></FONT></A></CENTER></H4>

<P>In the CPU columns of the report, the vmstat command summarizes the performance of multiprocessor systems. If you have a two-processor system and the CPU load is reflected as 50 percent, it doesn't necessarily mean that both processors are equally busy. 

Rather, depending on the multiprocessor implementation it can indicate that one processor is almost completely busy and the next is almost idle.

<BR></P>

<P>The first column of vmstat output also has implications for multiprocessor systems. If the number of runnable processes is not consistently greater than the number of processors, it is less likely that you can get significant performance increases from 

adding more CPUs to your system.

<BR></P>

<H3 ALIGN="CENTER">

<CENTER><A ID="I17" NAME="I17">

<FONT SIZE=4><B>Monitoring Disk Subsystem Performance</B>

<BR></FONT></A></CENTER></H3>

<P>Disk operations are the slowest of all operations that must be completed to enable most programs to complete. Furthermore, as more and more UNIX systems are being used for commercial applications, and particularly those that utilize relational database 

systems, the subject of disk performance has become increasingly significant with regard to overall system performance. Therefore, probably more than ever before, UNIX system tuning activities often turn out to be searches for unnecessary and inefficient 
disk I/O. Before you learn about the commands that can help you monitor your disk I/O performance, some background is appropriate.

<BR></P>

<P>Some of the major disk performance variables are the hard disk activities themselves (that is, rotation and arm movement), the I/O controller card, the I/O firmware and software, and the I/O backplane of the system.

<BR></P>

<P>For example, for a given disk operation to be completed successfully, the disk controller must be directed to access the information from the proper part of the disk. This results in a delay known as a queuing delay. When it has located the proper part 

of the disk, the disk arm must begin to position itself over the correct cylinder. This results in a delay called seek latency. The read/write head must then wait for the relevant data to happen as the disk rotates underneath it. This is known as 
rotational latency. The data must then be transferred to the controller. Finally, the data must be transferred over the I/O backplane of the system to be used by the application that requested the information.

<BR></P>

<P>If you think about your use of a compact disk, many of the operations are similar in nature. The CD platter contains information, and is spinning all the time. When you push 5 to request the fifth track of the CD, a controller positions the head that 
reads the information at the correct area of the disk (similar to the queuing delay and seek latency of disk drives). The rotational latency occurs as the CD spins around until the start of your music passes under the reading head. The data&#151;in this 
case your favorite song&#151;is then transferred to a controller and then to some digital to analog converters that transform it into amplified musical information that is playable by your stereo.

<BR></P>

<P>Seek time is the time required to move the head of the disk from one location of data, or track, to another. Moving from one track to another track that is adjacent to it takes very little time and is called minimum seek time. Moving the head between 
the two furthest tracks on a disk is measured as the maximum seek time. The average seek time approximates the average amount of time a seek takes.

<BR></P>

<P>As data access becomes more random in nature, seek time can become more important. In most commercial database applications that feature relational databases, for example, the data is often being accessed in a random manner, at a high rate, and in 
relatively small packets (for example, 512 bytes). Therefore, the disk heads are moving back and forth all the time looking for the pertinent data. Therefore, choosing disks that have small seek times for those systems can increase I/O performance.

<BR></P>

<P>Many drives have roughly the same rotational speed, measured as revolutions per minute, or RPMs. However, some manufacturers are stepping up the RPM rates of their drives. This can have a positive influence on performance by reducing the rotational 
delay, which is the time that the disk head has to wait for the information to get to it (that is, on average one-half of a rotation). It also reduces the amount of time required to transfer the read/write information.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I18" NAME="I18">

<FONT SIZE=3><B>Disk I/O Performance Optimization</B>

<BR></FONT></A></CENTER></H4>

<P>While reviewing the use of the commands to monitor disk performance, you will see how these clearly show which disks and disk subsystems are being the most heavily used. However, before examining those commands, there are some basic hardware-oriented 
approaches to this problem that can help increase performance significantly. The main idea is to put the hardware where the biggest disk problem is, and to evenly spread the disk work load over available I/O controllers and disk drives.

<BR></P>

<P>If your I/O work load is heavy (for example, with many users constantly accessing large volumes of data from the same set of files), you can probably get significant performance increases by reducing the number of disk drives that are daisy chained off 

one I/O controller from five or six to two or three. Perhaps doing this will force another daisy chain to increase in size past a total of four or five, but if the disks on that I/O controller are only used intermittently, system performance will be 
increased overall.

<BR></P>

<P>Another example of this type of technique is if you had one group of users that are pounding one set of files all day long, you could locate the most frequently used data on the fastest disks.

<BR></P>

<P>Notice that, once again, the more thorough your knowledge of the characteristics of the work being done on your system, the greater the chance that your disk architecture will answer those needs.

<BR></P>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="note.gif" WIDTH = 35 HEIGHT = 35><B>NOTE:</B> Remember, distributing a work load evenly across all disks and controllers is not the same thing as distributing the disks evenly across all controllers, or the files evenly across all disks. You must 

know which applications make the heaviest I/O demands, and understand the work load itself, to distribute it effectively.

<BR></NOTE>

<HR ALIGN=CENTER>

<HR ALIGN=CENTER>

<NOTE>

<IMG SRC="imp.gif" WIDTH = 68 HEIGHT = 35><B>TIP: </B>As you build file systems for user groups, remember to factor in the I/O work load. Make sure your high-disk I/O groups are put on their own physical disks and preferably their own I/O controllers as 
well. If possible, keep them, and /usr, off the root disk as well.

<BR></NOTE>

<HR ALIGN=CENTER>

<P>Disk-striping software frequently can help in cases where the majority of disk access goes to a handful of disks. Where a large amount of data is making heavy demands on one disk or one controller, striping distributes the data across multiple disks 
and/or controllers. When the data is striped across multiple disks, the accesses to it are averaged over all the I/O controllers and disks, thus optimizing overall disk throughput. Some disk-striping software also provides Redundant Array of Inexpensive 
Disks (RAID) support and the ability to keep one disk in reserve as a hot standby (that is, a disk that can be automatically rebuilt and used when one of the production disks fails). When thought of in this manner, this can be a very useful feature in 
terms of performance because a system that has been crippled by the failure of a hard drive will be viewed by your user community as having pretty bad performance.

<BR></P>

<P>This information may seem obvious, but it is important to the overall performance of a system. Frequently, the answer to disk performance simply rests on matching the disk architecture to the use of the system.

<BR></P>

<H4 ALIGN="CENTER">

<CENTER><A ID="I19" NAME="I19">

<FONT SIZE=3><B>Relational Databases</B>

<BR></FONT></A></CENTER></H4>

<P>With the increasing use of relational database technologies on UNIX systems, I/O subsystem performance is more important than ever. While analyzing all the relational database systems and making recommendations is beyond the scope of this chapter, some 

basic concepts are in order.

<BR></P>

<P>More and more often these days an application based on a relational database product is the fundamental reason for the procurement of the UNIX system itself. If that is the case in your installation, and if you have relatively little experience in terms 

of database analysis, you should seek professional assistance. In particular, insist on a database analyst that h