Kapitel 8 Einführung in den Fair Share Scheduler

Die Analyse von Arbeitslastdaten kann ergeben, dass eine bestimmte Arbeitslast oder Arbeitslastgruppe CPU-Ressourcen monopolisiert. Wenn diese Arbeitslasten keine Ressourceneinschränkungen zur CPU-Nutzung verletzen, können Sie die Zuweisungsrichtlinie für die CPU-Zeit des Systems ändern. Mit der in diesem Kapitel beschriebenen Fair Share Scheduling-Klasse können Sie CPU-Zeit basierend auf Shares anstatt nach dem Prioritätsschema der Timesharing Scheduling-Klasse (TS) zuweisen.

In diesem Kapitel werden die folgenden Themen behandelt.

• Einführung in den Scheduler

• Definition von CPU-Share

• CPU-Shares und Prozessstatus

• CPU-Share kontra Auslastung

• Beispiele für CPU-Shares

• FSS-Konfiguration

• FSS und Prozessorsets

• Kombinieren des FSS mit anderen Scheduling-Klassen

• Einstellen der Scheduling-Klasse für das System

• Scheduling-Klasse auf einem System mit installierten Zonen

• Mit FSS verwendete Befehle

Um direkt in das Arbeiten mit dem Fair Share Scheduler einzusteigen, lesen Sie Kapitel 9Verwalten des Fair Share Scheduler (Vorgehen).

Einführung in den Scheduler

Eine der wichtigsten Aufgaben des Betriebssystems ist zu entscheiden, welche Prozesse wann Zugriff auf die Systemressourcen erhalten. Der Prozess-Scheduler, oder Dispatcher, ist der Teil des Kernel, der die Zuweisung der CPU-Ressourcen zu den Prozessen steuert. Der Scheduler unterstützt das Konzept von Scheduling-Klassen. Jede Klasse definiert eine Scheduling-Richtlinie, über die Prozesse innerhalb der Klasse geplant werden. Der standardmäßige Scheduler im Betriebssystem Solaris, der TS-Scheduler, versucht jedem Prozess etwa den gleichen Zugriff auf die verfügbaren CPU-Ressourcen zu gewähren. Dennoch kommt es häufig vor, dass bestimmte Prozesse mehr Ressourcen als andere Prozesse erhalten sollen.

Mit dem Fair Share Scheduler (FSS) können Sie die Zuordnung von verfügbaren CPU-Ressourcen zwischen den Arbeitslasten steuern. Die Zuordnung erfolgt dabei nach der Wichtigkeit der Arbeitslasten. Diese Wichtigkeit wird durch die Anzahl der Shares (Anteile) an CPU-Ressourcen ausgedrückt, die Sie jeder Arbeitslast zuweisen.

Indem Sie einem Projekt CPU-Shares zuweisen, können Sie die Ansprüche dieses Projekts auf CPU-Ressourcen steuern. Der FSS garantiert eine faire Verteilung der CPU-Ressourcen unter den Projekten. Die Verteilung basiert auf den zugewiesenen Shares und erfolgt unabhängig von der Anzahl an Prozessen, die an ein Projekt angehängt sind. Die Fairness des FSS zeigt sich durch Reduzieren der Projektansprüche bei starker CPU-Nutzung und Erhöhen der Ansprüche bei geringerer CPU-Nutzung. Dies geschieht immer in Übereinstimmung mit anderen Projekten.

Der FSS setzt sich aus einem Kernel-Scheduling-Klassenmodul und klassenspezifischen Versionen der Befehle dispadmin(1M) und priocntl(1) zusammen. Vom FSS verwendete Projekt-Shares werden über die Eigenschaft project.cpu-shares in der project(4)-Datenbank angegeben.

Wenn Sie die Resource Control project.cpu-shares auf einem System mit installierten Zonen verwenden, lesen Sie Konfigurationsdaten in einer Zone, Resource Controls in nicht-globalen Zonen und Verwenden des Fair Share Scheduler auf einem Solaris-System mit installierten Zonen.

Definition von CPU-Share

Der Begriff „Share“ dient zum Festlegen des Anteils der CDU-Ressourcen eines Systems, der einem Projekt zugeordnet wird. Wenn Sie einem Projekt mehr CPU-Shares als einem anderen Projekt zuweisen, erhält das erste Projekt mehr CPU-Ressourcen vom Fair Share Scheduler.

