[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


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

[luga] Re: [lll]: bestimmung der aktuellen auslastung eines rechners in verbindung mit seiner leistung?



On Tue, Feb 24, 1998 at 01:27:17PM +0100, Andreas Lederer wrote:

> vielleicht sollte ich auch den zweck des programs hier erleutern:
>
> es sollen in einem netzwerk berechnungen, processe oder dergleichen so
> verteilt werden, das alle rechner gleichmaessig ausgelastet sind.

Darf ich da jetzt ganz frech behaupten, daß das nicht das ist, was Du
wirklich willst?

Was Du wirklich willst, ist, daß alle Aufgaben, die Du an das Netz
(Sun-Slogan: The network is the computer) heranträgst, möglichst schnell
gelöst werden. Du glaubst, daß das der Fall ist, wenn Du jeden Job auf
dem Computer startest, auf dem die zu erwartende Laufzeit am geringsten
ist. Du glaubst ferner, daß dieser Computer der mit der geringsten
"Last" ist. Drittens glaubst Du, daß die "Last" steigt, wenn auf einem
Computer ein (zusätzlicher) Job läuft, und schließt daraus, daß bei
einer idealen Verteilung alle die gleiche Last haben.

Daher forderst Du eine gleichmäßige "Last" auf allen Rechnern, und
stehst jetzt vor dem Problem, daß Du die "Last" noch gar nicht definiert
hast und auch nicht weißt, wie Du sie definieren sollst.

Ich glaube, daß Du Dich damit vom tatsächlichen Problem zu weit entfernt
hast, und es sinnvoll ist, wieder ein paar Schritte zurückzugehen.

Schon der erste Schluß ("ein Job wird dann am schnellsten erledigt,
wenn er auf dem Computer gestartet wird, der ihn am schnellsten
erledigt"), klingt zwar nach einer Tautologie, stimmt aber gar nicht
immer. Vielleicht ist es möglich, den Job in mehrere Teile aufzuteilen,
die parallel auf mehreren Computern abgearbeitet werden können? Nehmen
wir an, das sei bereits geschehen: Vielleicht ist es völlig sinnlos,
/diesen/ Job in 0.3 Sekunden abzuarbeiten, weil ich das Ergebnis erst
verwenden kann, wenn ich auch das Ergebnis eines anderen Jobs habe, der
2 Stunden braucht? Aber ignorieren wir das einmal für den Moment, und
nehmen wir an, alle unsere Jobs seien voneinander unabhängig, und es sei
gleich schlimm, wenn ein 2-Sekunden-Job statt dessen 4 Sekunden braucht,
wie wenn ein 2-Tage-Job 4 Tage braucht (Könnte ja sein, daß ich 90000
solche 2-Sekunden-Jobs erledigen muß). Dann müssen wir tatsächlich für
jeden Job nur den Computer suchen, der ihn am schnellsten erledigen
kann.

Was haben wir also für Jobs:

Job 1 liest ein 5GB-File sequentiell durch, und erstellt daraus
irgendwelche Histogramme.

Job 2 ist ein Raytracing-Programm, das eine kleine Szene mit vielen
Spiegelungen berechnet.

Job 3 ist eine Simulation, die 500MB RAM benötigt, und mehr oder weniger
zufällige Zugriffsmuster aufweist.

Job 4 komprimiert einige Files.

Wird jeder dieser Jobs auf dem gleichen Rechner am schnellsten
ausgeführt?

Job 1 ist sicherlich File-I/O-bound. Records zählen braucht weder eine
starke CPU noch viel RAM, d.h. der Prozess soll dort laufen, wo er das
File am schnellsten lesen kann, also wahrscheinlich auf dem Rechner, auf
dem das File liegt, oder zumindest auf einem, der dorthin eine schnelle
Netzwerkverbindung hat.

Job 2 braucht zuerst Floating-Point-Power, dann nocheinmal
Floating-Point-Power und dann Memory-Bandwidth. Er braucht nicht viel
Speicher (vielleicht hat er sogar im 2nd-Level-Cache Platz), und so gut
wie keine I/O.

Job 3 braucht RAM. Auf dem Rechner müssen mindestens 500 MB freies RAM
sein, sonst fängt er ganz fürchterlich an zu pagen und wird nie fertig.
In zweiter Linie braucht er FP und Memory-Bandwidth.

Job 4 braucht hauptsächlich Integer-Performance und dann noch File-I/O.


Man sieht also ganz deutlich, daß die Frage, auf welchem Rechner man
einen Job starten soll, nicht nur vom momentanen Zustand der Rechner
abhängt, sondern auch von den Jobs.

Jetzt kannst Du für jeden Rechner erstens interessante Parameter
feststellen (CPU-Leistung (zumindest aufgeteilt in FP und Integer,
wenn nicht noch feiner), Memory-Bandwidth, Cache-Größe, RAM-Größe,
Swapspace-Größe, Diskbandwidth, Bandbreite zum Fileserver, Bandbreite
zum Datenbankserver, ...) und zweitens, welchen Anteil davon der Rechner
einem neu dazukommenden Job zur Verfügung stellen könnte.

Dann kann z.B. eine Sun Ultra 30 mit 3 Prozessen in der CPU-Queue
sagen: Momentan könnte ich einem Prozess 14.9/4==3.7 SPECfp95 zur
Verfügung stellen, und ein 200MHz PPro mit 1 Prozess in der Run
Queue könnte sagen: Ich biete 6.2/2==3.1 SPECfp95. Entsprechend
kannst Du mit Diskbandbreite und Länge der Disk-Queue verfahren, bei
Netzwerkbandbreiten wird es schon schwieriger.

Schwierig ist eventuell, an die Queuelängen heranzukommen. Selbst
wenn es entsprechende Counter im Kernel gibt, existiert oft kein
(dokumentiertes) Interface, um sie anzusprechen. Hier kann ich nur
nochmals auf die Sourcen "top", "lsof", "monitor", etc. verweisen, die
solche und ähnliche Informationen aus den verschiedensten Unix-Versionen
auslesen.

Im schlimmsten Fall kannst Du natürlich einfach die "Load average" als
Näherungswerte für alle Queues verwenden. 

Oder Du kannst kleine Testroutinen schreiben, die nur kurz laufen
(jeweils weniger als eine Sekunde), die messen, wieviel CPU, Memory- und
I/O-Bandbreite ein Prozess gerade bekommen könnte. Aber Vorsicht: die
Tests müssen lange genug laufen, um sinnvolle Ergebnisse zu liefern
(also mindestens einige Timeslices), sie sind wahrscheinlich zu
optimistisch (neue Prozesse und solche die nur selten etwas tun haben
höhere Priorität als solche, die lange viel tun), und sie nehmen auf
jeden Fall anderen Prozessen die Ressourcen weg.


Ein völlig anderer Ansatz bietet sich an, wenn entweder alle Jobs oder
alle Rechner "ähnlich" sind, also entweder alle Jobs eher CPU-intensiv,
oder alle eher Memory-intensiv, oder alle disk-intensiv; oder alle
Rechner haben den gleichen Prozessortyp, und die mit der höheren
Taktfrequenz haben auch mehr und schnelleres Memory, schnellere Platten,
etc.

Dann kannst Du einfach auf jedem Rechner einen Server laufen lassen,
der einen neuen Job annimmt, wenn er sich unterbeschäftigt fühlt (im
einfachsten Fall: wenn er gerade nichts zu tun hat). Wenn gerade alle
Server beschäftigt sind, landen Prozesse in einer Queue. Naturgemäß
werden die schnelleren Server mit jedem Job schneller fertig sein und
früher wieder "Hier!" schreien, und damit mehr Arbeit erledigen.

Das kann man auch mit dem vorigen Ansatz mischen, dann könnte ein
Server sagen: Ich hätte noch Platz für eine Integer-intensiven
oder I/O-intensiven Job (aber nicht für eine Floating-Point- oder
Memory-intensiven).


	hp


-- 
   _  | Peter J. Holzer             | Lecture by Linus Torvalds:
|_|_) | Sysadmin WSR                |     "World Domination 101"
| |   | hjp@wsr.ac.at               | Lecture by Bill Gates:
__/   | http://wsrx.wsr.ac.at/~hjp/ |     "World Domination 404" 

Attachment: pgpUVzr6nhHCY.pgp
Description: PGP signature



powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010