Disk being used

To identify how a disk is being actively used, one can generally check to see what files are opened. The section to see which files are used describes how to see which files are being accessed. The available technique(s) described in that section might be able to also provide details about how much disk activity is being generated for each of those files and, therefore, which file is causing lots of system activity.

This section focuses on verifying that the disk is being used, and focuses more on solutions that are disk-wide (or partition-wide or “mount point”-wide) in scope. Whether this page's advice is more helpful, or the file-focused solutions (which look at which files are used), may vary. (One possible influencing factor may be which operating system is used, and what software is bundled with that operating system.) Check out both of these sections, because both might be useful if there is suspicion (or definitely known fact) that a disk is busy.

Troubleshooting Overview

The first thing to do is to verify that the disk is being heavily utilized. If that is not the case, then heavy disk activity does not appear to be the cause of general system slowness, and so people may wish to check some other troubleshooting efforts. This section does discuss some ways of verify that the disk is being used.

A common cause of a disk being heavily used is when a “virtual memory” implementation is in heavy use. If that is known to be the case, or if the cause of heavy disk usage hasn't yet been determined, it may be very worthwhile to check whether the system is running out of memory.

If the slowness is not caused by running low on memory, and then using “virtual memory” as a result, then a great next step is to figure out what file (or files) are being heavily used. The section to see which files are used describes how to see which files are being accessed.

This page may provide some more details about specific steps that can be taken to try to handle disk slowness. However, after performing the above specific steps, this guide recommends looking at the short overview of troubleshooting disk-based system slowness before spending more time on other specific steps provided by this guide.

After following that overview, this guide may provide some helpful details about how to accomplish the desired goal.

