Re: portupgrade und make brauchen zu viel CPU

P.U.Kruppa wrote:
> Oliver Fromme wrote:
> > OK.
> > Hast Du auch an /etc/malloc.conf gedacht?
> > # ln -sf aj /etc/malloc.conf
> Klär mich noch einmal auf: soll ich den Link setzen oder nicht?
> Z.Z. ist keiner da.

Dann setze ihn. Oder c(v)suppe nochmals auf das jetzt
aktuelle RELENG_7; dort sind die Debug-Optionen bereits
per Default ausgeschaltet.

> Ich hatte mich bis jetzt noch nicht mit SCHED_ULE beschäftigt,
> aber ich habe mal
> # options SCHED_4BSD
> options SCHED_ULE
> gesetzt.

OK. Nur der Vollständigkeit halber: Ist das ein UP- oder
ein SMP-System? (Kann mich nicht erinnern, ob Du's schon
erwähnt hattest.)

> > > STRIP=
> > > WITH_DEBUG=yes
> >
> > Die schmeiss bitte auch raus. Warum hast Du die drin?!?
> Naja, ... die hab' ich da vergessen. Es handelt sich um - wie
> ich sehe - veraltete Einstellungen für den gnome development
> Zweig
> ( http://www.freebsd.org/gnome/docs/develfaq.html )

Solche Optionen sollte man immer so eintragen, dass sie
_nur_ für den Port wirken, der sie benötigt. Ich mache
in /etc/make.conf immer ein »if« drumherum (es gibt auch
andere Möglichkeiten, aber so funktioniert's immer).
Z.B. steht bei mir drin:

.if ${.CURDIR} == "/usr/ports/devel/subversion"
WITHOUT_BDB=yes
WITHOUT_NLS=yes
.endif

> > Es gäbe erheblich weniger Probleme auf der Welt, wenn
> > die Leute keine Dinge in ihre Konfigurationsdateien rein-
> > schreiben würden, von denen sie nicht genau wissen, was
> > sie bewirken ... :-)
> Du meinst jetzt jene Konfigurationsdateien in uns allen?

An die dachte ich eher nicht, aber jetzt wo Du's sagst ...
Ja, die eigentlich auch. :-)

> Ergebnis:
> ---------
> Fühlt sich schon deutlich besser an. Schade, dass man das nicht
> irgendwie messen kann.

Naja, ein beliebter »Benchmark« ist die Dauer eines »make
buildworld«. Gerade bei den Debugging-Sachen macht das
einen deutlichen Unterschied. Die malloc.conf wirkt sich
natürlich vor allem auf Prozesse aus, die viel malloc(3)
verwenden, und das betrifft durchaus make, awk und ein
paar andere Tools, die z.B. beim buildworld intensiv ver-
wendet werden.

> Muss ich wegen dem SCHED_ULE irgendwie mit spontanen
> Systemabstürzen rechnen?

Nein, solltest Du nicht. Ich kann mich nicht erinnern,
dass der in letzter Zeit irgendwelche Panics verursacht
hätte (in FreeBSD 7, wohlgemerkt). Schlimmstenfalls
ist die Performance nicht so gut wie sie sein könnte,
aber nach den jüngsten Updates sollte er eigentlich min-
destens genausogut sein wie der alte BSD-Scheduler,
und auf SMP-Systemen sogar deutlich besser.

(NB: Es gibt Betriebssysteme, wo man den Scheduler im
laufenden Betrieb wechseln kann, und sogar verschiedene
Prozesse unter verschiedenen Schedulern gleichzeitig
laufen lassen kann [z.B. Solaris und DragonFly BSD].
FreeBSD hat den Umstieg auf ULE leider nicht für ein
entsprechend flexibles Framework genutzt, was ich sehr
schade finde.)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
C++: "an octopus made by nailing extra legs onto a dog"
        -- Steve Taylor, 1998
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message