CPU-Shares sind kein Synonym für „Prozentsatz der CPU-Ressourcen“. Shares dienen zum Festlegen der relativen Wichtigkeit von Arbeitslasten in Relation zu anderen Arbeitslasten. Wenn Sie einem Projekt CPU-Shares zuweisen, ist nicht die Anzahl der Shares, die ein Projekt erhält, wichtig. Wichtig ist, wie viele Shares das Projekt im Vergleich zu anderen Projekten hat. Darüber hinaus müssen Sie berücksichtigen, wie viele andere Projekte um CPU-Ressourcen konkurrieren.

Prozesse in Projekten mit null Shares werden immer mit der niedrigsten Systempriorität (0) ausgeführt. Diese Prozesse werden nur dann ausgeführt, wenn Projekte mit mehr als null Shares keine CPU-Ressourcen verbrauchen.

CPU-Shares und Prozessstatus

Eine Projektarbeitslast auf einem Solaris-System umfasst in der Regel mehrere Prozesse. Aus Sicht des Fair Share Scheduler kann jede Projektarbeitslast den Status idle (Wartezustand) oder active (aktiv) aufweisen. Ein Projekt wird als im Wartezustand betrachtet, wenn keiner der darin enthaltenen Prozesse CPU-Ressourcen verbraucht. In der Regel bedeutet dies, dass solche Prozesse entweder ruhen (auf den Abschluss eines E/A-Vorgangs warten) oder gestoppt sind. Ein Projekt wird als aktiv angesehen, wenn mindestens einer der darin enthaltenen Prozesse CPU-Ressourcen verbraucht. Die Summe der Shares aller aktiven Projekte dient zum Berechnen des Anteils an CPU-Ressourcen, der den Projekten zugeordnet wird.

Sind mehrere Projekte aktiv, werden die zugewiesenen CPU-Ressourcen für jedes Projekt reduziert, der Anteil an den Ressourcen bleibt für die einzelnen Projekte jedoch unverändert.

CPU-Share kontra Auslastung

Die Zuweisung von Shares ist nicht das Gleiche wie Auslastung. Ein Projekt, dem 50 % der CPU-Ressourcen zugeordnet sind, wird im Durchschnitt nur 20 % der CPU nutzen. Darüber hinaus dienen die Shares eines Projekts nur dann als Grenzwert für die CPU-Nutzung, wenn das Projekt mit anderen Projekten um CPU-Ressourcen konkurriert. Unabhängig davon, wie viele Shares einem Projekt zugewiesen sind, es erhält immer 100 % der Rechenleistung, wenn es allein auf dem System ausgeführt wird. Verfügbare CPU-Zyklen gehen nie verloren. Sie werden zwischen den Projekten aufgeteilt.

Das Zuweisen nur weniger Shares zu einer regen Arbeitslast könnte deren Performance herabsetzen. Jedoch wird nicht verhindert, dass diese Arbeitslast ihre Arbeit abschließt, sofern das System nicht überlastet ist.

Beispiele für CPU-Shares

Angenommen, Sie haben ein System mit zwei CPUs, die zwei parallele CPU-gebundene Arbeitslasten namens A und B ausführen. Jede Arbeitslast wird als ein separates Projekt ausgeführt. Die Projekte wurden so konfiguriert, dass Projekt A S_A Shares zugewiesen sind und Projekt B S_B Shares.

Unter dem traditionellen TS-Scheduler erhält jede Arbeitslast, die auf dem System aufgeführt wird, durchschnittlich den gleichen Anteil an CPU-Ressourcen. Jede Arbeitslast würde 50 % der Systemkapazität erhalten.

Wenn diese Projekte unter der Kontrolle des FSS-Schedulers mit S_A=S_B ausgeführt werden, erhalten diese Projekte ebenfalls in etwa die gleichen Anteile an CPU-Ressourcen. Sind diesen Projekten jedoch unterschiedlich viele Shares zugewiesen, ist auch die Zuordnung von CPU-Ressourcen unterschiedlich.

Die folgenden drei Beispiele zeigen, wie in verschiedenen Konfigurationen mit Shares gearbeitet wird. Diese Beispiele zeigen, dass Shares nur dann mathematisch korrekt für die Darstellung der Nutzung verwendet werden können, wenn der Bedarf den verfügbaren Ressourcen entspricht oder diese übersteigt.

Beispiel 1: Zwei CPU-gebundene Prozesse in jedem Projekt

Wenn·A und B jeweils zwei CPU-gebundene Prozesse enthalten und S _A = 1 und S _B = 3 ist, beträgt die Gesamtanzahl der Shares 1 + 3 = 4. Bei dieser Konfiguration, ausreichender CPU-Bedarf vorausgesetzt, werden den Projekten A und B 25% bzw. 75% der CPU-Ressourcen zugewiesen.