Unix
[#obsydisk]: OpenBSD
[#obsacvds]: Heavy disk usage

(The systat program may be fairly old; section 6.4, “Monitoring System Performance”Installing and Operating 4.3BSD-tahoe UNIX on the VAX, page 49 mentions it.)

(Some additional discussion on systat is mentioned by troubleshooting low memory: OpenBSD's systat.)

Verify that the disk is being used with “ systat iostat ”, or running systat and pressing 2.

[#obslwdsk]: Unnecessary slowness caused by disk

Some of the techniques described in this section may help to verify that the disk is being used heavily, or even that the disk is what programs are waiting for. Some of these programs (systat's “vmstat” view, and the vmstat command) might not be as useful in determining which program is causing a problem, but will help to verify that problems are coming from the disk. (And, depending on the issue, might help to identify the cause of the problem, such as if the the Name-to-iNode translation is high.) Other programs, like top or ps, may help to indicate what programs are involved. However, those may be programs that use the disk occassionally, and so at least some of those programs may be victims of system slowness, rather than the primary causers of slowness. Still, narrowing down the cause of slowness (as being related to disk hardware, and not networking) can be quite useful.

Some additional information may be found by checking some info from using “ systat vmstat ” (and similar actions)systat vmstat”.

One option is to run “ systat iostat ”, or to just enter systat and then press 2. (Updates to the screen can be forced by tapping 1 and then 2 again. Some further details about using this program are in the section about using “ systat vmstat ” (and similar actions). However, that section may be rather primarily about the “vmstat” view.)

This may also be checked by using the vmstat info. (The advantage to using the vmstat screen is that it does show more information, so useful details about a wider variety of problems may be determined by using this screen.) To do this, see: using “ systat vmstat ” (and similar actions). This screen provides a bunch of information about system speed, as described by OpenBSD's web page for systat (in the section describing vmstat). Based on reading OpenBSD's web page for systat (where the manual says “Below the memory display”), it appears that one indicator of a disk being slow might actually be in the “Proc:” section (for the column labeled “d”).

Disks that are heavily used may be showing lots of “system” resource usage in top, although this might not be the only cause of “system” usage.

Check for paging

This can be done with “ swapctl -s ” or “ swapctl swap ” (or basically any other “ swapctl ” and then pressing the 6 key). Using “ pstat -p ” seems to provide the same output.

Another option, though, is to use the more generalized “vmstat” report (see using “ systat vmstat ” (and similar actions)) and checking some of the provided information, as described below.

Under the “PAGING” category, see if there are values. (Under the word “PAGING” will be the words in” and “out”. In the couple of lines below those words, to the right of the words “ops” and “pages”, will be numbers of paging is occuring. Or, it could be blank if there is no such activity.)

If the “ops” shows numbers, and pages is also showing numbers (e.g. ops shows 13 in and 865 out, and three are 13838 pages), this could represent an issue.

The statistics in the lower-right corner, “fmin” and everything lower, are all related to paging activity. (This detail is noted by OpenBSD's manual page for systat.) Some of that information may be cut off on a 25 row display (or a 24 row display, if a row is dedicated to a status bar for a terminal multiplexer). This is documented, where the manual page says “Certain information may be discarded when the screen size is insufficient for display.” (The manual page does mention the ability to “Scroll”, but what use is that when information is already discarded?)

Samples
systat vmstat

First, let's take a look at what some output looked like when the machine was operating responsively:

Here is another view. This time, the presented view is the view of a happier system.

An happy machine is shown with “systat vmstat”. (Note that this was created by using copy and paste after the output was sent over a terminal. At the time of this writing, it is unknown if some of those spaces were actually tabs.)

    1 users    Load 0.57 0.45 0.42                     Sat Sep  6 13:36:02 2014

            memory totals (in KB)            PAGING   SWAPPING     Interrupts
           real   virtual     free           in  out   in  out     1711 total
Active  1359220   1359220 22521988   ops                            800 clock
All     1950960   1950960 29550088   pages                          905 ipi
                                                                        ahci0
Proc:r  d  s  w    Csw   Trp   Sys   Int   Sof  Flt       forks         azalia1
     1    25      1677    70 36055     6   177   44       fkppw       1 re0
                                                          fksvm         re1
   0.0%Int   0.0%Sys   0.0%Usr   0.0%Nic 100.0%Idle       pwait       5 uhci3
|    |    |    |    |    |    |    |    |    |    |       relck         ehci1
                                                          rlkok         vge3
                                                          noram         ahci1
Namei         Sys-cache    Proc-cache    No-cache         ndcpy
    Calls     hits    %    hits     %    miss   %         fltcp
      172      172  100                                   zfod
                                                          cow
Disks   sd0   cd0   sd1   sd2                      203941 fmin
seeks                                              271921 ftarg
xfers                                                     itarg
speed    3K                                             8 wired         IPKTS
  sec   0.0                                               pdfre         OPKTS
[cursor]

Following are some real-life statistics that were taken when a computer started a virtual machine, and gave the virtual machine a decent chunk of memory, because of an incorrect belief that there was probably plenty of memory free.

An unhappy machine is shown with “systat vmstat”. (Note that this was created by using copy and paste after the output was sent over a terminal. At the time of this writing, it is unknown if some of those spaces were actually tabs.)

   1 users    Load 22.34 20.42 13.94                   Wed Feb 20 04:33:40 2013

            memory totals (in KB)            PAGING   SWAPPING     Interrupts
           real   virtual     free           in  out   in  out      166 total
Active  1045152   3395452   124736   ops     25  858                100 clock
All     1893864   4244164  1172576   pages     13731                    ahci0
                                                                        azalia1
Proc:r  d  s  w    Csw   Trp   Sys   Int   Sof  Flt       forks      12 re0
     9  8  5        54   460   195    66   135  480       fkppw       2 re1
                                                          fksvm         uhci4
   0.0%Int  96.6%Sys   0.5%Usr   0.0%Nic   2.8%Idle       pwait         ehci1
|    |    |    |    |    |    |    |    |    |    |    25 relck         vge3
================================================>      25 rlkok      52 ahci1
                                                          noram
Namei         Sys-cache    Proc-cache    No-cache      12 ndcpy
    Calls     hits    %    hits     %    miss   %         fltcp
       90       90  100                               396 zfod
                                                          cow
Disks   sd0   cd0   sd1   sd2                       16821 fmin
seeks                                               22428 ftarg
xfers    52                                        132528 itarg      47 IPKTS
speed 1802K                                             1 wired      45 OPKTS
[cursor]

Next is an unhappy machine (now showing more hits under the Sys-cache label, and reduced numbers shown to the right of the words “itarg” and “wired”.

An unhappy machine is shown with “systat vmstat”. (Note that this was created by using copy and paste after the output was sent over a terminal. At the time of this writing, it is unknown if some of those spaces were actually tabs.)

   1 users    Load 22.34 20.42 13.94                   Wed Feb 20 04:33:56 2013

            memory totals (in KB)            PAGING   SWAPPING     Interrupts
           real   virtual     free           in  out   in  out      165 total
Active  1044856   3410976   124656   ops     23  862                100 clock
All     1893944   4260064  1156676   pages     13789                    ahci0
                                                                        azalia1
Proc:r  d  s  w    Csw   Trp   Sys   Int   Sof  Flt       forks      12 re0
     9  7  5        54   461   221    64   126  486       fkppw       3 re1
                                                          fksvm         uhci4
   0.0%Int  97.4%Sys   0.5%Usr   0.0%Nic   2.1%Idle       pwait         ehci1
|    |    |    |    |    |    |    |    |    |    |    23 relck         vge3
=================================================      23 rlkok      50 ahci1
                                                          noram
Namei         Sys-cache    Proc-cache    No-cache      12 ndcpy
    Calls     hits    %    hits     %    miss   %         fltcp
      130      130  100                               400 zfod
                                                          cow
Disks   sd0   cd0   sd1   sd2                       16821 fmin
seeks                                               22428 ftarg
xfers    50                                        132513 itarg      32 IPKTS
speed 1800K                                             1 wired      29 OPKTS
[cursor]

Things can get even worse. Here, the system cache value is even higher, and the values next to “IPCKTS” and “IPCKTS” are close to ten times what they were before.

An unhappy machine is shown with “systat vmstat”. (Note that this was created by using copy and paste after the output was sent over a terminal. At the time of this writing, it is unknown if some of those spaces were actually tabs.)

   1 users    Load 23.48 22.91 19.37                   Wed Feb 20 04:56:15 2013

            memory totals (in KB)            PAGING   SWAPPING     Interrupts
           real   virtual     free           in  out   in  out      256 total
Active  1057216   4007376   107316   ops     39 6056                100 clock
All     1911284   4861444   555296   pages     10485                    ahci0
                                                                        azalia1
Proc:r  d  s  w    Csw   Trp   Sys   Int   Sof  Flt       forks      55 re0
     9  6  7       160   106  1035   155   281  100       fkppw      41 re1
                                                          fksvm         uhci4
   0.2%Int  94.3%Sys   0.2%Usr   0.0%Nic   5.3%Idle       pwait         ehci1
|    |    |    |    |    |    |    |    |    |    |    45 relck         vge3
===============================================        45 rlkok      60 ahci1
                                                          noram
Namei         Sys-cache    Proc-cache    No-cache       6 ndcpy
    Calls     hits    %    hits     %    miss   %       1 fltcp
      218      217  100                     1   0       7 zfod
                                                        1 cow
Disks   sd0   cd0   sd1   sd2                       16821 fmin
seeks                                               22428 ftarg
xfers    60                                        132292 itarg     312 IPKTS
speed  252K                                             1 wired     309 OPKTS
[cursor]

The incident was caused accidentally, and the result was that the computer performed the requested task through heavy use of swapping/paging, which caused the system to seem very slow to respond. Key observations are:

  • Interrupts show that “ahci1” regularly had interrupts. The ??? man page for the “ahci” driver identifies this as being related to “Advanced Host Controller Interface for Serial ATA”. Serial ATA (more commonly abbreviated as “SATA”) is related to disks, so activity by this driver does suggest that a disk is being used.
  • When the system was working well, the “PAGING” section and “SWAPPING” sections were blank. When the system was less responsive, there were active numbers under the “PAGING” columns (both the “PAGING” “in” column, and the “PAGING” “out” column).
  • System load was high (way over 1.0) when the system was slow/unresponsive.
  • The amount of “free” memory was much lower than when the machine worked well
  • There were some interrupts related to the “clock” and the network card drivers (“re0” and “re1”, in this case), and some “Sys-cache” hits.
  • In this view of a more responsive system, the only devices showing significant numbers of interrupts are “clock” and (which presumably stands for “inter-processor interrupt”, and might be used to processors to communicate with each other, or even for portions of a processor to communicate with each other). Seeing a value of around 950 interrupts for “ipi” didn't seem to be causing any problems (although post refers to a problematic system that had “ipi” interrupts of around a million).
  • There were some “Namei” calls. However, none of that seemed particularly related to what ended up being the problem.
    • In particular, the “Namei” “Calls” and the “Sys-cache” “hits” were very similar numbers (actually, in many cases those numbers were exactly identical), so that is probably not the source of the problem.
    • If the “Sys-cache” “hits” is well under “100%”, then there may be some higher values in the “No-cache” “miss” section. One possible cause of that particular situation is semi-famous due to a mention by the OpenBSD FAQ. Details are available at OpenBSD: if Name-to-iNode is high.

There are a number of differences between this output and the earlier output of a struggling system (which is believed to be the same system, captured at different times).

  • When the system was doing well, then to the right of the “Proc:” label, a column header titled “Sys” shows a much larger value (“36055”, rather than “195” through “1035”.)
  • When the system was doing well, The system varied at showing 99.8% Idle or 100% idle, so the CPU usage bar graph was not showing heavy percentage by “Sys”.
  • When the system was doing well, even after other parts of the screen filled up, the “IPCKTS” and “OPCKTS” was often blank, although such values might climb to a small number like 16. The “itarg” usage is also non-existant.
  • When the system was doing well, disk usage shows the disk's “speed” value as “3.0K” in the screen, although sometimes that section would just be blank. When the disk was being heavily used, much higher speed values (like “speed”) were being reported. In this case, high speed values were undesirable, because the high speeds of disk activity mean that the disk was being actively used, and that was leading to the system feeling unresponsive.

Namely, it is noteworthy that the interrupts are not showing by the “ahci1”, whereas some of the other examples showed “ahci1” taking up over 15% of the interrupts on ths report. (The “ahci1” device is presumably related to the SATA hard drives that used AHCI.)

Remember, the OpenBSD manual page for systat describes what is shown by this “vmstat” view. The descriptions there may be fairly brief, but might be enough to generate some useful search terms if more information is needed.

top

Next shown is the output of running top. It looks like many systems are in a state of “biowait”. Speculation: that may refer to waiting on I/O with a block device, meaning that it is waiting for a disk. The top-left of page 6 of “Running and tuning OpenBSD network servers in a production environment”, by by Philipp Bühler and Henning Brauer indicates that a value of “getblk” would indicate that a program is waiting for a block device (like a disk).

An unhappy machine is shown with “top”. (Note that this was created by using copy and paste after the output was sent over a terminal. At the time of this writing, it is unknown if some of those spaces were actually tabs.)

load averages: 21.79, 21.01, 15.26                   sysname.thenetnam 04:38:06
122 processes: 4 running, 117 idle, 1 on processor
CPU states:  0.6% user,  0.0% nice, 98.1% system,  0.0% interrupt,  1.3% idle
Memory: Real: 1018M/1849M act/tot  Free: 122M  Swap: 2553M/3319M used/tot
Process ID to highlight:
  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
29003 root      28    0  428M   25M run       -       531:40  0.00% qemu
17762 root      -5    0  431M   23M sleep     biowait 524:56  0.00% qemu
 3737 root      -5    0  427M   12M sleep     biowait 354:31  0.00% qemu
12282 root      -5    0  431M   13M sleep     biowait 350:42  0.00% qemu
32000 root      -5    0  430M   22M sleep     biowait 337:35  0.00% qemu
12349 root      28    0  430M   28M run       -       330:48  0.00% qemu
 6078 root       2    0  430M 6880K sleep     poll    321:38  0.00% qemu
 1959 root      28    0  431M   22M run       -       321:06  0.00% qemu
25456 root      -5    0  430M   12M sleep     biowait 314:34  0.00% qemu
 4161 auser     28    0 9448K 2656K run       -        33:08  0.00% tmux
 6742 root       2    0 1028K  548K sleep     kqread    2:36  0.00% tmux
 1053 _tcpdump  -5    0   11M 3276K sleep     biowait   2:29  0.00% tcpdump
 4327 root       2    0 7320K 1108K idle      select    2:18  0.00% smbd
10410 root       2    0 1180K 1144K sleep     select    0:27  0.00% sendmail
29316 auser      2    0 1008K  188K idle      select    0:26  0.00% ssh
23291 _pflogd    4    0  592K  120K sleep     bpf       0:22  0.00% pflogd
23823 root      -5    0 3036M  858M sleep     biowait   0:22  0.00% qemu

and, after fixed, top looked much nicer. Notice that instead of a high percentage of “system”, there is now a high percentage of “idle”. Also, not nearly as many processes were in a state of “sleep” because of “biowait”.

load averages: 14.70, 20.93, 19.03                   sysname.thenetnam 04:59:08
120 processes: 8 running, 111 idle, 1 on processor
CPU states:  0.1% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.8% idle
Memory: Real: 259M/561M act/tot  Free: 1410M  Swap: 1789M/3319M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
29003 root       2    0  428M   40M run       -       531:41  0.05% qemu
17762 root       2    0  431M   34M run       -       524:57  0.00% qemu
 3737 root       2    0  427M   15M run       -       354:32  0.00% qemu
12282 root      -5    0  431M   23M sleep     biowait 350:43  0.00% qemu
32000 root       2    0  430M   32M run       -       337:36  0.00% qemu
12349 root       2    0  430M   42M run       -       330:49  0.00% qemu
 6078 root       2    0  430M   15M run       -       321:38  0.00% qemu
 1959 root       2    0  431M   28M run       -       321:07  0.00% qemu
25456 root       2    0  430M   25M run       -       314:35  0.00% qemu
 4161 auser      2    0 9448K 4756K sleep     kqread   33:08  0.00% tmux
 6742 root       2    0 1028K  548K sleep     kqread    2:36  0.00% tmux
 1053 _tcpdump   4    0   11M 9636K sleep     bpf       2:29  0.00% tcpdump
 4327 root       2    0 7320K 1532K idle      select    2:18  0.00% smbd
10410 root       2    0 1180K 1144K sleep     select    0:27  0.00% sendmail
29316 auser      2    0 1008K  580K sleep     select    0:26  0.00% ssh
23291 _pflogd    4    0  592K  120K sleep     bpf       0:22  0.00% pflogd
14266 auser     -6    0  356K  140K sleep     piperd    0:20  0.00% tee

Following is a log of a system that shows high “system” usage.

load averages: 22.28, 20.94, 14.86                   sysname.thenetnam 04:36:32
122 processes: 9 running, 112 idle, 1 on processor
CPU states:  0.6% user,  0.0% nice, 99.1% system,  0.0% interrupt,  0.3% idle
Memory: Real: 1019M/1849M act/tot  Free: 122M  Swap: 2463M/3319M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
29003 root      28    0  428M   25M run       -       531:40  0.05% qemu
12349 root      28    0  430M   26M run       -       330:48  0.05% qemu
17762 root      -5    0  431M   23M sleep     biowait 524:56  0.00% qemu
 3737 root      -5    0  427M   12M sleep     biowait 354:31  0.00% qemu
12282 root      -5    0  431M   11M sleep     biowait 350:42  0.00% qemu
32000 root      -5    0  430M   21M sleep     biowait 337:35  0.00% qemu
 6078 root      28    0  430M 8488K run       -       321:38  0.00% qemu
 1959 root      -5    0  431M   21M sleep     biowait 321:06  0.00% qemu
25456 root      28    0  430M   12M run       -       314:34  0.00% qemu
 4161 auser     28    0 9448K 2752K run       -        33:08  0.00% tmux
 6742 root       2    0 1028K  548K sleep     kqread    2:36  0.00% tmux
 1053 _tcpdump  28    0   11M 3416K run       -         2:29  0.00% tcpdump
 4327 root       2    0 7320K 1176K sleep     select    2:18  0.00% smbd
10410 root       2    0 1180K 1148K run       -         0:27  0.00% sendmail
29316 auser      2    0 1008K  188K idle      select    0:26  0.00% ssh
23291 _pflogd    4    0  592K  120K sleep     bpf       0:22  0.00% pflogd
23823 root      28    0 3036M  863M run       -         0:22  0.00% qemu

If this is an issue, then the cause of the high disk usage is (likely to be) paging/swapping. The cause of the paging/swapping is that something is using up more memory than is available. See: low memory: memory usage.

[#obnamich]: See if Name-to-iNode is high

Another possible indicator of slowness is if the Name-to-iNode translation is high. Specifically, to check the Name-to-iNode translation, review the area by where it says “Namei”. The “No-cache” “miss x %” represents likely slowness. Ideally the value will be zero, which will cause the reported value to show as blank. Close to ideal situations, which are probably not worth tinkering with in many simple cases, may show some other very low value such as being under 4%.

Note: If the Namei Calls are matching the Sys-cache hits, and so Sys-cache hits shows at 100%, then that could indicate that things (related to the Name-to-iNode translation) are okay. What is undesirable is to be seeing No-cache miss %.

If this is an issue, this might be easy to improve by adjusting how much memory is allocated to a specific task related to supporting the filesystem. The manual page for systat's vmstat display explains this is related to “name translations”. OpenBSD FAQ 14: section about optimizing maxvnodes (section titled “Size of the namei() cache”) (FAQ 14.18.2) better explains a solution, mentioning that this might be caused by using too low of a value for the sysctl called “kern.maxvnodes”. (This guide currently does not have a guide for what the value represents or how to choose a better value.) OpenBSD Manual: Section 3 (Subroutines): page about sysctl documents this sysctl by providing a description which is self-evident: “The maximum number of vnodes available on the system.”

Another command that may be quite useful is vmstat (which is the name of a command to run, and is different than the “vmstat” view of the systat program). Looking at the output of that command may also be a way to get some information quickly, so recording a copy of the output of that program may be a good thing to do if a system is still struggling. Understanding the output of that command can be viewed on pages 6 and 7 of “Running and tuning OpenBSD network servers in a production environment”, by by Philipp Bühler and Henning Brauer. One quick tidbit that those pages mention is that vmstat may show some different (and possibly tell-tale) information by using vmstat -s or vmstat -m (so save that information to text files if one is wishing to create a log while system performance is slow).

More Resources about OpenBSD (disk) performance
Other Unix systems

This guide does not have extensive/tested details. One may wish to try commands like vmstat or systat or iostat. (Or, perhaps lsof may be useful?) (Or, perhaps fstat or stat may be useful?)

Notice that a lot of those rcommended programs involve the word “stat”. So, running apropos may provide some options. If one of those commands exists, like vmstat (which might be more likely than some of the other options), check the bottom of its manual page. A command that could be used to do that may be:

env MANPAGER=cat man vmstat | tail -25

(Or, instead of cat, use most for more color. Also, instead of “ -25”, using “ -${LINES}” may work.)

It might also be true that /proc/ may provide some useful data.

DTrace one liners shows some command lines that use DTrace Tools (by Brendan Gregg). The iotop command from the related DTrace Toolkit may quickly show which programs use disk. This software may use the CDDL license. sar (see: Wikipedia page on “sar (Unix)”) may also be uesful for this?

Disk being busy in Microsoft Windows
Confirming busy-ness
Resource Monitor

In Windows 7, go to the Resource Monitor. Then check out the “Disk” tab.

Another option, for finding what proram might be using the disk, may be to use some process monitoring software. Process Hacker has a column called “I/O Total Rate”, which shows information about each process. That column can also be sorted, which may be the fasatest and easiest way to notice top culprits. (See: Information about Process Hacker.) Another option may be Process Explorer. (See information about Process Explorer.) Go to View, then “Select Columns...”. On the “Process Disk” tab, check some boxes. (Another option may be to check boxes on the “Process I/O” tab.)

Adjusting I/O priority
Adjusting I/O priority for already-running processes

Speaking of Process Hacker and Process Explorer: Priority may be adjustable. This was noticed thanks to SuperUser answer 462576 where David Solimano speculates this may be available starting with Windows Vista, since Vista's release was when I/O prioritization was believed to be added. information about Process Explorer

Using Process Hacker, access a process's context menu, choose Miscellaneous, then “I/O priority”. (See: Information about Process Hacker)

Or, using Process Explorer: Viewing the context menu of a program shows a “Set Priority” submenu. One of the options on that submenu is “Background: 4 (Low I/O and Memory Priority)”. This might be a way to manually interact in order to affect a currently running process.

Starting a new program with low I/O priority can be done, in Windows Vista and newer, by using the software PSExec (part of PSTools), part of the SysInternals software that is freely obtainable by Microsoft. The first time the software is run, a EULA dialog box will be shown, unless the -accepteula is specified on the command line. Although the program's help (shown when running the program without a parameter, and also shown on the program's home page) seems to indicate there is a -priority option, the earlier syntax seems more clear when it specifies -<priority> which is using notation that the “<priority>” is meant to be customized. (A test showed that “priority”, even used in addition to “background”, was being treated like an unrecognized option.) The priority option related to Vista's low I/O usage is specified by using the -background option.

C:\>psexec notepad

PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

notepad exited with error code 0.

C:\>

As shown above, the program will simply wait (after showing the blank line after the URL) until the program exits, so that the error code can be reported. Different results can be seen using the -d parameter.

C:\>psexec -d notepad

PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

notepad started with process ID 6148.

C:\>
Common fixes
Disk-heavy services

Some services are known to be rather disk intensive. Furthermore, they may be designed to speed up the system. In many cases, the approach just doesn't work: systems may crawl. They seem to have been recommended by Microsoft, but stopping them is often recommended because using these services has become known to be a recipe for disaster, at least on some computers. Trying to disable them is unlikely to cause any severe side effects except for possibly slowing down the system further, but very often this change has been known to simply cause the system to speed up, tremendously, with no change except for discontinuing to use this service.

To stop these services, try flipping them from Auto-Start to Manual Start, and then stop them. If they do end up getting started again, flip them from Manual Start to Disabled.

Index

The name of the service may be something like “Indexing Service” or “Windows Indexing”.

Windows Search

The name of the service may be something like “Windows Search” or “Windows Desktop Search” (“WDS”). The short name of the service is WSearch.

This is basically a newer implementation that tries to do the same sort of thing as the Index service. And, like its predecessor, it has been frequently found to be generally undesirable.

current speculation: Microsoft Outlook might try to use this service. Users may be encouraged to enable the service. The result can be far quicker searching in Outlook, while negatively affecting how the system runs as a whole (even with Microsoft Outlook is not running).

Superfetch

Introduced with Windows Vista. Zippy's comment to Mats Ekberg's SuperUser question on system/disk usage states, “If Superfetch is the problem behind your performance issues than you have a hardware or driver issue.” (That web page is currently the highly rated page on Google Seach for “svchost localsystemnetworkrestricted disk usage”, at the time of this writing.) However, there are multiple reports that this fixes the problem fine, so this does seem to be worth trying.

Prefetch

This has also been recommended (in addition to SuperFetch) as a potential culprit. (On a Windows 7 machine, this was simply not seen.)

In addition, services related to Windows Update have been known to cause notable slowdown. However, turning off those services may have the noteworthy side effect of disabling automatic updates, so be more careful about just applying that technique willy-nilly (without considering consequences).