View previous topic :: View next topic |
Author |
Message |
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Tue Nov 16, 2004 10:11 pm Post subject: Mapping Boot Times (any init script experts?) |
|
|
I don't particularly care for shortening my boot time, but I do enjoy projects...
Based on Owen Taylor's Boot poster challenge [1], Ziga Mahkovec came up with a method to map out what is going on during the booting process. I believe something similar can be done for Gentoo.
[1] http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00447.html
[2] http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00561.html
Examination of Gentoo's bootup process:
http://openskills.info/seminars/distro/5.htm
www.os3.nl/~pieter/courses/CIA/booting
www.os3.nl/~hobo01/CIA/BootSequence
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4
Idea:
Create a tmpfs early on in boot process (or find some way to mount /dev/shm earlier?). Find the appropriate place in run top (In batch mode, with -b switch... something like `top -b -d 0.2 -n 600`). Run it repeatedly and output to a logfile in tmpfs. Devise some way to display it graphically.
Plan:
I'm planning to at least find a way to generate the log file tonight when I get home from work, but people can take a shot at it before then. My personal feeling on how this might be approached:
1) Create a function in /sbin/rc that goes after:
Code: | # First time boot stuff goes here. Note that 'sysinit' is an internal runlevel
# used to bring up local filesystems, and should not be started with /sbin/rc
# directly ...
if [ "${RUNLEVEL}" = "S" -a "${argv1}" = "sysinit" ]
then...
#log the output here
/sbin/logtop > /dev/shm/top.log
|
Basically have it call a script here that outputs sequential top runs to the tmpfs.
2) Have /etc/inittab make some call to a script like /sbin/logtop before the system initialization line:
Code: | #log the output here
/sbin/logtop > /dev/shm/top.log
# System initialization, mount local filesystems, etc.
si::sysinit:/sbin/rc sysinit |
I'm not that familiar with messing around with the boot scripts, so if anyone else has any more ideas, please share :)
[edit] For reference, here's what the lines in the top summary mean:
Code: | us regular user apps
sy system (general kernel stuff)
ni nice user apps (low-priority tasks)
id idle
wa waiting for IO to complete
hi hard interrupt (IRQ) handlers
si soft interrupt (network stack, mostly?) handlers |
Last edited by aethyr on Fri Nov 19, 2004 2:04 am; edited 3 times in total |
|
Back to top |
|
|
amne Bodhisattva
Joined: 17 Nov 2002 Posts: 6378 Location: Graz / EU
|
Posted: Tue Nov 16, 2004 10:46 pm Post subject: |
|
|
Moved from OTW to Gentoo Chat. _________________ Dinosaur week! (Ok, this thread is so last week) |
|
Back to top |
|
|
castorilo Apprentice
Joined: 25 Dec 2002 Posts: 157
|
Posted: Tue Nov 16, 2004 10:54 pm Post subject: |
|
|
I don't have such a formal method for measuring my boot time. But I have been working on shortening my boot time. I made a few patches that do help considerably.
It would help me a lot if boot time and resource usage could be measured with something like what you are describing.
This is from another forum:
I made 3 patches that speed up boot time dramatically. Initially, It took my computer 2:00 minutes from grub to kdm, and I have been able to reduce it to 1:09 (YMMV). Here is how you can do it:
make sure you have baselayout-1.11.6-r1.
Before you start, make sure you time your current boot time (so you can post it here later )
Do not calculate module dependencies if not needed
This patch saves me around 11 seconds
1) go to this bug and download the patch named "modules-update.patch" and save it as /tmp/modules-update.patch
2) apply the patch:
Code: |
cd /
patch -b -p0 < /tmp/modules-update.patch
|
Make parallel startup really parallel
This saves me around 20 seconds. RC_PARALLEL_STARTUP right now is a joke. At startup the computer is doing either one script or two scripts + a cpu hungry busy wait. This patch I made makes RC_PARALLEL_STARTUP trully parallel running as many scripts as posible with no busy waits, and fully maintain the dependencies and semantics of use, need and before.
Note the messages "starting xxx..." and the corresponding [ok] no longer show on the same line, they get screwed up, but the services start up fine like before.
1) go to this bug and download "parallel_startup.patch" and save it as /tmp/parallel_startup.patch
2) apply the patch:
Code: |
cd /
patch -b -p0 < /tmp/parallel_startup.patch
|
3) enable parallel startup. Edit the file /etc/conf.d/rc and change the line
Code: |
RC_PARALLEL_STARTUP="no"
|
to
Code: |
RC_PARALLEL_STARTUP="yes"
|
Start xdm as soon as posible
This gives me kdm login prompt 20 seconds sooner. This one is especially better after doing the previous one.
[EDIT] changed the instructions to include Xservers.patch
1) go to this bug and download the file "fastxdm". Save it in /etc/init.d/fastxdm. Download the file "Xservers.patch" and put it in /tmp/Xservers.patch
2) remove xdm from default boot level and add fastxdm
Code: |
chmod +x /etc/init.d/fastxdm
rc-update del xdm default
rc-update add fastxdm default
|
3) apply Xservers.patch
Code: |
cd /
patch -b -p0 < /tmp/Xservers.patch
|
Reboot, time it and Enjoy.
All the files that are patched are backed up (patch -b ...) in a .orig file, so if anything goes wrong, you can reboot from the cd, and restore those files. |
|
Back to top |
|
|
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Wed Nov 17, 2004 12:20 am Post subject: |
|
|
I seem to have hit a snag, but I'm not sure why. I can only seem to capture about 13-14 seconds of data.
Here's what I've done so far:
Modified /sbin/rc as follows:
Code: | echo -e "${GOOD}Gentoo Linux${GENTOO_VERS}; ${BRACKET}http://www.gentoo.org/${NORMAL}"
echo -e " Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL"
echo
mount -t tmpfs -o size=2m tmpfs /top
/sbin/toplog&
check_statedir /proc |
The two new lines are the ones above check_statedir.
Created a script called /sbin/toplog, that has the following:
Code: | top -b -d 0.2 -n 600 > /top/toplog |
Now, this seems to work for about 13-14 seconds, but it should be capturing more data (2 minutes to be exact). The file it creates is only 157k, so I don't think it's filling up the partition...
Code: | # ll -h
total 168K
-rw-r--r-- 1 root root 157K Nov 16 14:11 toplog |
Any ideas? The only thing I can think of is that the top job might be getting killed, but I have no clue as to why that would happen. |
|
Back to top |
|
|
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Wed Nov 17, 2004 6:47 am Post subject: |
|
|
It seems that top is being killed in between when sysinit is called from /sbin/rc and then when it ends and inittab begins runlevel 3...
Is there some way I can prevent top from stopping when sysinit ends?
Last edited by aethyr on Wed Nov 17, 2004 8:26 am; edited 1 time in total |
|
Back to top |
|
|
xbmodder Guru
Joined: 25 Feb 2004 Posts: 404
|
Posted: Wed Nov 17, 2004 8:10 am Post subject: |
|
|
to map it i would boot in qemu and use gdb w00t |
|
Back to top |
|
|
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Fri Nov 19, 2004 2:03 am Post subject: |
|
|
ugh, this is frustrating, and I don't understand why it's working for the Red Hat people, but not for me...
Anyways, here's what else I've tried:
creating a /etc/init.d/toplog script:
Code: | #!/sbin/runscript
start() {
ebegin "Starting logging"
start-stop-daemon --start --quiet --exec `/usr/bin/top -b -n 600 -d 0.2 > /top/toplog` &
echo "started" > /top/started
eend $?
} |
And then running it inside /sbin/rc (after /proc loads, based on something I read on the Fedora list:
Code: | ebegin "Mounting proc at /proc"
try mount -n -t proc none /proc
eend $?
/etc/init.d/toplog start |
The only problem? It never starts :P
As an alternative, I tried this:
Code: | ebegin "Mounting proc at /proc"
try mount -n -t proc none /proc
eend $?
/sbin/start-stop-daemon --start --quiet --exec `/usr/bin/top -b -n 600 -d 0.2 > /top/toplog` & |
But now it stops after 14 seconds again... grrrrr :P
I have a feeling whatever gets started between when " si::sysinit:/sbin/rc sysinit" and "rc::bootwait:/sbin/rc boot" (from /etc/inittab) are called, gets killed?
I don't get it...
[edit] Just so we're all on the same page, here's what I want to occur:
start top in batch mode as early in the boot process as possible, and output to a file on a tmpfs directory. The problem is that it is dying some point after it gets started. |
|
Back to top |
|
|
castorilo Apprentice
Joined: 25 Dec 2002 Posts: 157
|
Posted: Wed Nov 24, 2004 3:30 pm Post subject: |
|
|
aethyr wrote: | I seem to have hit a snag, but I'm not sure why. I can only seem to capture about 13-14 seconds of data.
Here's what I've done so far:
Modified /sbin/rc as follows:
Code: | echo -e "${GOOD}Gentoo Linux${GENTOO_VERS}; ${BRACKET}http://www.gentoo.org/${NORMAL}"
echo -e " Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL"
echo
mount -t tmpfs -o size=2m tmpfs /top
/sbin/toplog&
check_statedir /proc |
The two new lines are the ones above check_statedir.
Created a script called /sbin/toplog, that has the following:
Code: | top -b -d 0.2 -n 600 > /top/toplog |
Now, this seems to work for about 13-14 seconds, but it should be capturing more data (2 minutes to be exact). The file it creates is only 157k, so I don't think it's filling up the partition...
Code: | # ll -h
total 168K
-rw-r--r-- 1 root root 157K Nov 16 14:11 toplog |
Any ideas? The only thing I can think of is that the top job might be getting killed, but I have no clue as to why that would happen. |
I have heavilly worked on my init scripts, with bugs 55329 69854 70689 and 71285. Maybe one of these fixed the problem.
Your approach works flawlessly for me. I have the toplog, i am now searching for where the scripts might be to parse that. I would not want to waste my time reinventing the weel. If you have a pointer to the scripts and the java program that was used, please let me know. If you want my toplog, I will send it to you through email, just ask.
I had to export a TERM variable so top would work, so this is my /sbin/toplog script:
Code: |
export TERM=linux
top -b -d 0.2 -n 600 > /top/toplog
|
You might also want to try using nohup |
|
Back to top |
|
|
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Wed Nov 24, 2004 11:59 pm Post subject: |
|
|
paulpach wrote: | Your approach works flawlessly for me. I have the toplog, i am now searching for where the scripts might be to parse that. I would not want to waste my time reinventing the weel. If you have a pointer to the scripts and the java program that was used, please let me know. |
http://www.klika.si/ziga/bootchart/
I don't understand how my approach worked for you when it doesn't work for me... Are you sure you got more than 14 seconds? Mine always cuts short :P
Where are you calling your toplog script from? |
|
Back to top |
|
|
castorilo Apprentice
Joined: 25 Dec 2002 Posts: 157
|
Posted: Thu Nov 25, 2004 2:45 pm Post subject: |
|
|
aethyr wrote: |
I don't understand how my approach worked for you when it doesn't work for me... Are you sure you got more than 14 seconds? Mine always cuts short
|
I am absolutelly sure, I have to kill it once I log in or it fills the partition with useless data.
aethyr wrote: |
Where are you calling your toplog script from? |
I did exactly what you said, I edited /sbin/rc where you said you did.
right here:
Code: |
echo -e "${GOOD}Gentoo Linux${GENTOO_VERS}; ${BRACKET}http://www.gentoo.org/${NORMAL}"
echo -e " Copyright 2001-2004 Gentoo Technologies, Inc.; Distributed under the GPL"
echo
# this is the part I added
mount -t tmpfs -o size=32m tmpfs /top
/sbin/toplog&
# this was there before
check_statedir /proc
|
Now I am facing other problems. It seems top by default is not giving PPID. Ziga makes a custom .toprc and exports HOME on an init script, it has to be adapted to gentoo. Ziga also asked me to send him the adapted script and patches and I will next week. Also, he runs iostat and uses that log to generate the chart. This will not work for everybody. In particular, it wont work if /usr is in a different partition because top and iostat are there. And it won't work unless you emerge sysstat which provides iostat.
As I said before, I might have fixed the problem in one of those bugs, in particular the parallel startup patch is fairly invasive and it has been reported to fix other bugs. Also, the start X soon bug does not change the runlevel like it used to, so it changes inittab behaviour. You might want to try the patches. If you use patch -b ..., backing out of them is trivial.
For me it is generating a lot of data, 2m is not enough, I have to create a 32m partition. Are you sure it is not filling up your tmpfs? |
|
Back to top |
|
|
castorilo Apprentice
Joined: 25 Dec 2002 Posts: 157
|
Posted: Wed Dec 01, 2004 4:45 pm Post subject: |
|
|
I got it working, sent patches to Ziga and he merged them.
To install, emerge baselayout 1.11.6-r1 and sysstat, download bootchart from cvs, run install.sh, reboot. After you reboot log in as root and run /etc/bootchart/bootlog stop. Then go to Ziga's page, put the gzipped logs there and save the png or svg.
Here are some charts that I have produced with Ziga's help. You can emerge librsvg and view them with rsvg-view
this chart is the default boot sequence
this chart is the default boot sequence with RC_PARALLEL_STARTUP="yes"
this chart is with bug 69854
this chart is with bug 69854, bug 55329 and bug 70689.
Enjoy. |
|
Back to top |
|
|
aethyr Veteran
Joined: 06 Apr 2003 Posts: 1085 Location: NYC
|
Posted: Wed Dec 01, 2004 6:40 pm Post subject: |
|
|
paulpach wrote: | I got it working, sent patches to Ziga and he merged them.
To install, emerge baselayout 1.11.6-r1 and sysstat, download bootchart from cvs, run install.sh, reboot. |
Awesome job :) I wish I had the chance to do it myself. I wonder what the issue was... I was only using baselayout 1.9.4-r3, so maybe that had something to do with it.
I notice that X starts on your machine now in 25 seconds, which is a big improvement over the 70+ seconds it took on the default setup. Looks good, I'll have to test those patches later. |
|
Back to top |
|
|
castorilo Apprentice
Joined: 25 Dec 2002 Posts: 157
|
Posted: Wed Dec 01, 2004 7:24 pm Post subject: |
|
|
aethyr wrote: |
I notice that X starts on your machine now in 25 seconds, which is a big improvement over the 70+ seconds it took on the default setup. Looks good, I'll have to test those patches later. |
Well, these logs do not include the kernel initialization, they start after /proc is mounted. In my machine it is about 25 seconds from grub until /proc is mounted. And X takes a few seconds before the login screen comes up.
Also, these charts are done in an dual processor computer, which benefits much more from the parallel patch, not every computer will have such a dramatic improvement.
Other than that, yes, it is definatelly noticeable and a big improvement.
On my parallel patches, you will see processes like cat net.eth0, this means the parent process is waiting for net.eth0 to finish. Pretty much all the cats you see are waiting proceses.
Right now, coldplug and net.eth0 are the biggest offenders because everyone else is waiting for them and they take a lot of time. Apache2 is also a big offender because it consumes a lot of CPU and Disk. |
|
Back to top |
|
|
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Mon Aug 01, 2005 4:15 pm Post subject: Does RC_PARALLEL_STARTUP="yes" work? |
|
|
There is a RC_PARALLEL_STARTUP option in /etc/conf.d/rc which is set to NO by default. I tried to set it to YES on my AMD64 system, and I clocked the startup with a watch. Both modes used 35seconds from when I pressed enter in grub to i was ready to log in on my console.
Have anyone actually noticed (or timed) a speed increase in booting up the services?
edit by nixnut: merged from IG |
|
Back to top |
|
|
Headrush Watchman
Joined: 06 Nov 2003 Posts: 5597 Location: Bizarro World
|
Posted: Mon Aug 01, 2005 4:49 pm Post subject: |
|
|
I have an amd64 also and even though I didn't time it, it didn't seem any faster.
You can look at the threads on initng. It's a replacement for the current startup system and I hear it makes quite a difference. Since I rarely reboot, I haven't tried it yet. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|