Re: Suggestion: controlling the load average
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> writes:
> I think the Debian installation tools need something to monitor the
> load average, to prevent systems from [ct]rashing during
> install. Cfr. sendmail which stops processing mail when it detects
> that the load average is above a specified threshold.
That should actually never happen. Any souch occurance would be a bug.
> A lot of programs start update-menus in the background upon
> installation. If you install (or upgrade) 50 of them, you get 50
> running update-menus processes fighting for CPU cycles. [
> correction: according to some people, this is not normal behavior,
> so it must be a bug in the current update-menus on PPC ]
I installed a few Debian Systems lately and never had that problem,
must be a bug.
The implementation of update-menu should be that programs register to
dpkg that they need the menus to be updated and at the end
update-menus runs once.
The actual behaviour looks to me as follows: update menus gets started
once by the first package needing new menus and all others are put on
hold as dpkg gos along. As soon as update-menu has finished in the
background it will run again for all packages that have come up
inbetween.
You should look at the locking under PPC, since I think it uses that
to keep update-menus from running multiple times.
> It may sound hard to update all helper scripts (like update-menus)
> used for installation, but even adding a simple load average check
> to dpkg only would cure most of the problems. If you do that dpkg
> just pauses until the load average is lower, i.e. until the
> background scripts are finished.
I used the load watching stuff from make to have make run several
gcc´s at once until it reaches a certain load, BUT when the system is
idle to start with make will start about 50 gcc´s before the load
reaches 3 and then it will keep klimbing up to about 80 or fail
because "out of memory". The load reacts far to slow to be a got
safety valve. All helperscripts should register themself to a runqueue
and get executed one after another. For stuff like update-menus a new
entry of update-menus should be able to replace the old.
But who want´s to change dpkg?
> This idea was inspired by the problem I had with update-menus, where
> they all kept running in the background when I did `apt-get upgrade
> -u'. All those update-menus processes consumed CPU cycles and tried
> to exhaust memory (I `only' have 128 MB in my PPC box).
Deffinetly a bug.
May the Source be with you.
Goswin
Reply to: