On Sunday 04 March 2007 16:09:03 Duncan wrote: > Peter Humphrey <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sun, 04 Mar > > > What is the machine doing? > > 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.
It's not long since we discussed this. It's set to /tmp, and so is PKG_TMPDIR. > 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. Hdparm is installed and does set DMA on. The only disk access I can foresee portage doing is to write its log file. Could that really consume as much time as I'm seeing? Seems unlikely to me. [Later...] I've now found that if I run "hdparm -d1 /dev/sda" from an X terminal I get "HDIO_SET_DMA failed: Inappropriate ioctl for device", but when /etc/init.d/hdparm is run during boot I see [ok] for each drive. Looks like I've got some exploring to do. > 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. As I said, I was watching firefox being compiled. All the preliminary stages had been completed by then. All the source code should have been in memory, but I can't say the same for any other libraries. On the other hand, just how much time is needed to load all the development libraries needed for this compilation? > 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. Yes, that's the only thing I can think of. > 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. I did play with distcc but found it unreliable on a large package, so I've removed it from make.conf. I don't use NFS or any other networked operations that I can think of. Thanks for the suggestions. -- Rgds Peter -- [email protected] mailing list