Beispiel 2: Keine Konkurrenz zwischen Projekten

Wenn·A und B über jeweils nur einen CPU-gebundenen Prozess verfügen und S A _{= 1} und S B _{= 100} ist, beträgt die Gesamtanzahl der Shares 101. Kein Projekt kann mehr als eine CPU benutzen, weil jedes Projekt über nur einen laufenden Prozess verfügt. Da bei dieser Konfiguration keine Konkurrenz zwischen den Projekten um CPU-Ressourcen besteht, werden Projekt A und Projekt B jeweils 50% aller CPU-Ressourcen zugewiesen. Bei dieser Konfiguration ist die Anzahl an CPU-Shares irrelevant. Die den Projekten zugewiesenen Ressourcen wären auch dann gleich (50/50), wenn beiden Projekten null Shares zugewiesen wären.

Beispiel 3: Ein Projekt kann nicht ausgeführt werden

Wenn A und B jeweils zwei CPU-gebundene Prozesse haben und Projekt A 1 Share, Projekt B 0 Shares zugeordnet wurden, erhält Projekt B keine CPU-Ressourcen und Projekt A alle CPU-Ressourcen. Prozesse in B werden immer mit der Systempriorität 0 ausgeführt. Mit anderen Worten, sie werden nie ausgeführt, da Prozesse in Projekt A immer höhere Prioritäten haben.

FSS-Konfiguration

Projekte und Benutzer

Projekte sind die Arbeitslastcontainer im FSS-Scheduler. Die einem Projekt zugewiesenen Benutzergruppen werden als einzeln steuerbare Blöcke betrachtet. Beachten Sie, dass Sie für jeden einzelnen Benutzer ein Projekt mit einer individuellen Anzahl an Shares erstellen können.

Benutzer können Mitglieder mehrerer Projekte sein, denen unterschiedlich viele Shares zugeordnet sind. Durch das Verschieben von Prozessen von einem Projekt zu einem anderen können den Prozessen CPU-Ressourcen verschiedener Größenordnungen zugewiesen werden.

Weitere Informationen zur project(4)-Datenbank und den Namen-Services finden Sie unter project-Datenbank.

Konfiguration der CPU-Shares

Die Konfiguration der CPU-Shares wird vom Namen-Service als Eigenschaft der project-Datenbank verwaltet.

Wenn die erste Aufgabe (bzw. der erste Prozess) einem mit der Bibliotheksfunktion setproject(3PROJECT) erstellten Projekt zugeordnet ist, wird die Anzahl der CPU-Shares, die als Resource Control project.cpu-shares in der project-Datenbank definiert wurde, an den Kernel übergeben. Einem Projekt, für das keine Resource Control project.cpu-shares definiert wurde, wird ein Share zugewiesen.

Im folgenden Beispiel setzt der Eintrag in der Datei /etc/project die Anzahl der Shares für das Projekt x-files auf 5:

x-files:100::::project.cpu-shares=(privileged,5,none)

Wenn Sie die Anzahl der CPU-Shares, die einem Projekt in der Datenbank zugeordnet ist, während der Ausführung von Prozessen ändern, wird diese Änderung nicht unmittelbar übernommen. Das Projekt muss neu gestartet werden, damit die Änderung wirksam wird.

Soll die Anzahl der einem Projekt zugeordneten Shares nur vorübergehend geändert werden, ohne die Projektattribute in der project-Datenbank zu ändern, verwenden Sie den Befehl prctl. Um beispielsweise den Wert der Resource Control project.cpu-shares für das Projekt x-files auf 3 zu ändern, während die dem Projekt zugeordneten Prozesse ausgeführt werden, geben Sie Folgendes ein:

# prctl -r -n project.cpu-shares -v 3 -i project x-files

Weitere Informationen finden Sie in der Manpage prctl(1).

-r

Ersetzt den aktuellen Wert der angegebenen Resource Control.

-n name

Gibt den Namen der Resource Control an.

-v val

Gibt den Wert der Resource Control an.

-i idtype

Gibt den ID-Typ des nächsten Arguments an.

x-files

Gibt das Objekt der Änderung an. In diesem Fall ist das Objekt das Projekt x-files.

Das Projekt system mit der Projekt-ID 0 enthält alle Systemdaemons, die von den Initialisierungsskripten beim Booten gestartet wurden. system kann als ein Projekt mit einer unbegrenzten Anzahl an Shares betrachtet werden. Dies bedeutet, dass system immer als erstes geplant wird, ungeachtet der Anzahl an Shares, die anderen Projekten zugewiesen wurden. Wenn Sie nicht möchten, dass das Projekt system eine unbegrenzte Anzahl an Shares erhält, können Sie in der project-Datenbank festlegen, wie viele Shares diesem Projekt zugeordnet werden sollen.

