Re: 5.0-RELAEASE-p2

From: Bernd Walter <ticso(at)cicely9.cicely.de>
Date: Thu, 27 Feb 2003 10:43:37 +0100

On Wed, Feb 26, 2003 at 11:21:57PM +0100, Oliver Lehmann wrote:
> soviel zur vorgeschichte. ;) Da ich einfach mal sehen wollte, wie das
> System unter Last reagiert (1 HE Gehaeuse, wenn es mir hier zu hause schon
> an Hitzeentwicklung stirbt...) Ab sich das System aufhaengt etc. pp. Dazu
> habe ich auf dem System einen wesentlich zu ueberdimensioniertes "make
> -j1000 buildworld" abgelassen. Das das mehr oder weniger oversized ist,
> ist mir schon klar ;) Auf jedenfall kommt halt irgendwann mal der Punkt,
> wo das make quasi "haengt", der load auf > 100 ansteigt, die Prozesse
> unaufhoerlich steigen. (das alles passiert nicht sofort, erst nach ner
> ganzen zeit mittem im make world). Dann faengt das system wie wild an zu

Der make kann nicht alles mit 1000 Prozessen machen, da es Abhängig-
keiten gibt.
Ich vermute, nachdem die buildchain erstellt ist kann er mehr gleich-
zeitig machen und die Anzahl der PRozesse geht schlagartig hoch.

> swapen (768 MB "real" ram, etwas um die 900 mb swap) und die plate ist
> laut systat 100% busy. Dann sinkt der load langsam wieder auf unter 1 ab,

Klar, weil alle Prozesse auf die Platte warten müssen.

> platte weiterhin 100% busy, und in/out Swap pages weiterhin ordentlich
> aktiv. Nach einer gewissen Zeit bricht das make dann mit einem segfault

Das sollte nicht sein.
Wenn swap ausgeht, dann kann das System nur noch einen Prozess killen,
um ein wenig Luft zu bekommen.
Allerdinsg ist das dann kein segfault.
Es mag sein, daß dem System RAM oder die Fieldescriptoren oder sonstwas
ausging und ein Bug in einem Programm dann diesen Fehler nicht abge-
fangen hat, das würde den Segfault erklären.

> ab. Ich erklaere mir das jetzt so, das die 1000 (- std prozesse) so viel
> mem anfordern, das der swaper einfach nicht mehr hinterherkommt, den ram
> zu allotiieren, und das dadurch speicherfehler auftreten (wei gesagt, der
> ram ist bis zum limit voll) Ab der Swap bis zum anschlag voll ist kann ich
> nicht sagen, da top etc alles nicht mehr reagiert (weder vmstat, noch top,
> noch iostat, friert alles ein bei diesem load. komischerweise arbeitet
> systat noch ohne probleme munter weiter).

systat ist wessentlich Resourcen schonender.
top ist hingegen ein echter Resourcenfreßer, der muß also mitunter
länger warten.

> Meine Frage mal wieder... "ist das normal"? also der segfault. Erklaeren

Nein, aber erklärlich.
Das Programm, das den Segfault hatte dürfte einen Bug haben, der
normalerweise nicht zum tragen kommt.
Aber der build wäre wohl wegen der eigendlichen Ursache sowieso
abgebrochen - nur etwas sauberer und vermutlich mit einer anständigen
Fehlermeldung.

> kann ichs mir schon irgendwie, nur wundert es mich schon irgendwie das
> dann gleich das ganze make stirbt, und der Scheduler die prozesse die das
> ganze ram wollen erstmal alle auf hold setzt...

Prozesse werden nicht on hold gesetzt wenn Speicher fehlt, da ein
Prozess, der nicht läuft, auch seine Resourcen nicht freigeben kann.
Stelle dir vor, daß ein Prozess 200M allociert und dann 1 Byte und
danach die 200M wieder freigibt.
Solange der Prozess dieses eine Byte nicht bekommt, dann kann das System
auch nicht wieder über die 200M verfügen.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 27 Feb 2003 - 10:43:48 CET

search this site