Disk I/O as a bottleneck?

[Shachar Raindel]

Hi Omer,

On Sat, May 7, 2011 at 3:29 PM, Omer Zak <w1 at zak.co.il> wrote:
> I have a PC with powerful processor, lots of RAM and SATA hard disk.
> Nevertheless I noticed that sometimes applications (evolution E-mail
> software and Firefox[iceweasel] Web browser) have the sluggish feel of a
> busy system (command line response time remains crisp, however, because
> the processor is 4x2 core one [4 cores, each multithreads as 2]).
>
> I run the gnome-system-monitor all the time.
>
> I notice that even when those applications feel sluggish, only one or at
> most two CPUs have high utilization, and there is plenty of free RAM (no
> swap space is used at all).
>

The phenomena you are describing could be (though other explanations
are still possible) a result of a completely different issue:

Having 4 cores with 2 virtual cores on each means 8 threads could,
theoretically, run in parallel. However, there is a large number of
factors preventing 4 cores CPU from being 4 times faster than a single
core CPU. The most common are, as of time being,  the applications
themselves - many of them are not written in a manner which enables
them to use more than 1 CPU. Usually, it is either due to doing all of
the CPU intensive work in one thread (i.e. the thread which renders
the webpages to the screen in iceweasel) or due to coarse grain
locking (i.e. locking the entire mozilla application every time we do
garbage collection on the java-script heap, etc.).

There are also issues of resource contention (i.e. firefox has a big
working set, and therefore its speed is more affected by the amount of
time it takes to access the RAM than it is affected by the CPU power -
the CPU tends to mostly wait for data to arrive from the RAM), but
that is less likely the case according to your description.

When large amount of RAM is available, the chances that the
sluggishness is due to slow disk access are rather slow - Linux is
very aggressive about keeping everything in the cache, and if your
application was spending most of its time waiting for disk I/O, you
wouldn't have seen large CPU usage percentages - it was going into a
"sleep" state until the data arrives, and wouldn't affect the user CPU
usage percentage. To verify that, run top while the application is
sluggish, and check if it the CPU usage is mostly in the user code
(pressing "1" while top is running will show the per-CPU statistics in
the top half of the screen, the percentage next to "us" is the
relative amount of time the CPU spent running user code since the last
sample).

Good luck in hunting down your slowness.

--Shachar