Wie bereits beschrieben, erhalten Prozesse, die Projekten mit null Shares zugeordnet sind, immer eine Systempriorität von null. Projekte mit einem oder mehr Shares werden mit den Prioritäten eins und höher ausgeführt. Somit werden Projekte mit null Shares nur dann geplant, wenn CPU-Ressourcen verfügbar sind, die nicht von einem Projekt mit mehr als null Shares angefordert sind.

Einem Projekt können nicht mehr als 65535 Shares zugewiesen werden.

FSS und Prozessorsets

Mit FSS und Prozessorsets kann die Aufteilung von CPU-Ressourcen unter den Projekten, die auf den einzelnen Prozessorsets ausgeführt werden, besser als mit Prozessorsets allein gesteuert werden. Der FSS-Scheduler behandelt Prozessorsets als vollständig unabhängige Partitionen. Dabei wird jedes Prozessorset hinsichtlich der CPU-Zuweisungen vollständig unabhängig gesteuert.

Die Zuweisung von CPU-Ressourcen zu Projekten, die auf ein Prozessorset ausgeführt werden, wird weder von den CPU-Shares noch den Aktivitäten der Projekte beeinflusst, die auf einem anderen Prozessorset ausgeführt werden, da diese Projekte nicht um die gleichen Ressourcen konkurrieren. Projekte konkurrieren nur miteinander, wenn sie auf dem gleichen Prozessorset ausgeführt werden.

Die Anzahl der einem Projekt zugewiesenen Shares gilt systemweit. Unabhängig davon, auf welchem Prozessorset ein Projekt ausgeführt wird, erhält jeder Teil eines Projekts die gleiche Anzahl an Shares.

Wenn Prozessorsets verwendet werden, werden die CPU-Zuweisungen für ein Projekt nur für die aktiven Projekte berechnet, die auf einem Prozessorset ausgeführt werden.

Projektpartitionen, die auf anderen Prozessorsets ausgeführt werden, haben eventuell abweichende CPU-Zuweisungen. Die Zuweisung von CPU-Ressourcen für jede Projektpartition in einem Prozessorset hängt nur von den Zuweisungen anderer Projekte ab, die auf diesem Prozessorset ausgeführt werden.

Leistung und Verfügbarkeit von Anwendungen, die innerhalb der Grenzen ihrer Prozessorsets ausgeführt werden, werden von der Einführung neuer Prozessorsets nicht beeinflusst. Darüber hinaus wirken sich Änderungen, die an den Share-Zuweisungen zu Projekten in anderen Prozessorsets vorgenommen werden, nicht auf die Anwendungen aus.

Leere Prozessorsets (Sets ohne Prozessoren) oder Prozessoren ohne darin gebundene Prozesse haben keinen Einfluss auf das Verhalten des FSS-Scheduler.

Beispiele für FSS und Prozessorsets

Angenommen, ein Server mit acht CPUs führt mehrere CPU-gebundene Anwendungen in den Projekten A, B und C aus. Projekt A ist ein Share zugewiesen, Projekt B sind zwei Shares zugewiesen und Projekt C sind drei Shares zugewiesen.

Projekt A wird nur auf Prozessorset 1 ausgeführt. Projekt B wird auf den Prozessorsets 1 und 2 ausgeführt. Projekt C wird auf den Prozessorsets 1, 2 und 3 ausgeführt. Es wird davon ausgegangen, dass jedes Projekt über genügend Prozesse verfügt, um die gesamte verfügbare CPU-Leistung auszulasten. Daher konkurrieren alle Prozesse auf jedem Prozessorset um die verfügbaren CPU-Ressourcen.

Die gesamte systemweite CPU-Zuweisung für Projekte auf einem solchen System wird in der folgenden Tabelle gezeigt.

Diese Prozentwerte stimmen nicht der entsprechenden Anzahl an CPU-Shares überein, die den Projekten zugeordnet sind. Dennoch sind die zugewiesenen CPU-Ressourcen pro Projekt innerhalb jedes Prozessorsets proportional zu den jeweiligen Shares.

Auf dem gleichen System ohne Prozessorsets wäre die Verteilung der CPU-Ressourcen anders. Dies wird in der folgenden Tabelle gezeigt.

Kombinieren des FSS mit anderen Scheduling-Klassen

