Blocking the boot is by design. The point of ureadahead is to preload all the data your boot will require ahead of time. The reason to do this is that the primary reason for disc slowness is seek times - even slow hard drives should be able to push out >50 MB/sec reads, but if you need to seek around - at tens of milliseconds per seek - that decreases dramatically. By running ahead of time, ureadahead should be able to minimise the seeks and hence minimise the time needed to read all the data your boot will need.
So, the ideal bootchart looks like ureadahead at 100% I/O utilisation, followed by everything else starting up and using no (disc) I/O. This boot isn't practically achievable, not least because many of the services we're starting up write to the disc, but that's the idea.
Looking at your bootchart it seems that ureadahead is having a hard time actually pulling data off your disc - there's lots of time where it's at a very low throughput. Even so, it looks like it's doing some of its job - after ureadahead starts your boot is mostly CPU bound, rather than I/O bound, and it looks like the large patches of I/O-bound boot are associated with preload
firing up.
You might want to try removing preload
, or to reprofile your boot¹, or it might be that some of your files are very fragmented, or it might be a bug in ureadahead.
1: Removing the pack
files from /var/lib/ureadahead will cause ureadahead to reprofile on your next boot.
In my version of ubuntu (12.04) bootchart
creates a different log file every time the computer boots, this goes into the directory /var/log/bootstrap
. Though, bootstartgui
looks by default to the file /var/log/bootchart.tgz
which does not exist.
In 12.04, if you install bootchart
properly, you automatically get an image file of the boot graph representation, so you do not need to run bootstartgui
.
In fact, it is enough to run (Alt+F2):
nautilus /var/log/bootchart
then double click on the image that contains the date and time that you are interested in.
If you want to delete useless logs and save space, you can start nautilus with sudo from the commandline: Type (Alt+Ctrl+T) and then:
gksu nautilus /var/log/bootchart
This will give you a window where you can also delete files. Be very cautious not to delete anything on another folder!
Best Answer
As stated in the Boot chart Documentation, the data collection process uses:
Therefore,
Yes
These are CPU cycles wasted waiting for I/O
a. The disk throughput is a number in MBps/sec measuring the data that gets read/written to/from the disk.
b. The Disk utilization is a % between 0 (meaning idle) and 100 (meaning fully occupied)
"Unint. sleep" is the abbreviation of "Uninterrupted sleep" (See 2. above)
"Sleeping" means "not doing anything" which would be not very good while performing a boot... (Also see 2. above)
A simple example:
Let's suppose you do video conversion: you will read very little disk, but use 100% of 1 CPU, then the Disk Utilisation will be 1% and the total CPU on a dual-Core CPU will be 50%
Now you do a file copy: 1 CPU will be at 1% and the Disk Utilisation will be at 40%; now you do 2 file copies at the same time: CPU will be at 2% and Disk Utilisation will be at 80%.
If you do a third file copy at the same time, Disk Utilisation will be at 100%, but CPU% will go up and show 20% "I/O Wait": it doesn't go any faster: the CPU is just waiting until it can push some more data to the disk.
This is just an example: the % depend on the availability of RAM, CPU and the speed of your disk!