Windows XP acts strangely when hard drive is being heavily used

Question

This happens in two situations so far: when I use sabnzbd, after it's done downloading a file and is using par2.exe to stitch it together, and just now, when I'm defragmenting a hard drive from a VM I'm running.

Such use of the hard drive causes XP to become really unresponsive. A lot of GUI elements won't click, or have severely delayed clicks. In Chrome, whenever I go to a tab that I just opened a few minutes ago, the whole page reloads extremely slowly - I can see the page graphics loading line by line. A thing to note is that in the 1st case, my pagefile is on a completely separate hard drive than the one I'm running these operations on, while in the 2nd case, it's on a separate partition but the same hard drive. The same behavior occurs, though.

Any explanations as to why this happens? Any suggestions on how to get it to not happen?

I have 4GB of RAM and a dual core processor, and my CPU is not even close to 25% when these activities are going on, so it doesn't seem like a case of lack of resources. Is XP just not efficient at handling this situation?

Answer 1

Note: I'm assuming you have a spinning disk drive here. Performance metrics in these areas differ greatly for solid-state storage.

While a modern drive can sustain many tens of Mbytes per second when performing bulk reads and writes, both the operations you describe involve at least two locations on the disk so there is a lot of head movements involved. The latency of head movements has a massive effect on throughput because every time the drive needs to move the heads there is a delay in actually kicking them to the right place, a delay waiting for them to settle, and then a delay waiting for the right part of the disc to spin past. These delays are small on the own (not even 10ns per movement in total on average for most modern drives) but if the drive can push 100Mbyte/sec in full flow 10ms each movement wastes the time of 1Mbyte of data transfer. With a lot happening the drive can easily spend more time moving the heads around than it spends actually reading and writing data (read for a couple of 10s of ms, move head, read from there for a bit, move head, write for a few ms, move head...).

As you are defragmenting the drive the utility spends most of its time reading from one place on the disk and writing to another, a small number of blocks at a time. Extracting content from a par protected file set is even worse as there are at least two files being read (a source file and one or more parity files) as well as the output file being written to. Even just a simple copy operation on a large file has the effect. All this is excluding the head movements needed to keep directory structures and free-space maps up-to-date as blocks are moved and/or files extended. Running a VM can be similarly demanding depending on what the VM is doing at the time (and the VM will reduce the RAM available on the host machine to use as cache/buffers which may worsen the situation, and any write operation in the VM can be much more demanding than the same operation on the host directly especially if you use "growable" virtual drives).

With all this going on, if a GUI application needs to ask for even a little I/O it may get queued behind all the other stuff that is going on. Unless the application is fully multi-threaded this is likely to cause it to "block" waiting for the I/O operation to complete meaning it is not in a position to response to any messages (like "the user clicked you here") in the Windows event queue until it gets its turn. The more going on at once, the worse it will get, and you will not notice it in the "CPU busy" readings because the CPU isn't busy - it is sat waiting for IO operations to complete most of the time in these circumstances.

If you have two or more drives you can greatly reduce the effect this has on you by spreading the load over the drives. If you VM is on a separate drive from your primary OS they won't compete for I/O servicing when the VM is busy while the host is defragmenting the system partition. Also, extracting an archive from one drive and writing the output to another will be noticeably faster than extracting it to the same drive because the read operation is not directly competing with the write operation for head positioning on the one drive.

Answer 2

Defragmenting a hard drive on a machine will cause any machine to slow down. It is moving lots of data all over the place.

What kind of computer do you have? Do you have a single or dual core processor? How much ram? There are many factors that could come into play here.

Most likely it is a hanging process or something to that matter. You said you are running a VM. Those can take up a lot of resources if you are performing work in the VM and the host OS. VM's are very cpu intensive operations. It is running an entire other OS under your main OS.

Answer 3

The problem could be caused by the activity in question (e.g. defragmentation) taking up a very large percentage of the CPU. This leaves very little for the UI, hence the lack of responsiveness.

You could try lowering the priority of par2.exe or the defragmentation. Go to Task Manager > Processes, right click over the offending process and select Set Priority > Low.

Are you running a single core processor? Having 2 or more processors (or cores) will allow the UI to run on the one not being tasked.

Answer 4

It honestly sounds like you're doing too much all at once. What you're seeing is a bottleneck - the harddrive is being asked to do several things at once (some with more priority than others) so things like GUI clicks are "waiting" for their turn to be processed.