[gentoo-amd64] Re: System load during emerge

[Duncan]

Peter Humphrey <prh@××××××××××.uk> posted
200703041151.37846.prh@××××××××××.uk, excerpted below, on  Sun, 04 Mar
2007 11:51:37 +0000:

> I'm watching the emerge of mozilla-firefox with top (I've just set the
> java USE flag so that I can use some astronomy Web sites), and I'm
> puzzled. This is a dual-Opteron box with 4G memory, and I have it set up
> with 6G /tmp mounted on tmpfs. Top shows 0k of used swap, so I'm
> confident that I'm not doing any swapping. It should show me a total of
> up to 200% when the system is fully loaded.
>
> But top shows 49 - 50% wa, which I understand is I/O waiting time (even
> with the X term rolled up), cc1plus is showing only single-digit percent
> CPU, and the System and User CPU % are in the teens. I can get X to use
> 30-odd % by leaving the terminal on display, or 1% by rolling it up;
> that seems not to affect the other figures. No other user processes are
> running; only the background processes started by init and so on. What
> is the machine doing? Why does it not work harder at its allotted task?

Ouch!

There's a couple things to check.  First, you say /tmp is on tmpfs and in 
memory (no swap), but you don't mention where you have $PORTAGE_TMPDIR 
pointed.  That's set in make.conf and defaults to /var/tmp.  Here, /var/
tmp is a symlink pointing to /tmp so it doesn't really matter, but I have 
$PORTAGE_TMPDIR set to /tmp anyway.  You may also wish to tweak 
$PORTAGE_TMPFS (see the documentation in make.conf.example) and if you 
have FEATURES=buildpkg set, $PKG_TMPDIR (which I don't see documentation 
for ATM, but...).  If /tmp is tmpfs and it's of reasonable size (as yours 
is), there's little reason not to have all of them set to /tmp.

Second, for general disk access speed (IOW, not portage specific), if 
you've not checked it, emerge hdparm if necessary and see if your hard 
drives are using DMA.  If they aren't, you'll have MUCH slower disk i/o.  
Normally, if you are using the correct drivers, DMA should be activated 
by default, but it's not uncommon for folks to be using the generic 
drivers or some other specific hardware drivers that don't fully match 
the disk controller chipset they actually have, thus forcing the kernel 
to use compatibility mode.  Less commonly, a driver won't activate DMA 
even if it's the right one, or will, but at a lower speed (say UDMA66 
rather than UDMA133) than both the drive and the chipset can handle.  Of 
course, don't attempt to activate a higher UDMA mode than both drive and 
chipset support, or you'll risk data corruption.

Of course, also note that depending on the ebuild stage and how much of 
what it is accessing you already have cached, portage does do some non-
tmp I/O access.  In particular, it has to read the portage tree to 
discover dependencies, then distdir to see if the tarball is there (and 
if not fetch it), then untar it to $PORTAGE_TMPDIR and read and apply any 
patches.  At the beginning of the compile step it does the configure, 
which accesses and tests for all sorts of system binaries, so until those 
are cached (generally after the first thing using a configure script is 
emerged), there will be some disk I/O reading those.  If you have CCACHE 
set up, of course it must write the compiles to that as it goes, but 
unless your drives aren't using DMA, that shouldn't be a big issue.  
Finally, at the package (if FEATURES=buildpkg) and qmerge steps, it'll 
write to the pkg dir and to the general system as it installs.

There's also portage logging and associated log variables.  Again, this 
shouldn't be a big deal if you've got DMA on your drives, but it might be 
if you don't.

Finally, if it's writing anything to NFS mounts or the like over the 
network, or if you have distcc active, it's possible the wait is on the 
network, not on your local hard drives, of course depending on exactly 
how you are configured.


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@g.o mailing list