Linux Resource Monitoring

 

Linux Resource Monitoring

 


See Also:

  1. System Tuning Info for Linux Servers
  2. Performance Monitoring Tools for Linux


 

Overview

Performance monitoring is normally done as the first and last steps of a three-step process:

  1. Monitoring to identify the nature and scope of the resource shortages that are causing the performance problems

  2. The data produced from monitoring is analyzed and a course of action (normally performance tuning and/or the procurement of additional hardware) is taken to resolve the problem

  3. Monitoring to ensure that the performance problem has been resolved

System performance monitoring is an iterative process, with these steps being repeated several times to arrive at the best possible system performance.

All Linux systems have the following resources available for resource monitoring:

The following resources are available on a typical linux system:

free(1) Displays free and used memory statistics.
top(1) Displays CPU utilization and process-level statistics.
watch(1) Periodically executes the specified program, displaying fullscreen output.
vmstat(8) Displays a concise overview of process, memory, swap, I/O, system, and CPU utilization.
iostat(1) Displays CPU and I/O statistics.
mpstat(1) Displays individual CPU statistics on multiprocessor systems.
sadc(8) Collects system utilization data.
sa1(8) A script that runs sadc periodically.
sar(1) Produces system resource utilization reports.
sa2(8) Produces daily system resource utilization report files.
nice(1) Changes process scheduling priority.


 

free

The free command displays system memory utilization. Here is an example of its output:

$ free
             total       used       free     shared    buffers     cached
Mem:        481532     470164      11368          0     132596     273704
-/+ buffers/cache:      63864     417668
Swap:       979956      72664     907292

The Mem: row displays physical memory utilization, while the Swap: row displays the utilization of the system swap space, and the -/+ buffers/cache: row displays the amount of physical memory currently devoted to system buffers.

Since free by default only displays memory utilization information once, it is only useful for very short-term monitoring, or quickly determining if a memory-related problem is currently in progress. Although free has the ability to repetitively display memory utilization figures via its -s option, the output scrolls, making it difficult to easily see changes in memory utilization.

 

watch

A better solution than using free -s would be to run free using the watch command. For example, to display memory utilization every two seconds (the default display interval), use this command:

watch free

The watch command issues the free command every two seconds, after first clearing the screen. This makes it much easier to see how memory utilization changes over time, as it is not necessary to scan continually scrolling output. You can control the delay between updates by using the -n option, and can cause any changes between updates to be highlighted by using the -d option, as in the following command:

watch -n 1 -d free

The watch command runs until interrupted with [Ctrl]-[C]. The watch command is something to keep in mind; it can come in handy in many situations.

 

top

While free displays only memory-related information, the top command does a little bit of everything. CPU utilization, process statistics, memory utilization — top does it all. In addition, unlike the free command, top's default behavior is to run continuously; there is no need to use the watch command. Here is a sample display:

11:13am  up 1 day, 31 min,  5 users,  load average: 0.00, 0.05, 0.07
89 processes: 85 sleeping, 3 running, 1 zombie, 0 stopped
CPU states:  0.5% user,  0.7% system,  0.0% nice, 98.6% idle
Mem:  255508K av, 241204K used,  14304K free,    0K shrd,   16604K buff
Swap: 530136K av,  56964K used, 473172K free                64724K cached

  PID USER   PRI  NI  size  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 8532 ed      16   0  1156 1156   912 R     0.5  0.4   0:11 top
 1520 ed      15   0  4084 3524  2752 S     0.3  1.3   0:00 gnome-terminal
 1481 ed      15   0  3716 3280  2736 R     0.1  1.2   0:01 gnome-terminal
 1560 ed      15   0 11216  10M  4256 S     0.1  4.2   0:18 emacs
    1 root    15   0   472  432   416 S     0.0  0.1   0:04 init
    2 root    15   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root    15   0     0    0     0 SW    0.0  0.0   0:00 kapmd
    4 root    34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    5 root    15   0     0    0     0 SW    0.0  0.0   0:00 kswapd
    6 root    25   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    7 root    15   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    8 root    25   0     0    0     0 SW    0.0  0.0   0:00 mdrecoveryd
   12 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
   91 root    16   0     0    0     0 SW    0.0  0.0   0:00 khubd
  185 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
  186 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
  576 root    15   0   712  632   612 S     0.0  0.2   0:00 dhcpcd

