?? unx39.htm
字號:
<HTML>
<HEAD>
<TITLE>UNIX Unleashed unx39.htm</TITLE>
<LINK REL="ToC" HREF="index.htm">
<LINK REL="Next" HREF="unx40.htm">
<LINK REL="Previous" HREF="unx38.htm"></HEAD>
<BODY TEXT="#000000" LINK="#0000FF" VLINK="#800080" bgcolor=white>
<P><A HREF="unx38.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Previous Page"></A>
<A HREF="index.htm"><IMG SRC="blutoc.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="TOC"></A>
<A HREF="unx40.htm"><IMG SRC="blunext.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Next Page"></A>
<A HREF="index.htm"><IMG SRC="bluprev.gif" WIDTH = 32 HEIGHT = 32 BORDER = 0 ALT="Home"></A>
</P><UL>
<LI>
<A HREF="#I1">39 — Performance Monitoring</A></LI>
<UL>
<UL>
<UL>
<UL>
<LI>
<A HREF="#I3">By Ronald Rose</A></LI></UL></UL>
<LI>
<A HREF="#I4">Performance and Its Impact on Users</A></LI>
<LI>
<A HREF="#I5">Introduction to UNIX Performance</A></LI>
<LI>
<A HREF="#I6">Monitoring the Overall System Status</A></LI>
<UL>
<LI>
<A HREF="#I7">Monitoring System Status Using uptime</A></LI>
<LI>
<A HREF="#I8">Monitoring System Status Using perfmeter</A></LI>
<LI>
<A HREF="#I9">Monitoring System Status Using sar -q</A></LI>
<LI>
<A HREF="#I10">Monitoring System Status Using sar -u</A></LI></UL>
<LI>
<A HREF="#I11">Monitoring Processes with ps</A></LI>
<LI>
<A HREF="#I12">Monitoring Memory Utilization</A></LI>
<UL>
<LI>
<A HREF="#I13">UNIX Memory Management</A></LI>
<LI>
<A HREF="#I14">Monitoring Memory Performance Using vmstat</A></LI>
<LI>
<A HREF="#I15">Monitoring Memory Performance with sar -wpgr</A></LI>
<LI>
<A HREF="#I16">Multiprocessor Implications of vmstat</A></LI></UL>
<LI>
<A HREF="#I17">Monitoring Disk Subsystem Performance</A></LI>
<UL>
<LI>
<A HREF="#I18">Disk I/O Performance Optimization</A></LI>
<LI>
<A HREF="#I19">Relational Databases</A></LI>
<LI>
<A HREF="#I20">Checking Disk Performance with iostat and sar</A></LI>
<UL>
<LI>
<A HREF="#I21"> The iostat Command</A></LI>
<LI>
<A HREF="#I22">The sar -d Command</A></LI></UL>
<LI>
<A HREF="#I23">Monitoring File System Use with df</A></LI>
<UL>
<LI>
<A HREF="#I24">The df Command</A></LI></UL></UL>
<LI>
<A HREF="#I25">Monitoring Network Performance</A></LI>
<UL>
<LI>
<A HREF="#I26">Monitoring Network Performance with netstat -i</A></LI>
<LI>
<A HREF="#I27">Monitoring Network Performance Using spray</A></LI>
<LI>
<A HREF="#I28">Monitoring Network Performance with nfsstat -c</A></LI>
<LI>
<A HREF="#I29">Monitoring Network Performance with netstat</A></LI>
<LI>
<A HREF="#I30">Looking for Network Data Corruption with netstat -s</A></LI>
<LI>
<A HREF="#I31">Corrective Network Actions</A></LI></UL>
<LI>
<A HREF="#I32">Monitoring CPU Performance</A></LI>
<UL>
<LI>
<A HREF="#I33">Monitoring Multiprocessor Performance with mpstat</A></LI></UL>
<LI>
<A HREF="#I34">Kernel Tuning</A></LI>
<UL>
<LI>
<A HREF="#I35">Kernel Tables</A></LI>
<LI>
<A HREF="#I36">Checking System Tables with sar -v</A></LI>
<LI>
<A HREF="#I37">Displaying Tunable Kernel Parameters</A></LI>
<LI>
<A HREF="#I38">Displaying Current Values of Tunable Parameters</A></LI>
<LI>
<A HREF="#I39">Modifying the Configuration Information File</A></LI>
<LI>
<A HREF="#I40">The maxusers Parameter</A></LI>
<LI>
<A HREF="#I41">Parameters That Influence Paging and Swapping</A></LI>
<LI>
<A HREF="#I42">Conclusion of Kernel Tuning</A></LI></UL>
<LI>
<A HREF="#I43">Summary</A></LI></UL></UL></UL>
<H1 ALIGN="CENTER">
<CENTER><A ID="I1" NAME="I1">
<BR>
<FONT SIZE=5><A ID="I2" NAME="I2"></A><B>39 — Performance Monitoring</B>
<BR></FONT></A></CENTER></H1>
<H5 ALIGN="CENTER">
<CENTER><A ID="I3" NAME="I3">
<FONT SIZE=3><B>By Ronald Rose</B>
<BR></FONT></A></CENTER></H5>
<P>Chapter 38, "Accounting System," teaches about the UNIX accounting system, and the tools that the accounting system provides. Some of these utilities and reports give you information about system utilization and performance. In Chapter 18,
"What Is a Process," you learned that the sadc command, in combination with the shell scripts sa1 and sa2, enables you to automatically collect activity data. These automatic reports can create a documented history of how the system behaves,
which can be a valuable reference in times of performance problems. Requesting similar reports in an ad hoc manner is demonstrated in this chapter, as this method is usually most appropriate when investigating performance problems that are in progress.
<BR></P>
<P>In this portion of the book, you will learn all about performance monitoring. There are a series of commands that enable system administrators, programmers, and users to examine each of the resources that a UNIX system uses. By examining these resources
you can determine if the system is operating properly or poorly. More important than the commands themselves, you will also learn strategies and procedures that can be used to search for performance problems. Armed with both the commands and the overall
methodologies with which to use them, you will understand the factors that are affecting system performance, and what can be done to optimize them so that the system performs at its best.
<BR></P>
<P>Although this chapter is helpful for users, it is particularly directed at new system administrators that are actively involved in keeping the system they depend on healthy, or trying to diagnose what has caused its performance to deteriorate.
<BR></P>
<P>This chapter introduces several new tools to use in your system investigations and revisits several commands that were introduced in Chapter 19, "Administrative Processes."
<BR></P>
<P>The sequence of the chapter is not based on particular commands. It is instead based on the steps and the strategies that you will use during your performance investigations. In other words, the chapter is organized to mirror the logical progression
that a system administrator uses to determine the state of the overall system and the status of each of its subsystems.
<BR></P>
<P>You will frequently start your investigations by quickly looking at the overall state of the system load, as described in the section "Monitoring the Overall System Status." To do this you see how the commands uptime and sar can be used to
examine the system load and the general level of Central Processing Unit (CPU) loading. You also see how tools such as SunOS's perfmeter can be helpful in gaining a graphic, high-level view of several components at once.
<BR></P>
<P>Next, in the section "Monitoring Processes with ps," you learn how ps can be used to determine the characteristics of the processes that are running on your system. This is a natural next step after you have determined that the overall system
status reflects a heavier-than-normal loading. You will learn how to use ps to look for processes that are consuming inordinate amounts of resources and the steps to take after you have located them.
<BR></P>
<P>After you have looked at the snapshot of system utilization that ps gives you, you may well have questions about how to use the memory or disk subsystems. So, in the next section, "Monitoring Memory Utilization," you learn how to monitor
memory performance with tools such as vmstat and sar, and how to detect when paging and swapping have become excessive (thus indicating that memory must be added to the system).
<BR></P>
<P>In the section "Monitoring Disk Subsystem Performance," you see how tools such as iostat, sar, and df can be used to monitor disk Input/Output (I/O) performance. You will see how to determine when your disk subsystem is unbalanced and what to
do to alleviate disk performance problems.
<BR></P>
<P>After the section on disk I/O performance is a related section on network performance. (It is related to the disk I/O discussion because of the prevalent use of networks to provide extensions of local disk service through such facilities as NFS.) Here
you learn to use netstat, nfsstat, and spray to determine the condition of your network.
<BR></P>
<P>This is followed by a brief discussion of CPU performance monitoring, and finally a section on kernel tuning. In this final section, you will learn about the underlying tables that reside within the UNIX operating system and how they can be tuned to
customize your system's UNIX kernel and optimize its use of resources.
<BR></P>
<P>You have seen before in this book that the diversity of UNIX systems make it important to check each vendor's documentation for specific details about their particular implementation. The same thing applies here as well. Furthermore, modern developments
such as symmetric multiprocessor support and relational databases add new characteristics and problems to the challenge of performance monitoring. These are touched on briefly in the discussions that follow.
<BR></P>
<H3 ALIGN="CENTER">
<CENTER><A ID="I4" NAME="I4">
<FONT SIZE=4><B>Performance and Its Impact on Users</B>
<BR></FONT></A></CENTER></H3>
<P>Before you get into the technical side of UNIX performance monitoring, there are a few guidelines that can help system administrators avoid performance problems and maximize their overall effectiveness.
<BR></P>
<P>All too typically, the UNIX system administrator learns about performance when there is a critical problem with the system. Perhaps the system is taking too long to process jobs or is far behind on the number of jobs that it normally processes. Perhaps
the response times for users have deteriorated to the point where users are becoming distracted and unproductive (which is a polite way of saying frustrated and angry!). In any case, if the system isn't actually failing to help its users attain their
particular goals, it is at least failing to meet their expectations.
<BR></P>
<P>It may seem obvious that when user productivity is being affected, money and time, and sometimes a great deal of both, are being lost. Simple measurements of the amount of time lost can often provide the cost justification for upgrades to the system. In
this chapter you learn how to identify which components of the system are the best candidates for such an upgrade. (If you think people were unhappy to begin with, try talking to them after an expensive upgrade has produced no discernible improvement in
performance!)
<BR></P>
<P>Often, it is only when users begin complaining that people begin to examine the variables that are affecting performance. This in itself is somewhat of a problem. The system administrator should have a thorough understanding of the activities on the
system before users are affected by a crisis. He should know the characteristics of each group of users on the system. This includes the type of work that they submit while they are present during the day, as well as the jobs that are to be processed
during the evening. What is the size of the CPU requirement, the I/O requirement, and the memory requirement of the most frequently occurring and/or the most important jobs? What impact do these jobs have on the networks connected to the machine? Also
important is the time-sensitivity of the jobs, the classic example being payrolls that must be completed by a given time and date.
<BR></P>
<P>These profiles of system activity and user requirements can help the system administrator acquire a holistic understanding of the activity on the system. That knowledge will not only be of assistance if there is a sudden crisis in performance, but also
if there is a gradual erosion of it. Conversely, if the system administrator has not compiled a profile of his various user groups, and examined the underlying loads that they impose on the system, he will be at a serious disadvantage in an emergency when
it comes to figuring out where all the CPU cycles, or memory, have gone. This chapter examines the tools that can be used to gain this knowledge, and demonstrates their value.
<BR></P>
<P>Finally, although all users may have been created equal, the work of some users inevitably will have more impact on corporate profitability than the work of other users. Perhaps, given UNIX's academic heritage, running the system in a completely
democratic manner should be the goal of the system administrator. However, the system administrator will sooner or later find out, either politely or painfully, who the most important and the most influential groups are. This set of characteristics should
also somehow be factored into the user profiles the system administrator develops before the onset of crises, which by their nature obscure the reasoning process of all involved.
<BR></P>
<H3 ALIGN="CENTER">
<CENTER><A ID="I5" NAME="I5">
<FONT SIZE=4><B>Introduction to UNIX Performance</B>
<BR></FONT></A></CENTER></H3>
<P>While the system is running, UNIX maintains several counters to keep track of critical system resources. The relevant resources that are tracked are the following:
<BR></P>
<TABLE BORDER>
<TR>
<TD>
<P>CPU utilization</P>
<TD>
<P>Buffer usage</P>
<TR>
<TD>
<P>Disk I/O activity</P>
<TD>
<P>Tape I/O activity</P>
<TR>
<TD>
<P>Terminal activity</P>
<TD>
<P>System call activity</P>
<TR>
<TD>
<P>Context switching activity</P>
<TD>
<P>File access utilization</P>
<TR>
<TD>
<P>Queue activity</P>
<TD>
<P>Interprocess communication (IPC)</P>
<TR>
<TD>
<P>Paging activity</P>
<TD>
<P>Free memory and swap space</P>
<TR>
<TD>
<P>Kernel memory allocation (KMA)</P>
<TD>
<P>Kernel tables</P>
<TR>
<TD>
<P>Remote file sharing (RFS)</P>
<TD>
<P><BR></P></TABLE>
<P>By looking at reports based on these counters you can determine how the three major subsystems are performing. These subsystems are the following:
<BR></P>
<TABLE BORDER>
<TR>
<TD>
<PRE>
<BR>CPU
<BR></PRE>
<TD>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -