Dan circulated the following internally, but I thought it was cool enough to share with everyone out there. It seems there’s a very slick project to chart boot time performance across a variety of GNU/Linux systems. This makes it much easier to spot performance bottlenecks and improve boot time performance.
It would be really interesting to see this on a Solaris system for two reasons. First, we have the Service Management Facility which significantly parallelizes boot. Having a chart like this would let us see just how well it accomplishes this task. Second, DTrace provides a far superior mechanism for gathering data. The current project uses a combination of top and iostat sampling to gather data. With DTrace, we can get much more accurate data, and do cool stuff like associate I/O with individual processes, track interrupt activity, or gather performance data well before init(1M) begins executing. Our performance team has had a variation on this for a while now, using DTrace to track “events of interest” in order to analyze boot time regressions, but it’s presentation is nowhere near that of this tool.
Some of us have downloaded the software and are beginning to poke around with some D scripts. Stay tuned…
11 Responses
Knoppix is using the -sort option of mkisofs to minimize the head movement in the CD-ROM drive during boot (the weights are derived from access time stamps). While only used during install and emergency operations, it might still be interesting to be quicker in single user mode on an older CD-ROM drive…
We are constantly measuring boot time for Solaris builds, too.
We would consider it a regression if boot times increase.
Interestingly, on one of my test machines at home, I can get
to a login prompt on Solaris 10 in about 12-13 seconds…
— richard
I haven’t actually noticed any improvement
on my machines but, for networked systems,
waiting for spanning tree on the network
switches seems to be the limiting factor.
And that’s a lot longer than the times that
are being talked about. (The Solaris boxes
seem to wait until the nameservice is ready;
we had to fix the ypbind startup on our Linux machines so that it waited longer and really did start.)
I find Solaris installs to be much slower than Fedora installs on the same hardware. Maybe the install needs some D loving.
Wanted to also point out 2 blog posts which describe a Solaris 10 install from a Linux user (This is similar to what I felt when I installed b69)
Solaris installation Part 1
Solaris installation Part 2
I will be really interested to see how you get on with the results on Solaris 10. Are you going to set up a mailing alias internally or externally when Open Solaris is set up? I am sure lots of people would like to see how the combination of dtrace and Solaris 10 features be put into practical actions 🙂
XP does some tricks to speed up disk. First. it tracks the information about what portions of the disk are used when booting, or when a app starts up. With that information in place, it “preloads” all the neccesary data from disk to memory. Doing this. you can fetch all the needed data with a few reads instead of pagefaulting or reading files with small reads, and this speeds up the boot.
Also, the defragmenter analizes all that information and places the programs which are used more often in the places of the disk where the can be loaded faster. In fact, the defragmenter starts up automatically ever three days and does all this in the background if the box is idle, without you noticing it.
I know we hate defragmenters in the unix world, but the above example shows that a defragmentation API is not a bad idea at all. Solaris and linux kernels can keep a file unfragmented, but they don’t (can’t) know what programs are used more often. XP may not be our preffered OS but in the desktop field is ahead of us (not for long time, I hope)
Mac OS X uses similar tricks, if you’re curious you can look at the Darwin sources, it’s all there!
I’m afraid that all the optimizations you do with scripts startup et all. won’t be enought, they’ll be faster but I doubt they’re the real fix for the problem. We need something like the XP/mac os x “preloaders”, IMHO.
I’ve also though about things like “process freezing” (pause a process and store its image on disk and stop it, then awake it when you want) that could help greatly for desktops. If we could store on disk the process imagen of ej: evolution, and restore it when you switch on your computer again, 1) it’d be faster (no startup costs) and 2) and more important: you’d get a evolution which is in the SAME than when you switched off the computer.
Recent efforts with Fedora Core 3 – parallelizing modprobes, not inserting floppy driver on a floppyless machine, ditching rhgb and readahead_early of all of the KDE/Qt libraries have resulted in pretty acceptable boot times. Tracking the page faults to predict the usage and then prefetching them should yield boot times comparable with XP – but I would much rather have suspend and swsup working – who needs to reboot it anyways?
Recent efforts with Fedora Core 3 – parallelizing modprobes, not inserting floppy driver on a floppyless machine, ditching rhgb and readahead_early of all of the KDE/Qt libraries have resulted in pretty acceptable boot times. Tracking the page faults to predict the usage and then prefetching them should yield boot times comparable with XP – but I would much rather have suspend and swsup working – who needs to reboot it anyways?
To address Richard Elling’s comments re: waiting on spanning tree… you should be able to safely disable spanning tree for host-to-switch connections. This would be done on the switch side by setting the port to bypass the normal block-listen-learn-forward process and go straight to forwarding. An example would be enabling “portfast” on Cisco equipment.
Hope this helps…
Booting an ultra 5 off of solaris 10 CDs (as the first step to installing it) is a painfully length process. From the sounds of the CD, reads are jumping all over the place. Isn’t there some way to preread in to memory most of the data in one pass
from the CD, rather than relying on the normal paging mechanism? This would be a lot faster. And I wonder if it would give any improvements in the usual boot from hard disk case?
As mentioned above you can turn off spanning tree…if you own the network. In some places of work the networking staff is a bit more paranoid then others and keeps spanning tree on every port.