The display is divided into two sections. The top section contains information related to overall system status — uptime, load average, process counts, CPU status, and utilization statistics for both memory and swap space. The lower section displays process-level statistics, the exact nature of which can be controlled while top is running.

Although top looks like a simple display-only program, this is not the case. top uses single character commands to perform various operations; if you are logged in as root, it is possible to change the priority and even kill any process on your system. Therefore, until you have reviewed top's help screen (type [?] to display it), it is safest to only type [q] (which exits top).

 

The GNOME System Monitor — A Graphical top

If you are more comfortable with graphical user interfaces, the GNOME System Monitor may be more to your liking. Like top, the GNOME System Monitor displays information related to overall system status, process counts, memory and swap utilization, and process-level statistics.

However, the GNOME System Monitor goes a step further by also including graphical representations of CPU, memory, and swap utilization, along with a tabular disk space utilization listing. Here is an example of the GNOME System Monitor's Process Listing display:

 

The GNOME System Monitor Process Listing Display

Additional information can be displayed for a specific process by first clicking on the desired process and then clicking on the More Info button.

To view the CPU, memory, and disk usage statistics, click on the System Monitor tab.

 

vmstat

For a more concise view of system performance, try vmstat. Using this resource monitor, it is possible to get an overview of process, memory, swap, I/O, system, and CPU activity in one line of numbers:

   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      0 524684 155252 338068   0   0     1     6  111   114  10   3  87
        

The process-related fields are:

The memory-related fields are:

The swap-related fields are:

The I/O-related fields are:

The system-related fields are:

The CPU-related fields are:

When vmstat is run without any options, only one line is displayed. This line contains averages, calculated from the time the system was last booted.

However, most system administrators do not rely on the data in this line, as the time over which it was collected varies. Instead, most administrators take advantage of vmstat's ability to repetitively display resource utilization data at set intervals. For example, the command vmstat 1 displays one new line of utilization data every second, while the command vmstat 1 10 displays one new line per second, but only for the next ten seconds.

In the hands of an experienced administrator, vmstat can be used to quickly determine resource utilization and performance issues. But to gain more insight into those issues, a different kind of tool is required — a tool capable of more in-depth data collection and analysis.

 

The Sysstat Suite of Resource Monitoring Tools

While the previous tools may be helpful for gaining more insight into system performance over very short time frames, they are of little use beyond providing a snapshot of system resource utilization. In addition, there are aspects of system performance that cannot be easily monitored using such simplistic tools.

Therefore, a more sophisticated tool is necessary. Sysstat is such a tool.

Sysstat contains the following tools related to collecting I/O and CPU statistics:

iostat

Displays an overview of CPU utilization, along with I/O statistics for one or more disk drives.

mpstat

Displays more in-depth CPU statistics.

Sysstat also contains tools that collect system resource utilization data and create daily reports based on that data. These tools are:

sadc

Known as the system activity data collector, sadc collects system resource utilization information and writes it to a file.

sar

Producing reports from the files created by sadc, sar reports can be generated interactively or written to a file for more intensive analysis.

The following sections explore each of these tools in more detail.

 

The iostat command

The iostat command at its most basic provides an overview of CPU and disk I/O statistics:

Linux 2.4.18-18.8.0 (pigdog.example.com)     12/11/2002

avg-cpu:  %user   %nice    %sys   %idle
           6.11    2.56    2.15   89.18

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0            1.68        15.69        22.42   31175836   44543290
          

