Lemur zaprasza
Red Hat® Linux 6 Unleashed
Chapter 21: Advanced System Administration Previous
Sections in this Chapter: Basic Performance Analysis Momma Always Said to Be Nice! Graphical Monitoring Tools How Much Swap Is Enough? Previous SectionNext Section Chapter 21 Advanced System Administration by David Pitts A large portion of this book is devoted
Basic Performance Analysis Determining CPU Usage with vmstat Basic performance analysis is the process of identifying performance bottlenecks and involves a number of steps. The first step is to look at the big picture: Is the problem CPU- or I/O-related? If it is a CPU problem, what is the load average? You should probably check what processes are running and what is causing the problem. If it is an I/O problem, is it paging or normal disk I/O? If it is paging, increasing memory might help. You can also try to isolate the program or the user causing the problem. If it is a disk problem, is the disk activity balanced? If you have only one disk, you might want to install a second.The next section looks at several tools that you can use to determine the answers to the preceding questions. Determining CPU Usage with vmstat CPU usage is the first test on the list. There are many different ways to obtain a snapshot of the current CPU usage. The one I focus on here is vmstat. The vmstat command gives you several pieces of data, including the CPU usage. The following is the syntax for the command: $ vmstat interval [count] interval is the number of seconds between reports, and count is the total number of reports to give. If the count is not included, vmstat will run continuously until you stop it with Ctrl+C or kill the process.Here is an example of the output from vmstat: shell:/home/dpitts$ vmstat 5 5 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 1104 1412 10032 36228 0 0 10 8 31 15 7 4 24 0 0 0 1104 1736 10032 36228 0 0 0 3 111 18 1 1 99 0 0 0 1104 1816 10032 36228 0 0 0 1 115 23 2 2 96 0 1 0 1104 1148 10096 36268 8 0 7 4 191 141 4 6 91 0 0 0 1104 1868 9812 35676 6 0 2 10 148 39 25 4 70 The first line of the report displays the average values for each statistic since boot time. It should be ignored. For determining CPU used, you are interested in the last three columns, as indicated by the cpu heading. They are us, sy, and id: CPU Description us Percentage of CPU cycles spent on performing user tasks. sy Percentage of CPU cycles spent as system tasks. These tasks include waiting on I/O, performing general operating system functions, and so on. id Percentage of CPU cycles not used. This is the amount of time the system was idle. A high CPU time (or low idle time) is not necessarily indicative of an overall CPU problem. It could be that a number of batch jobs running just need rearranged. To determine that there is actually a CPU problem, it is important to monitor the CPU percentages for a significant period of time. If the percentages are high during this time, then there is definitely a problem.Next, look at a different section of the vmstat output. If the problem is not CPU-related, check whether it is a problem with paging or normal disk I/O. To determine whether it is a memory problem, look at the headings memory and swap: shell:/home/dpitts$ vmstat 5 5 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 1096 1848 4580 37524 0 0 9 8 8 17 7 3 29 1 0 0 1096 1424 4580 37980 0 0 92 10 125 24 94 4 3 2 0 0 1096 864 4536 38408 0 0 112 31 146 42 93 2 5 2 0 0 1096 732 4360 38480 10 0 98 7 146 48 97 3 1 Included in the vmstat command's output is a "snapshot" table detailing the status of your system's memory. The output includes Memory Description swpd The amount of virtual memory used (KB) free The amount of idle memory (KB) buff The amount of memory used as buffers (KB) cache The amount of memory left in the cache (KB) Swap Description (si) The amount of memory swapped in from disk (KB/s) so The amount of memory swapped to disk (KB/s) The most important of these fields is the swap in (si) column. This column shows paging that has previously been swapped out, even if it was done before the vmstat command was issued.The io section is used to determine whether the problem is with blocks sent in or out of the device: shell:/home/dpitts$ vmstat 5 5 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 1096 1848 4580 37524 0 0 9 8 8 17 7 3 29 1 0 0 1096 1424 4580 37980 0 0 92 10 125 24 94 4 3 2 0 0 1096 864 4536 38408 0 0 112 31 146 42 93 2 5 2 0 0 1096 732 4360 38480 10 0 98 7 146 48 97 3 1 The io section is described in the following table: IO Description bi The blocks sent to a block device (blocks/s) bo The blocks received from a block device (blocks/s) cs The number of context switches per second These fields run from several to several hundred (maybe even several thousand). If you are having a lot of in and out block transfers, the problem is probably here. Keep in mind, however, that a single reading is not indicative of the system as a whole; it's just a snapshot of the system at that time. There are three states in which the processes can exist. They are runtime, uninterrupted sleep, and swapped out: Procs Description r The number of processes waiting for runtime b The number of processes in uninterrupted sleep w The number of processes swapped out but otherwise able to run The number of processes waiting for runtime is a good indication that there is a problem. The more processes waiting, the slower the system. More than likely, you won't look at vmstat unless you already know there is a bottleneck somewhere, so the r field doesn't give you much vital information. top The top command provides another tool for identifying problems with a Linux system. The top command displays the top CPU processes. More specifically, top provides an ongoing look at processor activity in real time. It displays a listing of the most CPU-intensive tasks on the system and can provide an interactive interface for manipulating processes. The default is to update every five seconds. The following is an example of the output from top: 1:36am up 16 days, 7:50, 3 users, load average: 1.41, 1.44, 1.21 60 processes: 58 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 89.0% user, 8.5% system, 92.4% nice, 3.9% idle Mem: 63420K av, 62892K used, 528K free, 32756K shrd, 6828K buff Swap: 33228K av, 1096K used, 32132K free 38052K cached PID USER PRI NI SIZE RSS SHARE STATE LIB %CPU %MEM TIME COMMAND The following table explains each field: Field Description up The time the system has been up and the three load averages for the system. The load averages are the average number of processes ready to run during the last 1, 5, and 15 minutes. This line is just like the output of uptime. processes The total number of processes running at the time of the last update. This is also broken down into the number of tasks that are running, sleeping, stopped, and zombied. CPU states The percentage of CPU time in user mode, system mode, niced tasks, and idle. (Niced tasks are only those whose nice value is negative.) Time spent in niced tasks is also counted in system and user time, so the total is more than 100 percent. Mem Statistics on memory usage, including total available memory, free memory, used memory, shared memory, and memory used for buffers. Swap Statistics on swap space, including total swap space, available swap space, and used swap space. This and Mem are just like the output of free. PID The process ID of each task. USER The username of the task's owner. PRI The priority of the task. NI The nice value of the task. Negative nice values are lower priority. SIZE The size of the task's code plus data, plus stack space, in kilobytes. RSS The total amount of physical memory used by the task, in kilobytes. SHARE The amount of shared memory used by the task. STATE The state of the task, either S for sleeping, D for uninterrupted sleep, R for running, Z for zombied, or T for stopped or traced. TIME Total CPU time the task has used since it started. If cumulative mode is on, this also includes the CPU time used by the process's children that have died. You can set cumulative mode with the S command-line option or toggle it with the interactive command S. %CPU The task's share of the CPU time since the last screen update, expressed as a percentage of total CPU time. %MEM The task's share of the physical memory. COMMAND The task's command name, which is truncated if tasks have only the name of the program in parentheses (for example, (getty)). As you can probably tell from the server used to obtain the previously displayed top data, there are no current bottlenecks in the system.free is another good command for showing the amount of used and free memory: shell:/home/dpitts$ free total used free shared buffers cached Mem: 63420 61668 1752 23676 13360 32084 -/+ buffers: 16224 47196 Swap: 33228 1096 32132 The first line of output (Mem:) shows the physical memory. The total column does not show the physical memory used by the kernel, which is usually about a megabyte. The used column shows the amount of memory used. The free column shows the amount of free memory. The shared column shows the amount of memory shared by several processes. The buffers column shows the current size of the disk buffer cache. The cached column shows how much memory has been cached off to disk.The last line (Swap:) shows similar information for the swapped spaces. If this line is all zeroes, your swap space is not activated.To activate a swap space, use the swapon command. The swapon command tells the kernel that the swap space can be used. The location of the swap space is given as the argument passed to the command. The following example shows starting a temporary swap file: $ swapon /temporary_swap To automatically use swap spaces, list them in the /etc/fstab file. The following example lists two swap files for /etc/fstab: /dev/hda8 none swap sw 0 0 /swapfile none swap sw 0 0 To remove a swap space, use the swapoff command. Usually, this is necessary only when using a temporary swap space. Caution - If swap space is removed, the system will attempt to move any swapped pages into other swap space or to physical memory. If there isn't enough space, the system will freak out but will eventually come back (this is commonly called thrashing). The system will be unavailable during the time it is trying to figure out what to do with these extra pages. Also keep in mind that, depending upon how much real memory you have, the system may never figure out what to do with these pages. Red Hat® Linux 6 Unleashed
Chapter 21: Advanced System Administration Previous
Sections in this Chapter: Basic Performance Analysis Momma Always Said to Be Nice! Graphical Monitoring Tools How Much Swap Is Enough? Previous SectionNext Section © Copyright Macmillan USA. All rights reserved. |