High load average on Lucid for nominal/idle system use

I am uploading a sar -P (load average) for another VM I have. Violet was kept unused with only one running application (terminal) and no other running programs. During the time of the sar captures, the system was kept unused. I would expect that a load average of 0.00 or 0.10 might be expected for lavg1.

Data collected from violet.

This is a fork from bug ID 574910 to deal with non EC high load averages on idle systems.

Are you sure there is no I/O? You say iotop doesn't show anything, but iotop is broken in Lucid.

(sigh) another drive by comment for karma points.

In the NFS situation I would expect NFS tasks to 'float high' in regular TOP. No such items are seen at the top of top. The 'meta' information in iotop does not seem to be totally broken. The Total Disk Read and Disk Write stats though may be not as accurate in their totals they still reflect activity under normal operation. The "zero" I speak of above is that line showing zero to a few byes of activity with rsync sending the LA1 to 6 or more.

The issue manifests itself in NFS copying via rsync, dd from /dev/zero to a usb device, and on SATA to SATA moves of large VDI files. If a simple dd=/dev/zero of=/path/to/usb/file bs=1024 count=1M sends the load average sky high (on two different guests on two different parents and one parent is running 10.04) something is wrong on 10.04. It did not operate this way before. I should not need to render my parent or guests useless moving 30 GB vdi images from one disk spindle to another. Nor should I need to "put up with" (as seen in the sar output attached to the case) load averages for idle systems that, for no apparent reason, migrate above 1.00 or more. If you had read my other posts on 574910 you would have noted that regressing the kernel to a 9.10 version improves the issue, but does not totally resolve it.

There are more instance types. See my posts in 574910.

NB: As to the "broken" state of iotop, Only CONFIG_TASK_DELAY_ACCT seems to be disabled in Lucid. CONFIG_TASK_DELAY_ACCT used for intra-task prioritization[1] and seems only to disable the SwapIn and IO %. So, unless I have missed other posts where it states that iotop is totally broken, the package is still valid for meta information. (BTW if CONFIG_TASK_DELAY_ACCT is disabled due to "performance" issues, why not disable SMP on all kernels too since that is a performance hit too for all non SMP hosts).

1 https://lists.ubuntu.com/archives/kernel-team/2009-December/008029.html

Close the case.

Hi Chris,

why should it be closed? Did you find a solution?

Yes, the solution is: Fedora core 13, or 14.

Since I installed FC13 XFCE on the parent host (home and work), and
using GNOME FC13/14 on guests things have been normal.

Today, 11/24, I rzipped several 4-9GB files in the 'parent' os. No
problem. No sluggish display. No guests "freezing" for several
seconds. Load averages of 4 and not ++(++(++10)).

I may take a gander at Ubuntu when the next LTS release comes out. That
may give me enough healing time to see that +5 months of my life wasted
is not such a long time. Heck it is better than 5 months in jail.

10.04 is/was a colossal waste of (my) time and energy. The problem may
persist, but for what I care at this point...

After giving up on Ubuntu in late September, I had enough free time, not
to mention faster hosts, in October/November to download and play with
Hercules, vm370\mvs-380 and music/sp on my home system (guest FC14). I
have had better support in the yahoo group for those products than the
'drive by' RTFM shouts on here. I might even try z/Linux. It took
almost two months for anyone (you) to notice on here to close the
case. I need to redo the mapping in my brain for apt-get install to
yum -y install. Otherwise the transition is less than it takes to get
used to AIX from Solaris.

Have a nice day

On 2010-11-24 02:29, imagine wrote:
> Hi Chris,
>
> why should it be closed? Did you find a solution?
>

--
------------------------------------------------------------------------
Chris | <email address hidden>
------------------------------------------------------------------------
This account for level two spam guarding.

Chris, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/635181/comments/7 regarding you requesting this be closed. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.