[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.

Reply to: