Peter Humphrey <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [email protected] mailing list