Below the first line (which displays the system's kernel version and hostname, along with the current date), iostat displays an overview of the system's average CPU utilization since the last reboot. The CPU utilization report includes the following percentages:

Below the CPU utilization report is the device utilization report. This report contains one line for each active disk device on the system and includes the following information:

This is just a sample of the information that can be obtained using iostat.

 

The mpstat command

The mpstat command at first appears no different from the CPU utilization report produced by iostat:

Linux 2.4.18-14smp (pigdog.example.com)      12/11/2002

07:09:26 PM  CPU   %user   %nice %system   %idle    intr/s
07:09:26 PM  all    6.40    5.84    3.29   84.47    542.47
          

With the exception of an additional column showing the interrupts per second being handled by the CPU, there is no real difference. However, the situation changes if mpstat's -P ALL option is used:

Linux 2.4.18-14smp (pigdog.example.com)      12/11/2002

07:13:03 PM  CPU   %user   %nice %system   %idle    intr/s
07:13:03 PM  all    6.40    5.84    3.29   84.47    542.47
07:13:03 PM    0    6.36    5.80    3.29   84.54    542.47
07:13:03 PM    1    6.43    5.87    3.29   84.40    542.47
          

On multiprocessor systems, mpstat allows the utilization for each CPU to be viewed individually, making it possible to determine how effectively each CPU is being used.

 

The sadc command

As stated earlier, the sadc command collects system utilization data and writes it to a file for later analysis. By default, the data is written to files in the /var/log/sa/ directory. The files are named sa<dd>, where <dd> is the current day's two-digit date.

sadc is normally run by the sa1 script. This script is periodically invoked by cron via the file sysstat, which is located in /etc/crond.d. The sa1 script invokes sadc for a single one-second measuring interval. By default, cron runs sa1 every 10 minutes, adding the data collected during each interval to the current /var/log/sa/sa<dd> file.

 

The sar command

The sar command produces system utilization reports based on the data collected by sadc. As configured in Red Hat Linux, sar is automatically run to process the files automatically collected by sadc. The report files are written to /var/log/sa/ and are named sar<dd>, where <dd> is the two-digit representations of the previous day's two-digit date.

sar is normally run by the sa2 script. This script is periodically invoked by cron via the file sysstat, which is located in /etc/crond.d. By default, cron runs sa2 once a day at 23:53, allowing it to produce a report for the entire day's data.

 

Reading sar Reports

The format of a sar report produced by the default Red Hat Linux configuration consists of multiple sections, with each section containing a specific type of data, ordered by the time of day that the data was collected. Since sadc is configured to perform a one-second measurement interval every ten minutes, the default sar reports contain data in ten-minute increments, from 00:00 to 23:50 [2].

Each section of the report starts with a heading that illustrates the data contained in the section. The heading is repeated at regular intervals throughout the section, making it easier to interpret the data while paging through the report. Each section ends with a line containing the average of the data reported in that section.

Here is a sample section sar report, with the data from 00:30 through 23:40 removed to save space:

00:00:01          CPU     %user     %nice   %system     %idle
00:10:00          all      6.39      1.96      0.66     90.98
00:20:01          all      1.61      3.16      1.09     94.14
…
23:50:01          all     44.07      0.02      0.77     55.14
Average:          all      5.80      4.99      2.87     86.34
            

In this section, CPU utilization information is displayed. This is very similar to the data displayed by iostat.

Other sections may have more than one line's worth of data per time, as shown by this section generated from CPU utilization data collected on a dual-processor system:

00:00:01          CPU     %user     %nice   %system     %idle
00:10:00            0      4.19      1.75      0.70     93.37
00:10:00            1      8.59      2.18      0.63     88.60
00:20:01            0      1.87      3.21      1.14     93.78
00:20:01            1      1.35      3.12      1.04     94.49
…
23:50:01            0     42.84      0.03      0.80     56.33
23:50:01            1     45.29      0.01      0.74     53.95
Average:            0      6.00      5.01      2.74     86.25
Average:            1      5.61      4.97      2.99     86.43

There are a total of seventeen different sections present in reports generated by the default Red Hat Linux sar configuration; many are discussing in upcoming chapters.

Device major numbers can be found by using ls -l to display the desired device file in /dev/. Here is sample output from ls -l /dev/hda:

brw-rw----    1 root     disk       3,   0 Aug 30 19:31 /dev/hda
                  

The major number in this example is 3, and appears between the file's group and its minor number. [2]

Due to changing system loads, the actual time that the data was collected may vary by a second or two.


 

Resource Monitoring Tools

Red Hat Linux comes with a variety of resource monitoring tools. While there are more than those listed here, these tools are representative in terms of functionality. The tools we will look at are:

Let us look at each one in more detail.

 

free

The free command displays memory utilization data. Here is an example of its output:

             total       used       free     shared    buffers     cached
Mem:        255508     240268      15240          0       7592      86188
-/+ buffers/cache:     146488     109020
Swap:       530136      26268     503868

The Mem: row displays physical memory utilization, while the Swap: row displays the utilization of the system swap space, while the -/+ buffers/cache: row displays the amount of physical memory currently devoted to system buffers.

Since free by default only displays memory utilization information once, it is only useful for very short-term monitoring. Although free has the ability to repetitively display memory utilization figures via its -s option, the output simply scrolls, making it difficult to easily see changes in memory utilization.

A better solution would be to run free using the watch command. For example, to display memory utilization every two seconds, use this command:

watch free

You can control the delay between updates by using the -n option, and can cause any changes between updates to be highlighted by using the -d option, as in the following command:

watch -n 1 -d free

The watch command will run until interrupted with [Ctrl]-[C]. Make sure you remember watch; it can come in handy in many situations.

 

top

While free displays only memory-related information, the top command does a little bit of everything. CPU utilization, process statistics, memory utilization — top does it all. In addition, unlike the free command, top's default behavior is to run continuously; no need for the watch command here. Here is a sample display:

11:13am  up 1 day, 31 min,  5 users,  load average: 0.00, 0.05, 0.07
89 processes: 85 sleeping, 3 running, 1 zombie, 0 stopped
CPU states:  0.5% user,  0.7% system,  0.0% nice, 98.6% idle
Mem:  255508K av, 241204K used,  14304K free,    0K shrd,   16604K buff
Swap: 530136K av,  56964K used, 473172K free                64724K cached

  PID USER   PRI  NI  size  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 8532 ed      16   0  1156 1156   912 R     0.5  0.4   0:11 top
 1520 ed      15   0  4084 3524  2752 S     0.3  1.3   0:00 gnome-terminal
 1481 ed      15   0  3716 3280  2736 R     0.1  1.2   0:01 gnome-terminal
 1560 ed      15   0 11216  10M  4256 S     0.1  4.2   0:18 emacs
    1 root    15   0   472  432   416 S     0.0  0.1   0:04 init
    2 root    15   0     0    0     0 SW    0.0  0.0   0:00 keventd
    3 root    15   0     0    0     0 SW    0.0  0.0   0:00 kapmd
    4 root    34  19     0    0     0 SWN   0.0  0.0   0:00 ksoftirqd_CPU0
    5 root    15   0     0    0     0 SW    0.0  0.0   0:00 kswapd
    6 root    25   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    7 root    15   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    8 root    25   0     0    0     0 SW    0.0  0.0   0:00 mdrecoveryd
   12 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
   91 root    16   0     0    0     0 SW    0.0  0.0   0:00 khubd
  185 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
  186 root    15   0     0    0     0 SW    0.0  0.0   0:00 kjournald
  576 root    15   0   712  632   612 S     0.0  0.2   0:00 dhcpcd

The display is separated into two main parts. The top section contains information related to overall system status, process counts, along with memory and swap utilization. The lower section displays process-level statistics, the exact nature of which can be controlled while top is running.

Although top looks like a simple display-only program, this is not the case. If you are logged in as root, it is possible to change the priority and even kill any process on your system.

Therefore, make sure you read the top man page before using it.

 

gnome-system-monitor — A Graphical top

If you are more comfortable with graphical user interfaces, gnome-system-monitor may be more to your liking. Like top, gnome-system-monitor displays information related to overall system status, process counts, memory and swap utilization, and process-level statistics.

However, gnome-system-monitor goes a step further by including displays disk space utilization — something that top does not do at all.

 

The sysstat Suite of Resource Monitoring Tools

While the previous tools may be helpful for gaining more insight into system performance over very short time frames, they are of little use beyond providing a snapshot of system resource utilization. In addition, there are aspects of system performance that cannot be easily monitored using such simplistic tools.

Therefore, a more sophisticated tool is necessary. sysstat is such a tool.

sysstat contains the following commands related to collecting I/O and CPU statistics:

iostat

Displays I/O statistics for one or more disk drives. The statistics returned can include read and write rates per second, average wait, service, and CPU utilization, and more.

mpstat

Displays CPU statistics.

However, the most versatile and sophisticated tools that are part of sysstat are those related to the sar command. Collectively these tools:

The tools that perform these tasks are:

sadc

sadc is known as the system activity data collector. It collects system resource utilization information and writes it to files in the /var/log/sa/ directory. The files are named sa<dd>, where <dd> is the current day's two-digit date.

sa1

sa1 is a script that runs sadc to perform the actual data collection, and is run by cron at regular intervals throughout the day.

sar

sar produces reports from the files created by sadc. The report files written to /var/log/sa/, and are named sar<dd>, where <dd> is the two-digit representations of the previous day's date.

sa2

sa2 is a script that uses sar to write a daily system resource utilization report. sa2 is run by cron once at the end of each day.

isag

isag graphically displays data collected by sadc.

sa

Summarizes system accounting information.

The sysstat tools should be part of every system administrator's resource monitoring tool bag.


 

What to Monitor?

As stated earlier, the resources present in every system are CPU power, bandwidth, memory, and storage. At first glance, it would seem to be that monitoring would consist of just looking at these four different things.

Unfortunately, it is not that simple. For example, consider a disk drive. What things might you want to know about its performance?

There are more ways of looking at disk drive performance; these points have only scratched the surface. The main thing to keep in mind is that there are many different types of data for each resource.

The following sections look at the types of utilization information that would be helpful for each of the major resource types.

 

Monitoring CPU Power

In its most basic form, monitoring CPU power can be no more difficult than seeing if CPU utilization ever reaches 100%. If CPU utilization stays below 100%, no matter what the system is doing, there is additional processing power available for more work.

However, it is a rare system that does not reach 100% CPU utilization at least some of the time. That is when it becomes important to look at more detailed CPU utilization data. By doing so, it becomes possible to start determining where the majority of your processing power is being consumed. Here are some of the more popular CPU utilization statistics:

User Versus System

The percentage of time spent performing user-level processing versus system-level processing can point out whether a system's load is primarily due to running applications, or due to operating system overhead. High user-level percentages tend to be good (assuming users are not experiencing unsatisfactory performance), while high system-level percentages tend to point toward problems that will require further investigation.

Context Switches

A context switch happens when the CPU stops running one process and starts running another. Because each context switch requires the operating system to take control of the CPU, excessive context switches and high levels of system-level CPU consumption tend to go hand-in-hand.

Interrupts

As the name implies, interrupts are situations where the processing being performed by the CPU is abruptly changed. Interrupts generally occur due to hardware activity (such as an I/O device completing an I/O operation) or due to software (such as software interrupts that control application processing). Because interrupts must be serviced at a system level, high interrupt rates lead to higher system-level CPU consumption.

Runnable Processes

A process may be in different states. For example, it may be:

  • Waiting for an I/O operation to complete

  • Waiting for the memory management subsystem to handle a page fault

In these cases, the process has no need for the CPU.

However, eventually the process state changes, and the process becomes runnable. As the name implies, a runnable process is one that is capable of getting work done as soon as it is scheduled to receive CPU time. However, if more than one process is runnable at any given time, all but one [1] of the runnable processes must wait for their turn at the CPU. By monitoring the number of runnable processes, it is possible to determine how CPU-bound your system is.

Other performance data that impacts CPU utilization tends to revolve around different services that the operating system provides to processes. They may include statistics on memory management, I/O processing, and so on. These statistics also reveal that, when system performance is monitored, there are no boundaries between the different statistics. In other words, CPU utilization statistics may end up pointing to a problem in the I/O subsystem, or memory utilization statistics may reveal an application design flaw.

Therefore, when monitoring system performance, it is not possible to look at any one statistic in complete isolation; only by viewing the overall picture will it be possible to extract meaningful information from any performance statistics you gather.

 

Monitoring Bandwidth

Monitoring bandwidth is more elusive than the other resources described here. The reason for this is due to the fact that performance statistics tend to be device-based, while most of the places where bandwidth is important tend to be the buses that connect devices. In those instances where more than one device shares a common bus, you might see reasonable statistics for each device, but the aggregate load those devices place on the bus would be much greater.

Another challenge to monitoring bandwidth is that there can be circumstances where statistics for the devices themselves may not be available. This is particularly true for system expansion buses and datapaths [2]. However, even though 100% accurate bandwidth-related statistics may not always be available, there is often enough information to make some level of analysis possible, particularly when related statistics are taken into account.

Some of the more common bandwidth-related statistics are:

Bytes received/sent

Network interface statistics provide an indication of the bandwidth utilization of one of the more visible buses — the network.

Interface counts and rates

These network-related statistics can give indications of excessive collisions, transmit and receive errors, and more. Through the use of these statistics (particularly if the statistics are available for more than one system on your network), it is possible to perform a modicum of network troubleshooting even before the more common network diagnostic tools are used.

Transfers per Second

Normally collected for block I/O devices, such as disk and high-performance tape drives, this statistic is a good way of determining whether a particular device's bandwidth limit is being reached. Due to their electromechanical nature, disk and tape drives can only perform so many I/O operations every second; their performance rapidly degrades as this limit is reached.

 

Monitoring Memory

If there is one area where a wealth of performance statistics can be found, it is in the area of monitoring memory utilization. Due to the inherent complexity of today's demand-paged virtual memory operating systems, memory utilization statistics are many and varied. It is here that the majority of a system administrator's work with resource management takes place.

The following statistics represent a cursory overview of commonly-found memory management statistics:

Page Ins/Page Outs

These statistics make it possible to gauge the flow of pages from system memory to attached mass storage devices (usually disk drives). High rates for both of these statistics can mean that the system is short of physical memory and is thrashing.

Active/Inactive Pages

These statistics show how heavily memory resident pages are used. A lack of inactive pages can point toward a shortage of physical memory.

Free, Shared, Buffered, and Cached Pages

These statistics provide additional detail over the more simplistic active/inactive page statistics. By using these statistics, it is possible to determine the overall mix of memory utilization.

Swap Ins/Swap Outs

These statistics show the system's overall swapping behavior. Excessive rates here can point to physical memory shortages.

Successfully monitoring memory utilization requires a good understanding of how demand-paged virtual memory operating systems work. While such a subject alone could take up an entire book, the basic concepts are discussed in Chapter 4 Physical and Virtual Memory. This chapter, along with time spent monitoring a system, gives you the the necessary building blocks to learn more about this subject.

 

Monitoring Storage

Monitoring storage normally takes place at two different levels:

The reason for this is that it is possible to have dire problems in one area, and no problems whatsoever in the other. For example, it is possible to cause a disk drive to run out of disk space without once causing any kind of performance-related problems. Likewise, it is possible to have a disk drive that has 99% free space, yet is being pushed past its limits in terms of performance.

However, it is more likely that the average system will experience varying degrees of resource shortages in both areas. Because of this, it is also likely that — to some extent — problems in one area will impact the other. Most often this type of interaction takes the form of poorer and poorer I/O performance as a disk drive nears 0% free space although, in cases of extreme I/O loads, it might be possible to slow I/O throughput to such a level that applications will no longer run properly.

In any case, the following statistics are useful for monitoring storage:

Free Space

Free space is probably the one thing that all system administrators watch closely; it would be a rare administrator that never checks on free space (or has some automated way of doing so).

File System-Related Statistics

These statistics (such as number of files/directories, average file size, etc.) provide additional detail over a single free space percentage. As such, these statistics make it possible for system administrators to configure the system to give the best performance, as the I/O load imposed by a file system full of many small files is not the same as that imposed by a file system filled with one massive file.

Transfers per Second

This statistic is a good way of determining whether a particular device's bandwidth limitations are being reached.

Reads/Writes per Second

A slightly more detailed breakdown of the transfers per second statistic, these allow the system administrator to more fully understand the nature of the I/O loads a storage device is experiencing. This can be critical, as some storage technologies have widely different performance characteristics for read versus write operations.

Assuming a single-processor computer system. [2]

More information on buses, datapaths and bandwidth is available in Chapter 3 Bandwidth and Processing Power.



 

Home