Standardmäßig nutzt die FSS-Scheduling-Klasse den gleichen Prioritätenbereich (0 bis 59) wie die Scheduling-Klassen Timesharing (TS), Interactive (IA) und Fixed Priority (FX). Aus diesem Grund sollten Sie vermeiden, dass Prozesse aus diesen Scheduling-Klassen das gleiche Prozessorset gemeinsam nutzen. Das Verbinden von Prozessen der Klassen FSS, TS, IA und FX könnte zu einem unerwarteten Scheduling-Verhalten führen.

Werden Prozessorsets verwendet, können Sie TS, IA und FX mit FSS in einem System verbinden. Alle Prozesse, die auf den Prozessorsets ausgeführt werden, müssen jedoch einer Scheduling-Klasse angehören, so dass sie nicht um die gleichen CPUs konkurrieren. Insbesondere sollte der FX-Scheduler nicht zusammen mit der FSS-Scheduling-Klasse verwendet werden, es sei denn, es werden Prozessorsets verwendet. Hierdurch wird verhindert, dass Anwendungen in der FX-Klasse so hohe Prioritäten verwenden, dass Anwendungen in der FSS-Klasse nicht mehr zum Zuge kommen.

Prozesse der Klassen TS und IA können auf dem gleichen Prozessorset oder auf dem gleichen System ohne Prozessorsets gemischt werden.

Für Benutzer mit Superuser-Berechtigungen bietet das Solaris-System darüber hinaus einen Realtime-Scheduler (RT). In der Standardeinstellung nutzt die RT-Scheduling-Klasse Systemprioritäten in einem anderen Bereich als der FSS (in der Regel von 100 bis 159). Da RT und FSS getrennte oder nicht-überlappende Prioritätenbereiche nutzen, kann FSS mit der RT-Scheduling-Klasse innerhalb des gleichen Prozessorsets koexistieren. Jedoch hat die FSS-Scheduling-Klasse keine Kontrolle über Prozesse, die in der RT-Klasse ausgeführt werden.

Bei einem Vier-Prozessor-System kann ein CPU-gebundener RT-Prozess mit einem Thread einen gesamten Prozessor verbrauchen. Wenn das System auch FSS ausführt, konkurrieren die Prozesse normaler Benutzer um die drei verbleibenden CPUs, die nicht vom RT-Prozess genutzt werden. Beachten Sie, dass der RT-Prozess die CPU eventuell nicht ständig nutzt. Wenn sich der RT-Prozess im Leerlauf befindet, lastet der FSS alle vier Prozessoren aus.

Mit dem folgenden Befehl können Sie herauszufinden, in welchen Scheduling-Klassen die Prozessorsets ausgeführt werden und sicherstellen, dass jedes Prozessorset zur Ausführung entweder von TS-, IA-, FX- oder FSS-Prozessen konfiguriert ist.

$ ps -ef -o pset,class | grep -v CLS | sort | uniq
1 FSS
1 SYS
2 TS
2 RT
3 FX

Einstellen der Scheduling-Klasse für das System

Informationen zum Einstellen der standardmäßigen Scheduling-Klasse für das System finden Sie unter So legen Sie FSS als standardmäßige Scheduling-Klasse fest, Scheduling-Klasse in einer Zone und in der Manpage dispadmin(1M). Wie Sie laufende Prozesse in eine andere Scheduling-Klasse verschieben, können Sie unter Konfigurieren des FSS und in der Manpage priocntl(1) nachlesen.

Scheduling-Klasse auf einem System mit installierten Zonen

Nicht-globale Zonen verwenden die standardmäßige Scheduling-Klasse des Systems. Wenn das System eine neue Standardeinstellung für die Scheduling-Klasse erhält, beziehen die nicht-globalen Zonen die neue Einstellung nach dem Booten bzw. einem Neustart.

Normalerweise wird der FSS in diesem Fall mit dem Befehl dispadmin auf die standardmäßige Scheduling-Klasse des Systems gesetzt. So erhalten alle Zonen einen gleich großen Anteil der CPU-Ressourcen des Systems. Weitere Informationen zu Scheduling-Klassen bei installierten Zonen finden Sie unter Scheduling-Klasse in einer Zone.

Informationen zum Verschieben von laufenden Prozessen in eine andere Scheduling-Klasse, ohne die standardmäßige Scheduling-Klasse zu ändern und einen Neustart durchzuführen, finden Sie in Tabelle 27–5 und in der Manpage priocntl(1).

Mit FSS verwendete Befehle

Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zum Fair Share Scheduler dar.