Teil I Ressourcenverwaltung

In diesem Teil wird die Solaris 10-Ressourcenverwaltung vorgestellt, mit der Sie festlegen können, wie Anwendungen verfügbare Systemressourcen nutzen.

Kapitel 1 Einführung in Solaris 10-Ressourcenverwaltung

Die Funktionen zur Ressourcenverwaltung bilden eine Komponente der Solaris Container-Umgebung. Mit der Ressourcenverwaltung können Sie festlegen, wie verfügbare Systemressourcen durch Anwendungen genutzt werden. Folgende Vorgehensweisen sind möglich:

• Computerressourcen, z. B. Prozessorzeit, zuweisen

• Die Auslastung der vorgenommenen Zuweisungen überwachen und dann ggf. anpassen

• Extended Accounting-Daten zur Analyse, Abrechnung und Kapazitätsplanung erzeugen

In diesem Kapitel werden die folgenden Themen behandelt.

• Ressourcenverwaltung – Übersicht

• Einsatzgebiete für die Ressourcenverwaltung

• Einrichten der Ressourcenverwaltung (Übersicht der Schritte)

Ressourcenverwaltung – Übersicht

Moderne Computerumgebungen müssen flexibel auf sich ändernde Arbeitslasten reagieren können, die von verschiedenen Anwendungen auf einem System erzeugt werden. Eine Arbeitslast ist die Zusammenfassung aller Prozesse einer Anwendung oder Anwendungsgruppe. Ohne die Funktionen der Ressourcenverwaltung reagiert Solaris auf die Ansprüche von Arbeitlasten, indem es sich den neuen Anforderungen dynamisch anpasst. Diese Standardreaktion bedeutet allgemein, dass allen Aktivitäten auf einem System der gleiche Zugriff auf Ressourcen gewährt wird. Mit der Solaris-Ressourcenverwaltung können Arbeitslasten jedoch individuell behandelt werden. Folgende Vorgehensweisen sind möglich:

• Den Zugriff auf eine bestimmte Ressource einschränken

• Arbeitslasten bestimmte Ressourcen bevorzugt anbieten

• Arbeitslasten voneinander isolieren

Als Ressourcenverwaltung wird die Fähigkeit bezeichnet, arbeitslastübergreifende Leistungseinbußen zu minimieren. Dies wird kombiniert mit Funktionen zur Überwachung von Ressourcennutzung und -auslastung. Die Ressourcenverwaltung wird über verschiedene Algorithmen umgesetzt. Diese Algorithmen verarbeiten die Kapazitätsanforderungen, die eine Anwendung während ihrer Ausführung stellt.

Mit den Funktionen der Ressourcenverwaltung können Sie das Standardverhalten des Betriebssystems in Bezug auf die verschiedenen Arbeitslasten anpassen. Verhalten bezieht sich hier auf die Entscheidungen der Betriebssystemalgorithmen, wenn eine Anwendung Ressourcenanforderungen an das System stellt. Mit den Funktionen der Ressourcenverwaltung können Sie:

• Ressourcen verweigern oder eine Anwendung bevorzugen, indem Sie ihr einen größeren Anteil an den Ressourcen zuweisen

• Bestimmte Zuweisungen kollektiv anstatt über isolierte Mechanismen behandeln

Die Übernahme einer Systemkonfiguration, die Funktionen der Ressourcenverwaltung verwendet, dient mehreren Zwecken. Folgende Vorgehensweisen sind möglich:

• Die wahllose Belegung von Ressourcen durch eine Anwendung verhindern

• Die Priorität einer Anwendung basierend auf externen Ereignissen ändern

• Ressourcengarantien gleichmäßig an ein Anwendungsset verteilen, um maximale Systemauslastung zu erreichen

Bei der Planung einer ressourcenverwalteten Konfiguration sind die primären Anforderungen:

• Die konkurrierenden Arbeitslasten auf dem System zu erkennen

• Kooperierende Arbeitslasten von solchen Arbeitslasten zu unterschieden, deren Leistungsanforderungen sich negativ auf die primären Arbeitslasten auswirken

Nachdem kooperierende und konkurrierende Arbeitslasten identifiziert wurden, erstellen Sie eine Ressourcenkonfiguration, die den besten Kompromiss zwischen den betrieblichen Zielen Ihres Unternehmens und den Einschränkungen der Systemkapazitäten darstellt.

Eine effektive Ressourcenverwaltung in einem Solaris-System erfolgt über das Zusammenspiel von Mechanismen zur Steuerung, Benachrichtigung und Überwachung. Einige dieser Funktionen werden über Erweiterungen für vorhandene Mechanismen bereitgestellt, z. B. das proc(4)-Dateisystem, Prozessorsets und Scheduling-Klassen. Andere Funktionen sind nur für die Ressourcenverwaltung verfügbar. Diese Funktionen werden in den folgenden Kapiteln beschrieben.

Ressourcenklassifizierungen

Eine Ressource ist ein beliebiger Aspekt eines Computersystems, der geändert werden kann, um das Verhalten einer Anwendung zu beeinflussen. Somit ist eine Ressource ein Leistungsmerkmal, das eine Anwendung implizit oder explizit anfordert. Wird dieses Leistungsmerkmal verweigert oder ist es eingeschränkt, wird eine robust geschriebene Anwendung langsamer ausgeführt.

Im Gegensatz zur Identifizierung von Ressourcen kann die Klassifizierung von Ressourcen auf verschiedenen Achsen erfolgen. Die Achsen können implizit vs. explizit angefordert, zeitbasiert (z. B. CPU-Zeit) vs. zeitunabhängig (z. B. zugewiesene CPU-Shares) usw. darstellen.

Im Allgemeinen wird die Scheduler-basierte Ressourcenverwaltung für Ressourcen eingesetzt, die eine Anwendung implizit anfordern kann. So fordert eine Anwendung z. B. implizit zusätzliche CPU-Zeit an, um die Ausführung fortsetzen zu können. Eine andere Anwendung fordert implizit Bandbreite an, um Daten auf ein Netzwerk-Socket zu schreiben. Für implizit angeforderten Ressourcen können Einschränkungen hinsichtlich der Gesamtnutzung festgelegt werden.

Es können zusätzliche Schnittstellen eingeführt werden, so dass Bandbreite oder CPU-Serviceebenen explizit ausgehandelt werden können. Explizit angeforderte Ressourcen (beispielsweise eine Anforderung für einen zusätzlichen Thread) können mithilfe von Einschränkungen verwaltet werden.

Steuerungsmechanismen in der Ressourcenverwaltung

Im Betriebssystem Solaris gibt es drei Arten von Steuerungsmechanismen: Einschränkungen, Scheduling und Partitionierung.

Einschränkungen

Mit Einschränkungen kann der Administrator oder Anwendungsentwickler Grenzen für den Verbrauch von bestimmten Ressourcen durch eine Arbeitslast festlegen. Mit bekannten Grenzen wird das Erstellen von Szenarien zum Ressourcenverbrauch einfacher. Grenzen vereinfachen auch die Steuerung fehlerhafter Anwendungen, die sich andernfalls durch unkontrollierte Ressourcenanforderungen negativ auf die Systemleistung oder -verfügbarkeit auswirken würden.

Einschränkungen stellen Komplikationen für eine Anwendung dar. Das Zusammenspiel von Anwendung und System kann bis zu einem Punkt modifiziert werden, an dem die Anwendung nicht mehr ordnungsgemäß funktioniert. Eine Möglichkeit, dieses Risiko zu mindern, besteht darin, die Einschränkungen nur an Anwendungen mit unbekannten Ressourcenverhalten anzuwenden. Die in Kapitel 6Einführung in die Resource Controls beschriebene Funktion der Resource Controls stellt einen solchen Einschränkungsmechanismus dar. Neuere Anwendungen können so geschrieben werden, dass sie sich ihrer Ressourceneinschränkungen bewusst sind, aber nicht alle Autoren nutzen diese Möglichkeit.

Scheduling

Scheduling bedeutet, verschiedene Zuweisungsentscheidungen in bestimmten Intervallen zu treffen. Eine getroffene Entscheidung basiert auf einem berechenbaren Algorithmus. Eine Anwendung, die ihre aktuell zugewiesenen Ressourcen nicht benötigt, überlässt sie einer anderen Anwendung zur Nutzung. Scheduling-basierte Ressourcenverwaltung ermöglicht die volle Auslastung eines nicht vollständig genutzten Systems und steuert gleichzeitig die Zuweisungen in einem kritisch oder übermäßig ausgelastetem Szenario. Der zu Grunde liegende Algorithmus definiert, wie der Begriff „gesteuert“ interpretiert wird. In einigen Fällen kann der Scheduling-Algorithmus garantieren, dass alle Anwendungen einen bestimmten Zugriff auf die Ressourcen haben. Der in Kapitel 8Einführung in den Fair Share Scheduler beschriebene Fair Share Scheduler (FSS) verwaltet und steuert den Zugriff von Anwendungen auf CPU-Ressourcen.

Partitionierung

Die Partitionierung bindet eine Arbeitslast an einen Teil der verfügbaren Systemressourcen. Diese Binding garantiert, dass immer eine bekannte Ressourcenmenge für die Arbeitslast zur Verfügung steht. Mit der in Kapitel 12Einführung in Resource Pools beschriebenen Funktion der Resource Pools können Sie die Arbeitslasten auf bestimmte Teile des Computers beschränken.

Mit Konfigurationen, in denen die Partitionierung eingesetzt wird, lassen sich systemweite Überlastungen vermeiden. Andererseits könnte durch eben dieses Vermeiden von Überlastungen die Fähigkeit, eine möglichst hohe Systemauslastung zu erreichen, beeinträchtigt werden. Befindet sich die an eine Ressourcengruppe (z. B. Prozessoren) gebundene Arbeitslast im Leerlauf, steht diese gebundene Ressourcengruppe nicht mehr anderen Arbeitslasten zur Verfügung.

Konfiguration der Ressourcenverwaltung

Teile der Konfiguration einer Ressourcenverwaltung können in einem Netzwerk-Namen-Service platziert werden. So kann der Administrator die Einschränkungen einer Ressourcenverwaltung auf mehrere Computer anstatt nur auf ein System anwenden. Verwandte Arbeiten können einen gemeinsamen Bezeichner nutzen, und die Gesamtnutzung dieser Arbeiten kann anhand der Accounting-Daten tabellarisch dargestellt werden.

Die Konfiguration der Ressourcenverwaltung und arbeitslastbezogene Bezeichner werden in Kapitel 2Einführung in Projekte und Aufgaben ausführlich beschrieben. Das Extended Accounting, das diese Bezeichner mit der Ressourcennutzung durch Anwendungen verbindet, ist in Kapitel 4Einführung in das Extended Accounting beschrieben.

Interaktion mit Solaris Zones

Die Ressourcenverwaltung kann zusammen mit der Partitionierungssoftware Solaris Zones verwendet werden, um die Anwendungsumgebung genau anzupassen. Die Interaktionen zwischen den Funktionen der Ressourcenverwaltung und Solaris Zones werden in den entsprechenden Abschnitten dieses Handbuchs beschrieben.

Einsatzgebiete für die Ressourcenverwaltung

Die Ressourcenverwaltung wird immer dann eingesetzt, wenn sichergestellt werden muss, dass Ihre Anwendungen vorgeschriebene Reaktionszeiten einhalten.

Die Ressourcenverwaltung kann auch die Ressourcenauslastung erhöhen. Durch Kategorisieren und Priorisieren der Nutzung können freie Kapazitäten außerhalb der Hauptbelastungszeiten effizient genutzt und so häufig den Bedarf für zusätzliche Prozessorleistung eliminiert werden. Außerdem können Sie sicherstellen, dass Ressourcen aufgrund sich ändernder Arbeitslasten nicht ungenutzt bleiben.

Server-Konsolidierung

Die Ressourcenverwaltung eignet sich besonders für Umgebungen, in denen zahlreiche Anwendungen auf einem Server zusammengelegt sind.

Die hohen Kosten für die Verwaltung mehrerer Computer und deren Komplexität sprechen dafür, mehrere Anwendungen auf großen, besser skalierbaren Servern zu konsolidieren. Doch anstatt jeder Arbeitslast auf einem separaten System den vollen Zugriff auf die Systemressourcen zu gewähren, können Sie die Ressourcenverwaltung einsetzen, um Arbeitslasten innerhalb des Systems zu trennen. Die Ressourcenverwaltung kann zur Senkung der Gesamtkosten beitragen, indem mehrere unterschiedliche Anwendungen auf einem einzigen Solaris-System ausgeführt und gesteuert werden.

Wenn Sie Internet- und Anwendungsservices bereitstellen, können Sie mit der Ressourcenverwaltung:

• Mehrere Webserver auf einem Computer hosten. Den Ressourcenverbrauch jeder Website steuern und jede Site vor potentiellem übermäßigen Ressourcenverbrauch anderer Sites schützen.

• Den übermäßigen Verbrauch von CPU-Ressourcen durch ein fehlerhaftes Common Gateway Interface (CGI)-Skript verhindern.

• Den Verbrauch des gesamten verfügbaren virtuellen Speicher durch eine fehlerhafte Anwendung verhindern.

• Sicherstellen, dass die Anwendungen eines Kunden keine Anwendungen anderer Kunden beeinflussen, die am gleichen Standort ausgeführt werden.

• Unterschiedliche Serviceebenen oder -klassen auf dem gleichen Computer bereitstellen.

• Accounting-Daten für Abrechnungszwecke beziehen.

Unterstützen einer großen oder variierenden Benutzerzahl

Ein ideales Einsatzgebiet für die Ressourcenverwaltung ist ein System, das zahlreiche Benutzer mit unterschiedlichen Anforderungen bedient, z. B. bei einem Bildungsinstitut. Wenn unterschiedliche Arbeitslasten vorliegen, kann die Software so konfiguriert werden, dass sie bestimmten Projekten Prioritäten einräumt.

Beispielsweise benötigen die Broker großer Maklerfirmen in unregelmäßigen Abständen schnellen Zugriff auf Ressourcen, um eine Abfrage oder eine Berechnung durchzuführen. Andere Systembenutzer haben hingegen konsistente Arbeitslasten. Wenn Sie den Projekten der Broker einen proportional größeren Betrag der Rechenleistung zuweisen, haben sie die benötigte Reaktionsschnelligkeit.

Die Ressourcenverwaltung eignet sich auch ideal für die Unterstützung von Thin-Client-Systemen. Diese Plattformen bieten statusfreie Konsolen mit Frame-Buffern und Eingabegeräte, z. B. SmartCards. Die tatsächliche Berechnung erfolgt auf einen gemeinsam genutzten Server, die gesamte Umgebung entspricht einem Timesharing-Modell. Mit den Funktionen der Ressourcenverwaltung können Sie die Benutzer auf dem Server voneinander isolieren. In diesem Fall kann ein Benutzer, der eine übermäßig hohe Last erzeugt, keine Hardwareressourcen monopolisieren oder die Leistung anderer Benutzer des gleichen Systems negativ beeinflussen.

Einrichten der Ressourcenverwaltung (Übersicht der Schritte)

Die folgende Übersicht der Schritte bietet einen allgemeinen Überblick der Schritte, die zum Einrichten der Ressourcenverwaltung auf dem System erforderlich sind.

Kapitel 2 Einführung in Projekte und Aufgaben

In diesem Kapitel werden die Funktionen Projekt und Aufgabe der Solaris-Ressourcenverwaltung beschrieben. Mit Projekten und Aufgaben werden Arbeitslasten bezeichnet (mit einem Label versehen) und voneinander getrennt.

In diesem Kapitel werden folgende Themen behandelt:

• Projekte und Aufgaben

• Projektbezeichner

• Aufgabenbezeichner

• Mit Projekten und Aufgaben verwendete Befehle

Wie Projekte und Aufgaben verwendet werden, lesen Sie in Kapitel 3Verwalten von Projekten und Aufgaben (Vorgehen).

Neuerungen bei der Projektdatenbank und den Resource Control-Befehlen für Solaris 10

Zu den Erweiterungen von Solaris 10 gehören:

• Unterstützung für skalierte Wert- und Einheitenmodifizierer für Ressourcenobjektwerte und -befehle

• Verbesserte Validierung und vereinfachter Umgang mit dem Projektattributfeld

• Überarbeitetes Ausgabeformat und neue Optionen für die Befehle prctl und projects

• Möglichkeit zum Einstellen eines Benutzer-Standardprojekts mit dem Befehl useradd und Bearbeiten der Informationen mit den Befehlen usermod und passmgmt

Neben den Informationen in diesem Kapitel und in Kapitel 6Einführung in die Resource Controls sollten Sie auch die folgenden Manpages lesen:

• passmgmt(1M)

• projadd(1M)

• projmod(1M)

• useradd(1M)

• usermod(1M)

• resource_controls(5)

Zu den Erweiterungen von Solaris 10 5/08 gehört die neue Option -A des Befehls projmod. Siehe Mit Projekten und Aufgaben verwendete Befehle.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Projekte und Aufgaben

Um die Reaktionen von Arbeitslasten zu optimieren, müssen Sie zunächst die Arbeitslasten identifizieren können, die auf dem analysierten System ausgeführt werden. Diese Informationen sind jedoch mit einem rein prozessorientierten oder einen rein benutzerorientierten Ansatz nur schwer zu beziehen. Das Solaris System bietet Ihnen jedoch zwei zusätzliche Funktionen, mit denen Sie Arbeitslasten voneinander trennen und identifizieren können: das Projekt und die Aufgabe. Das Projekt bietet einen netzwerkweit geltenden administrativen Bezeichner für miteinander verwandte Arbeiten. Die Aufgabe fasst eine Prozessgruppe zu einer überschaubaren Einheit, einer Arbeitslastkomponente zusammen.

Die in der Namen-Service-Datenbank project angegebenen Resource Controls sind auf Prozess, Aufgabe und Projekt eingestellt. Da Resource Controls für Prozesse und Aufgaben über die Systemaufrufe fork und settaskid vererbt werden, gehen alle diese Resource Controls auf alle Prozesse und Aufgaben über, die innerhalb des Projekt erstellt werden. Weitere Informationen zu diesen Systemaufrufen finden Sie in den Manpages fork(2) und settaskid(2).

Basierend auf ihrer Projekt- oder Aufgabenmitgliedschaft können laufende Prozesse mit standardmäßigen Solaris-Befehlen bearbeitet werden. Mit dem Extended Accounting können Berichte zur Prozess- und Aufgabennutzung erstellt und jeder Datensatz mit einem übergeordneten Projektbezeichner versehen werden. Dieser Prozess ermöglicht, dass die Offline-Analyse von Arbeitslasten mit der Online-Überwachung abgestimmt wird. Der Projektbezeichner kann über die Namen-Service-Datenbank project auf mehreren Computern genutzt werden. Auf diese Weise kann der Ressourcenverbrauch durch verwandte Arbeitslasten, die auf mehreren Computern ausgeführt werden (oder mehrere Computer umfassen), über alle Computer analysiert werden.

Projektbezeichner

Der Projektbezeichner ist ein administrativer Bezeichner zur Identifikation von verwandten Aufgaben. Der Projektbezeichner ist im Prinzip das Arbeitslast-Tag-Äquivalent zu den Benutzer- und Gruppenbezeichnern. Ein Benutzer oder eine Gruppe können zu einem oder mehreren Projekten gehören. Mit diesen Projekten werden die Arbeitslasten dargestellt, an denen der Benutzer (oder die Benutzergruppe) teilnehmen darf. Diese Mitgliedschaft kann als Basis des Chargeback verwendet werden, auf der z. B. die Nutzung oder die ursprünglichen Ressourcenzuordnungen basieren. Obwohl einem Benutzer ein Standardprojekt zugewiesen sein muss, können die vom Benutzer gestarteten Prozesse zu jedem Projekt gehören, bei dem der Benutzer Mitglied ist.

Festlegen des Standardprojekt eines Benutzers

Jedem Benutzer muss ein Standardprojekt zugewiesen sein, damit er bzw. sie sich beim System anmelden kann. Ein Benutzer ist automatisch Mitglied dieses Standardprojekts. Dies gilt auch dann, wenn der Benutzer nicht in der für das Projekt angegebenen Benutzer- oder Gruppenliste enthalten ist.

Da jeder Prozess auf einem System über eine Projektmitgliedschaft verfügt, ist ein Algorithmus erforderlich, der bei der Anmeldung ein Standardprojekt oder einen anderen Anfangsprozess zuweist. Dieser Algorithmus ist in der Manpage getprojent(3C) beschrieben. Zur Ermittlung des Standardprojekts führt das System die im Folgenden aufgeführten Schritte in der angegebenen Reihenfolge aus. Wenn kein Standardprojekt gefunden wurde, wird die Benutzeranmeldung oder Anfrage nach einem Prozessstart verweigert.

Das System führt nacheinander die folgenden Schritte aus, um das Standardprojekt eines Benutzers zu ermitteln:

1. Verfügt der Benutzer über einen Eintrag mit einem project-Attribut in der Datenbank mit den erweiterten Benutzerattributen /etc/user_attr, wird der Wert des project-Attributs als Standardprojekt verwendet. Weitere Informationen finden Sie in der Manpage user_attr(4).

2. Ist ein Projekt mit dem Namen user.Benutzer-ID in der project-Datenbank vorhanden, wird dieses Projekt als Standardprojekt verwendet. Weitere Informationen entnehmen Sie bitte der Manpage krb5.conf (4).project(4)

3. Ist ein Projekt mit dem Namen group.Gruppenname in der project-Datenbank vorhanden und ist Gruppenname der Name der Standardgruppe des Benutzers (gemäß der passwd-Datei), wird dieses Projekt als Standardprojekt verwendet. Weitere Informationen zur passwd-Datei finden Sie in der Manpage passwd(4).

4. Ist das Sonderprojekt default in der project-Datenbank vorhanden, wird dieses Projekt als Standardprojekt verwendet.

Die Logik wird von der Bibliotheksfunktion getdefaultproj() bereitgestellt. Weitere Informationen finden Sie in der Manpage getprojent(3PROJECT).

Einrichten von Benutzerattributen mit den Befehlen useradd , usermod und passmgmt

Mit den folgenden Befehlen und der Option -K sowie einem Schlüssel=Wert-Paar können Sie die Benutzerattribute in lokalen Dateien einrichten:

passmgmt

Ändern vom Benutzerinformationen

useradd

Einrichten des Standardprojekts eines Benutzers

usermod

Ändern vom Benutzerinformationen

Lokale Dateien können Folgende umfassen:

• /etc/group

• /etc/passwd

• /etc/project

• /etc/shadow

• /etc/user_attr

Wenn eine lokale Datei mit einem Netzwerk-Namen-Service wie NIS um zusätzliche Einträge ergänzt wird, können diese Befehle nicht zum Ändern der vom Netzwerk-Namen-Service bereitgestellten Daten verwendet werden. Mit den Befehlen kann jedoch Folgendes mit einer externen Namen-Service-Datenbank verglichen werden:

• Eindeutigkeit des Benutzernamens (bzw. der Rolle)

• Eindeutigkeit der Benutzer-ID

• Vorhandensein der angegebenen Gruppennamen

Weitere Informationen finden Sie in den Manpages passmgmt(1M), useradd(1M), usermod(1M) und user_attr(4).

project-Datenbank

Sie können die Projektdaten in einer lokalen Datei, in einer Network Information Service (NIS)-Projektmap oder in einem Lightweight Directory Access Protocol (LDAP)-Verzeichnisservice speichern. Die Datei /etc/project oder der Namen-Service wird bei der Anmeldung und bei allen Anfragen zum Kontomanagement durch die plugfähige Authentifizierung (Pluggable Authentication Module, PAM) verwendet, um einen Benutzer an einen Standardprojekt zu binden.

Aktualisierungen der Einträge in der Projektdatenbank, ob an der Datei /etc/project oder an einer Repräsentation der Datenbank in einem Netzwerk-Namen-Service, werden nicht für die jeweils aktiven Projekte übernommen. Die Aktualisierungen werden jedoch für neue Aufgaben übernommen, die einem Projekt über die Befehle login oder newtask hinzugefügt werden. Weitere Informationen finden Sie in den Manpages login(1) und newtask(1).

PAM-Untersystem

Zu den Vorgängen, bei denen Identitäten geändert oder eingestellt werden, gehören die Anmeldung beim System, das Aufrufen des Befehls rcp oder rsh, oder das Verwenden von ftp oder su. Wenn ein Vorgang u. a. eine Identität ändert oder einstellt, wird ein Set mit konfigurierbaren Modulen verwendet, um Funktionen zur Authentifizierung, Kontoverwaltung und Sitzungsverwaltung bereitzustellen.

Das PAM-Modul zur Kontoverwaltung für Projekte ist in der Manpage pam_projects(5) dokumentiert. Eine Übersicht zum PAM finden Sie in Kapitel 17, Using PAM in System Administration Guide: Security Services.

Konfiguration der Namen-Services

Die Ressourcenverwaltung unterstützt die project-Datenbanken der Namen-Services. Der Speicherort der project-Datenbank ist in der Datei /etc/nsswitch.conf definiert. Standardmäßig wird files zuerst aufgelistet, aber die Quellen können in einer beliebigen Reihenfolge erscheinen.

project: files [nis] [ldap]

Wenn mehrere Quellen für die Projektinformationen aufgelistet sind, sorgt die Datei nsswitch.conf dafür, dass die Suche nach Informationen in der ersten aufgeführten Quelle beginnt, dann werden alle aufgeführten Quellen nacheinander durchsucht.

Weitere Informationen zur Datei /etc/nsswitch.conf finden Sie in Kapitel 2, The Name Service Switch (Overview) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) und in der Manpage nsswitch.conf(4).

Format der lokalen Datei /etc/project

Wenn Sie files als project-Datenbankquelle in der Datei nsswitch.conf auswählen, sucht der Anmeldeprozess in der Datei /etc/project nach Projektinformationen. Weitere Informationen finden Sie in den Manpages projects(1) und project(4).

Die Datei project enthält für jedes vom System erkannte Projekt einen einzeiligen Eintrag in dem folgenden Format:

projname:projid:comment:user-list:group-list:attributes

Die Felder sind wie folgt definiert:

Projname

Der Name des Projekts. Der Name muss aus einer Zeichenfolge mit alphanumerischen Zeichen, Unterstrichen (_), Bindestrichen (-) und Punkten (.) bestehen. Der Punkt, der für Projekte mit besonderer Bedeutung für das Betriebssystem reserviert ist, kann nur in denNamen der Benutzer-Standardprojekte verwendet werden. Projname darf keinen Doppelpunkt (: ) oder ein Absatzzeichen enthalten.

Projid

Die einmalige numerische ID des Projekts (PROJID) innerhalb des Systems. Der Höchstwert im Feld Projid ist UID_MAX ( 2147483647).

Kommentar

Eine Beschreibung des Projekts.

Benutzerliste

Eine durch Kommata getrennte Liste der im Projekt zulässigen Benutzer.

In diesem Feld können Platzhalter verwendet werden. Bei einem Sternchen (*) ist es allen Benutzern gestattet, dem Projekt beizutreten. Bei einem Ausrufezeichen gefolgt von einem Sternchen (!*) sind alle Benutzer vom Projekt ausgeschlossen. Ein Ausrufezeichen (!) gefolgt von einem Benutzernamen schließt den angegebenen Benutzer vom Projekt aus.

Gruppenliste

Eine durch Kommata getrennte Liste der im Projekt zulässigen Gruppen.

In diesem Feld können Platzhalter verwendet werden. Bei einem Sternchen (*) ist es allen Gruppen gestattet, dem Projekt beizutreten. Bei einem Ausrufezeichen gefolgt von einem Sternchen (!*) sind alle Gruppen·vom Projekt ausgeschlossen. Ein Ausrufezeichen (!) gefolgt von einem Gruppennamen schließt die angegebene Gruppe vom Projekt aus.

Attribute

Eine durch Semikola getrennte Liste von Name/Wert-Paaren, zum Beispiel Resource Controls (siehe Kapitel 6Einführung in die Resource Controls). Name ist eine willkürliche Zeichenfolge, die das objektbezogene Attribut angibt, und Wert ist der optionale Wert für das Attribut.

name[=value]

In Name/Wert-Paaren sind die Namen auf Buchstaben, Zahlen, Unterstriche und Punkte beschränkt. Ein Punkt wird in der Regel als Trennzeichen zwischen den Kategorien und Unterkategorien der Resource Control (rctl) verwendet. Das erste Zeichen eines Attributnamens muss ein Buchstabe sein. Der Name ist abhängig von der Groß-/Kleinschreibung.

Werte können mithilfe von Kommata und Klammern strukturiert werden, um eine Rangfolge herzustellen.

Ein Semikolon dient zum Trennen von Name/Wert-Paaren. Es kann nicht in einer Wertdefinition verwendet werden. Ein Doppelpunkt dient zum Trennen von Projektfeldern. Er kann nicht in einer Wertdefinition verwendet werden.

Programmroutinen, die diese Datei einlesen, stoppen bei einem falsch formatierten Eintrag. Projekte, die hinter einem falschen formatierten Eintrag aufgeführt sind, werden nicht zugewiesen.

Das folgende Beispiel zeigt die Standarddatei /etc/project:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::

Das folgende Beispiel zeigt die Standarddatei /etc/project, an deren Ende Projekteinträge hinzugefügt wurden:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::
user.ml:2424:Lyle Personal:::
booksite:4113:Book Auction Project:ml,mp,jtd,kjh::

Sie können der Datei /etc/project auch Resource Controls und Attribute hinzufügen:

• Wie Sie einem Projekt Resource Controls hinzufügen, können Sie unter Einrichten von Resource Controls nachlesen.

• Wie Sie mithilfe des in der Manpage rcapd(1M) beschriebenen Resource Capping Daemon eine Memory Resource Cap für ein Projekt hinzufügen, ist unter Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte beschrieben.

• Wie Sie einem Projekteintrag ein project.pool-Attribut hinzufügen, können Sie unter Erstellen der Konfiguration nachlesen.

Projektkonfiguration für NIS

Wenn Sie NIS verwenden, können Sie in der Datei /etc/nsswitch.conf angeben, die NIS-Projektmaps nach Projekten zu durchsuchen:

project: nis files 

Die NIS-Maps, entweder project.byname oder project.bynumber, weisen das gleiche Format wie die Datei /etc/project auf:

projname:projid:comment:user-list:group-list:attributes

Weitere Informationen finden Sie in Kapitel 4, Network Information Service (NIS) (Overview) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Projektkonfiguration für LDAP

Wenn Sie LDAP verwenden, können Sie in der Datei /etc/nsswitch.conf angeben, die LDAP-Datenbank project nach Projekten zu durchsuchen:

project: ldap files

Weitere Informationen zu LDAP finden Sie in Kapitel 8, Introduction to LDAP Naming Services (Overview/Reference) in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Weitere Informationen zum Schema für Projekteinträge in einer LDAP-Datenbank finden Sie unter Solaris Schemas in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Aufgabenbezeichner

Jede erfolgreiche Anmeldung bei einem Projekt erstellt eine neue Aufgabe, die den Anmeldeprozess enthält. Eine Aufgabe ist eine Sammlung von Prozessen, die ein Arbeitsset über die Zeit darstellt. Eine Aufgabe kann auch als eine Arbeitslastkomponente betrachtet werden. Jeder Aufgabe wird automatisch eine Aufgaben-ID zugewiesen.

Jeder Prozess ist Mitglied einer Aufgabe, und jede Aufgabe ist einem Projekt zugeordnet.

Abbildung 2–1 Projekt- und Aufgabenstruktur

Alle Vorgänge in Prozessgruppen, z. B. die Signalübermittlung, werden auch für Aufgaben unterstützt. Sie können eine Aufgabe auch an ein Prozessorset binden und eine Scheduling-Priorität und -klasse für die Aufgabe einrichten, wodurch alle aktuellen und folgenden Prozesse in der Aufgabe geändert werden.

Eine Aufgabe wird immer dann erstellt, wenn ein Projekt verbunden wird. Aufgaben werden mit den folgenden Aktionen, Befehle und Funktionen erstellt:

• login

• cron

• newtask

• setproject

• su

Eine abgeschlossene Aufgabe wird mit einer der folgenden Methoden erstellt. Alle weiteren Versuche, neue Aufgaben zu erstellen, schlagen fehl.

• Geben Sie den Befehl newtask mit der Option -F ein.

• Setzen Sie das Attribut task.final auf ein Projekt in der project-Datenbank des Namen-Service. Alle Aufgaben, die mit setproject in diesem Projekt erstellt werden, weisen das Flag TASK_FINAL auf.

Weitere Informationen finden Sie in den Manpages login(1), newtask(1), cron(1M), su(1M) und setproject(3PROJECT).

Accounting-Daten für Prozesse können mit dem Extended Accounting bereitgestellt werden. Die Daten werden auf Aufgabenebene zusammengefasst.

Mit Projekten und Aufgaben verwendete Befehle

Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zu Projekten und Aufgaben dar.

Kapitel 3 Verwalten von Projekten und Aufgaben (Vorgehen)

In diesem Kapitel wird beschrieben, wie die Leistungsmerkmale Projekt und Aufgabe der Solaris-Ressourcenverwaltung verwendet werden.

In diesem Kapitel werden folgende Themen behandelt.

• Beispiele für Befehle und Befehlsoptionen

• Verwalten von Projekten

Eine allgemeine Einführung in die Leistungsmerkmale Projekte und Aufgaben finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.

Wenn Sie diese Funktionen auf einem Solaris-System mit installierten Zonen verwenden, sind über die Systemaufruf-Schnittstellen, die Prozess-IDs akzeptieren, nur Prozesse in der gleichen Zone sichtbar (wenn diese Befehle in einer nicht-globalen Zone ausgeführt werden).

Verwalten von Projekten und Aufgaben (Übersicht der Schritte)

Beispiele für Befehle und Befehlsoptionen

Im folgenden Abschnitt sind Beispiele für Befehle und Optionen aufgeführt, die mit Projekten und Aufgaben verwendet werden können.

Mit Projekten und Aufgaben verwendete Befehlsoptionen

ps-Befehl

Mit dem Befehl ps und der Option -o können Sie die Aufgaben- und Projekt-IDs anzeigen. Um beispielsweise die Projekt-ID anzuzeigen, geben Sie Folgendes ein:

# ps -o user,pid,uid,projid
USER PID   UID  PROJID
jtd  89430 124  4113

id-Befehl

Mit dem Befehl id und der Option -p können Sie die aktuelle Projekt-ID nebst Benutzer- und Gruppen-IDs drucken. Wenn der Operand Benutzer angegeben ist, wird das Projekt gedruckt, das dem Anmeldenamen dieses Benutzers zugeordnet ist:

#  id -p
uid=124(jtd) gid=10(staff) projid=4113(booksite)

pgrep- und pkill-Befehle

Um nur Prozesse mit einer Projekt-ID in einer bestimmten Liste zu suchen, geben Sie die Befehle pgrep und pkill mit der Option -J ein:

# pgrep -J projidlist
# pkill -J projidlist

Um nur Prozesse mit einer Aufgaben-ID in einer bestimmten Liste zu suchen, geben Sie die Befehle pgrep und pkill mit der Option -T ein:

# pgrep -T taskidlist
# pkill -T taskidlist

prstat-Befehl

Um verschiedene Statistiken zu Prozessen und Projekten anzuzeigen, die aktuell auf dem System ausgeführt werden, geben Sie den Befehl prstat mit der Option -J ein:

% prstat -J
	  PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 21634 jtd      5512K 4848K cpu0    44    0   0:00.00 0.3% prstat/1
   324 root       29M   75M sleep   59    0   0:08.27 0.2% Xsun/1
 15497 jtd        48M   41M sleep   49    0   0:08.26 0.1% adeptedit/1
   328 root     2856K 2600K sleep   58    0   0:00.00 0.0% mibiisa/11
  1979 jtd      1568K 1352K sleep   49    0   0:00.00 0.0% csh/1
  1977 jtd      7256K 5512K sleep   49    0   0:00.00 0.0% dtterm/1
   192 root     3680K 2856K sleep   58    0   0:00.36 0.0% automountd/5
  1845 jtd        24M   22M sleep   49    0   0:00.29 0.0% dtmail/11
  1009 jtd      9864K 8384K sleep   49    0   0:00.59 0.0% dtwm/8
   114 root     1640K  704K sleep   58    0   0:01.16 0.0% in.routed/1
   180 daemon   2704K 1944K sleep   58    0   0:00.00 0.0% statd/4
   145 root     2120K 1520K sleep   58    0   0:00.00 0.0% ypbind/1
   181 root     1864K 1336K sleep   51    0   0:00.00 0.0% lockd/1
   173 root     2584K 2136K sleep   58    0   0:00.00 0.0% inetd/1
   135 root     2960K 1424K sleep    0    0   0:00.00 0.0% keyserv/4
PROJID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT
    10       52  400M  271M    68%   0:11.45 0.4% booksite
     0       35  113M  129M    32%   0:10.46 0.2% system

Total: 87 processes, 205 lwps, load averages: 0.05, 0.02, 0.02

Um verschiedene Statistiken zu Prozessen und Aufgaben anzuzeigen, die aktuell auf dem System ausgeführt werden, geben Sie den Befehl prstat mit der Option -T ein:

% prstat -T
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 23023 root       26M   20M sleep   59    0   0:03:18 0.6% Xsun/1
 23476 jtd        51M   45M sleep   49    0   0:04:31 0.5% adeptedit/1
 23432 jtd      6928K 5064K sleep   59    0   0:00:00 0.1% dtterm/1
 28959 jtd        26M   18M sleep   49    0   0:00:18 0.0% .netscape.bin/1
 23116 jtd      9232K 8104K sleep   59    0   0:00:27 0.0% dtwm/5
 29010 jtd      5144K 4664K cpu0    59    0   0:00:00 0.0% prstat/1
   200 root     3096K 1024K sleep   59    0   0:00:00 0.0% lpsched/1
   161 root     2120K 1600K sleep   59    0   0:00:00 0.0% lockd/2
   170 root     5888K 4248K sleep   59    0   0:03:10 0.0% automountd/3
   132 root     2120K 1408K sleep   59    0   0:00:00 0.0% ypbind/1
   162 daemon   2504K 1936K sleep   59    0   0:00:00 0.0% statd/2
   146 root     2560K 2008K sleep   59    0   0:00:00 0.0% inetd/1
   122 root     2336K 1264K sleep   59    0   0:00:00 0.0% keyserv/2
   119 root     2336K 1496K sleep   59    0   0:00:02 0.0% rpcbind/1
   104 root     1664K  672K sleep   59    0   0:00:03 0.0% in.rdisc/1
TASKID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT                     
   222       30  229M  161M    44%   0:05:54 0.6% group.staff                 
   223        1   26M   20M   5.3%   0:03:18 0.6% group.staff                 
    12        1   61M   33M   8.9%   0:00:31 0.0% group.staff                 
     1       33   85M   53M    14%   0:03:33 0.0% system                      

Total: 65 processes, 154 lwps, load averages: 0.04, 0.05, 0.06	

Die Optionen -J und -T können nicht zusammen verwendet werden.

Verwenden der Befehle cron und su mit Projekten und Aufgaben

cron-Befehl

Der Befehl cron gibt eine settaskid aus, mit der sichergestellt wird, dass jeder cron-, at- und batch-Job in einer separaten Aufgabe mit dem entsprechenden Standardprojekt für den übermittelnden Benutzer ausgeführt wird. Darüber hinaus erfassen die Befehle at und batch die aktuelle Projekt-ID, wodurch sichergestellt wird, dass die Projekt-ID beim Ausführen eines at-Jobs wiederhergestellt wird.

su-Befehl

Mit dem Befehl su wird das Standardprojekt des Zielbenutzers als Teil einer simulierten Anmeldung durch das Erstellen einer neuen Aufgabe aufgenommen.

Um das Standardprojekt des Benutzers mit dem Befehl su zu ändern, geben Sie Folgendes ein:

# su user

Verwalten von Projekten

So definieren Sie ein Projekt und zeigen das aktuelle Projekt an

Im folgenden Beispiel wird gezeigt, wie Sie einen Projekteintrag mit dem Befehl projadd hinzufügen und diesen Eintrag dann mit dem Befehl projmod ändern.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Zeigen Sie die Standarddatei /etc/project auf dem System mit dem Befehl projects -l an.

   # projects -l system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

3. Fügen Sie ein Projekt mit dem Namen booksite hinzu. Weisen Sie das Projekt dem Benutzer mark mit der Projekt-ID 4113 zu.

   # projadd -U mark -p 4113 booksite

4. Zeigen Sie die Datei /etc/project noch einmal an.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "" users : mark groups : (none) attribs:

5. Fügen Sie einen Kommentar, der das Projekt beschreibt, in das Kommentarfeld ein.

   # projmod -c `Book Auction Project' booksite

6. Zeigen Sie die Änderungen in der Datei /etc/project an.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "Book Auction Project" users : mark groups : (none) attribs:

Siehe auch

Wie Sie Projekte, Aufgaben und Prozesse an einen Pool binden, können Sie unter Einrichten von Pool-Attributen und Binden an einen Pool nachlesen.

So löschen Sie ein Projekt aus der Datei /etc/project

Im folgenden Beispiel wird gezeigt, wie Sie ein Projekt mit dem Befehl projdel löschen.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Entfernen Sie das Projekt booksite mit dem Befehl projdel.

   # projdel booksite

3. Zeigen Sie die Datei /etc/project an.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

4. Melden Sie sich als der Benutzer mark an und geben Sie projects ein, um die Projekte anzuzeigen, die diesem Benutzer zugeordnet sind.

   # su - mark # projects default

So validieren Sie den Inhalt der Datei /etc/project

Wenn keine Bearbeitungsoptionen angegeben sind, validiert der Befehl projmod den Inhalt der Datei project.

Zum Validieren einer NIS-Map melden Sie sich als Superuser an und geben Folgendes ein:

# ypcat project | projmod -f —

Der Befehl ypcat project | projmod -f - ist noch nicht implementiert.

Zum Überprüfen der Syntax der Datei /etc/project geben Sie Folgendes ein:

# projmod -n

So beziehen Sie Informationen zur Projektmitgliedschaft

Geben Sie den Befehl id mit der Option -p ein, um die aktuelle Projektmitgliedschaft des aufrufenden Prozesses anzuzeigen.

$ id -p
uid=100(mark) gid=1(other) projid=3(default)

So erstellen Sie eine neue Aufgabe

1. Melden Sie sich als ein Mitglied des Zielprojekts booksite an.

2. Erstellen Sie eine neue Aufgabe im Projekt booksite. Geben Sie dazu den Befehl newtask mit der Option -v (verbose) ein, um die System-Aufgaben-ID zu beziehen.

   machine% newtask -v -p booksite 16

   Die Ausführung von newtask erstellt eine neue Aufgabe im angegebenen Projekt und platziert die Standard-Shell des Benutzers in dieser Aufgabe.

3. Zeigen Sie die aktuelle Projektmitgliedschaft des aufrufenden Prozesses an.

   machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite)

   Der Prozess ist jetzt Mitglied des neuen Projekts.

So verschieben Sie einen laufenden Prozess in eine neue Aufgabe

Im folgenden Beispiel wird gezeigt, wie Sie einen laufenden Prozess einer anderen Aufgabe und einem neuen Projekt zuweisen. Um diese Aktion auszuführen, müssen Sie entweder als Superuser angemeldet oder Eigentümer des Prozesses und Mitglied des neuen Projekts sein.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Wenn Sie Eigentümer des Prozesses oder Mitglied des neuen Projekts sind, können Sie diesen Schritt überspringen.

   ---

2. Beziehen Sie die Projekt-ID des Prozesses book_catalog.

   # pgrep book_catalog 8100

3. Ordnen Sie den Prozess 8100 der neuen Aufgaben-ID im Projekt booksite zu.

   # newtask -v -p booksite -c 8100 17

   Die Option -c gibt an, dass newtask auf den bestehenden benannten Prozess angewendet wird.

4. Bestätigen Sie die Zuordnung der Aufgabe zur Prozess-ID.

   # pgrep -T 17 8100

Bearbeiten und Validieren von Projektattributen

Mit den Projektdatenbank-Administrationsbefehlen projadd und projmod können Sie die Projektattribute bearbeiten.

Die Option -K gibt eine Ersatzliste der Attribute an. Attribute werden durch Semikola (;) voneinander getrennt. Wenn die Option -K mit der Option -a angegeben ist, wird das Attribut oder der Attributwert hinzugefügt. Wenn die Option -K mit der Option -r angegeben ist, wird das Attribut oder der Attributwert entfernt. Wenn die Option -K mit der Option -s angegeben ist, wird das Attribut oder der Attributwert ersetzt.

So fügen Sie Projekten Attribute und Attributwerte hinzu

Geben Sie den Befehl projmod mit den Optionen -a und -K ein, um einem Projektattribut Werte hinzuzufügen. Wenn das Attribut nicht existiert, wird es erstellt.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Geben Sie das Resource Control-Attribut task.max-lwps ohne Werte in das Projekt myproject ein. Eine in das Projekt aufgenommene Aufgabe weist nur den Systemwert für das Attribut auf.

   # projmod -a -K task.max-lwps myproject

3. Anschließend können Sie dem Projekt myproject einen Wert für task.max-lwps hinzufügen. Der Wert setzt sich aus einer Berechtigungsstufe, einem Schwellenwert und einer Aktion zusammen, die ausgeführt wird, wenn der Schwellenwert erreicht ist.

   # projmod -a -K "task.max-lwps=(priv,100,deny)" myproject

4. Da Resource Controls mehrere Werte akzeptieren, können Sie der vorhandenen Werteliste mit den gleichen Optionen einen weiteren Wert hinzufügen.

   # projmod -a -K "task.max-lwps=(priv,1000,signal=KILL)" myproject

   Mehrere Werte werden durch Kommata voneinander getrennt. Der Eintrag task.max-lwps lautet jetzt wie folgt:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

So entfernen Sie Attributwerte aus Projekten

Bei diesem Verfahren werden folgende Werte angenommen:

task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Um einen Attributwert von der Resource Control task.max-lwps im Projekt myproject zu entfernen, geben Sie den Befehl projmod mit den Optionen -r und -K ein.

   # projmod -r -K "task.max-lwps=(priv,100,deny)" myproject

   Wenn task.max-lwps mehrere Werte enthält, z. B.:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

   wird nur der erste entsprechende Wert gelöscht. Das Ergebnis wäre:

   task.max-lwps=(priv,1000,signal=KILL)

So entfernen Sie ein Resource Control-Attribut aus einem Projekt

Um die Resource Control task.max-lwps aus dem Projekt myproject zu entfernen, geben Sie den Befehl projmod mit den Optionen -r und -K ein.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Entfernen Sie das Attribut task.max-lwps und alle zugehörigen Werte aus dem Projekt myproject:

   # projmod -r -K task.max-lwps myproject

So ersetzen Sie Attribute und Attributwerte für Projekte

Um einen anderen Wert für das Attribut task.max-lwps im Projekt myproject einzusetzen, geben Sie den Befehl projmod mit den Optionen -s und -K ein. Wenn das Attribut nicht existiert, wird es erstellt.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Ersetzen Sie die aktuellen Werte für task.max-lwps durch die angezeigten neuen Werte:

   # projmod -s -K "task.max-lwps=(priv,100,none),(priv,120,deny)" myproject

   Das Ergebnis wäre:

   task.max-lwps=(priv,100,none),(priv,120,deny)

So entfernen Sie vorhandene Werte für ein Resource Control-Attribut

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Um die aktuellen Werte für die Resource Control task.max-lwps aus dem Projekt myproject zu entfernen, geben Sie Folgendes ein:

   # projmod -s -K task.max-lwps myproject

Kapitel 4 Einführung in das Extended Accounting

Mit den in Kapitel 2Einführung in Projekte und Aufgaben beschriebenen Leistungsmerkmalen Projekt und Aufgabe zum Bezeichnen und Trennen von Arbeitslasten können Sie den Ressourcenverbrauch durch einzelne Arbeitslasten überwachen. Mit dem Subsystem Extended Accounting können Sie detaillierte Statistiken zum Ressourcenverbrauch durch Prozesse und Aufgaben erfassen.

In diesem Kapitel werden folgende Themen behandelt.

• Einführung in das Extended Accounting

• Funktionsweise des Extended Accounting

• Konfiguration des Extended Accounting

• Mit Extended Accounting verwendete Befehle

• Perl-Schnittstelle für libexacct

Wenn Sie direkt mit der Arbeit in Extended Accounting beginnen möchten, lesen Sie So aktivieren Sie das Extended Accounting für Prozesse, Aufgaben und Flows.

Neue Funktionen im Extended Accounting für Solaris 10

mstate-Daten für das Prozess-Accounting können jetzt erstellt werden. Lesen Sie dazu So zeigen Sie die verfügbaren Accounting-Ressourcen an.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Einführung in das Extended Accounting

Das Subsystem Extended Accounting kennzeichnet Nutzungsdatensätze mit dem Projekt, für das die Arbeit ausgeführt wurde. Sie können das Extended Accounting auch zusammen mit dem in Kapitel 36, Verwenden von Flow Accounting und Erfassen von Statistiken (Aufgaben) in Systemverwaltungshandbuch: IP ServicesSystem Administration Guide: IP Services beschriebenen Internet Protocol Quality of Service (IPQoS) Flow Accounting-Modul verwenden, um Informationen zu den Netzwerkabläufen auf einem System zu erfassen.

Bevor Sie die Mechanismen einer Ressourcenverwaltung anwenden können, müssen Sie den Ressourcenverbrauch durch die verschiedenen Arbeitslasten auf dem System einschätzen. Das Extended Accounting im Betriebssystem Solaris kann den System- und Netzwerk-Ressourcenverbrauch auf Aufgaben- oder Prozessbasis oder auf Basis von Selektoren, die vom IPQoS-Modul flowacct bereitgestellt werden, flexibel erfassen. Weitere Informationen finden Sie unter ipqos(7IPP).

Im Gegensatz zu Online-Überwachungstools, die die Systemnutzung in Echtzeit messen, können Sie mit dem Extended Accounting Verlaufsdaten zur Nutzung auswerten. Mit diesen Ergebnissen können Sie Einschätzungen der Kapazitätsanforderungen künftiger Arbeitslasten erstellen.

Wenn Ihnen Daten aus dem Extended Accounting zur Verfügung stehen, können Sie Software zum Ressourcen-Chargeback, zur Arbeitlastüberwachung oder zur Kapazitätsplanung entwickeln oder erwerben.

Funktionsweise des Extended Accounting

Das Extended Accounting im Betriebssystem Solaris verwendet für die Accounting-Daten ein mit Versionsnummer gekennzeichnetes, erweiterbares Dateiformat. Dateien in diesem Dateiformat können mithilfe der in der Bibliothek libexacctenthaltenen API geöffnet oder erstellt werden (siehe libexacct(3LIB)). Diese Dateien können dann auf jeder Plattform mit aktiviertem Extended Accounting analysiert werden. Die darin enthaltenen Daten können zur Kapazitätsplanung und für das Chargeback verwendet werden.

Bei aktiviertem Extended Accounting werden Statistiken erfasst, die mit der libexacct-API ausgewertet werden können. libexacct ermöglicht sogar eine vorwärts- und rückwärts gerichtete Auswertung der exacct-Dateien. Die API unterstützt von libexacct erzeugte Drittanbieterdateien sowie vom Kernel erstellte Dateien. Weiterhin gibt es eine Perl-Schnittstelle zu libexacct, mit der Sie benutzerdefinierte Skripten zur Berichterstattung und Extraktion entwickeln können. Lesen Sie dazu Perl-Schnittstelle für libexacct.

Beispielsweise verfolgt die Aufgabe bei aktiviertem Extended Accounting die aggregierte Ressourcennutzung ihrer Mitgliederprozesse. Nach Beendigung der Aufgabe wird ein Aufgaben-Accounting-Datensatz gespeichert. Für laufende Prozesse und Aufgaben können auch Zwischendatensätze gespeichert werden. Weitere Informationen zu Aufgaben finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.

Abbildung 4–1 Aufgabenverfolgung bei aktiviertem Extended Accounting

Erweiterbares Format

Das Extended Accounting-Format ist wesentlich flexibler als das der SunOS-Accounting-Legatsoftware (siehe What is System Accounting? in System Administration Guide: Advanced Administration ). Mit dem Extended Accounting können Accounting-Metriken zwischen einzelnen Releases und sogar während des Systembetriebs zum System hinzugefügt bzw. davon gelöscht werden.

Das Extended Accounting und die Accounting-Legatsoftware können gleichzeitig auf einem System aktiviert sein.

exacct – Datensätze und Format

Programmroutinen zum Erstellen von exacct-Datensätzen erfüllen zwei Aufgaben.

• Das Erstellen von exacct-Drittanbieterdateien.

• Das Erstellen von Markierungsdatensätzen (Tags), die mithilfe des Systemaufrufs putacct in die vom Kernel erzeugte Accounting-Datei eingebettet werden (siehe getacct(2)).

  ---

  Hinweis –

  Der Systemaufruf putacct ist auch von der Perl-Schnittstelle verfügbar.

  ---

Das Format ermöglicht, dass verschiedene Arten von Accounting-Datensätzen erfasst werden können, ohne dass jede Änderung eine explizite Versionsänderung erfordert. Gut geschriebene Anwendungen zur Verarbeitung von Accounting-Daten ignorieren Datensätze, die sie nicht verstehen.

Die Bibliothek libexacct konvertiert und erstellt Dateien im exacct-Format. Diese Bibliothek ist die einzige unterstützte Schnittstelle für Dateien im exacct-Format.

Die Systemaufrufe getacct, putacct und wracct gelten nicht für Flows. Der Kernel erstellt Flow-Datensätze und schreibt sie in die Datei, wenn das IPQoS Flow-Accounting konfiguriert ist.

Verwenden des Extended Accounting auf einem Solaris-System mit installierten Zonen

Wenn das Extended Accounting in der globalen Zone ausgeführt wird, sammelt es Daten und erstellt Berichte für das gesamte System (einschließlich der nicht-globalen Zonen). Der globale Administrator kann darüber hinaus den Ressourcenverbrauch pro Zone festlegen. Weitere Informationen finden Sie unter Extended Accounting auf einem Solaris-System mit installierten Zonen.

Konfiguration des Extended Accounting

Die aktuelle Konfiguration des Extended Accounting ist in der Datei/etc/acctadm.conf gespeichert. Diese Datei wird über die Schnittstelle acctadm und nicht vom Benutzer bearbeitet.

Standardmäßig werden die Extended Accounting-Daten im Verzeichnis /var/adm/exacct gespeichert. Mit dem Befehl acctadm können Sie einen anderen Speicherort für die Accounting-Datendateien von Prozessen und Aufgaben zuweisen. Weitere Informationen finden Sie unter acctadm(1M).

Mit Extended Accounting verwendete Befehle

Weitere Informationen zu den Befehlen, die Aufgaben und Projekten zugeordnet sind, finden Sie unter Beispiele für Befehle und Befehlsoptionen. Informationen zum IPQoS Flow-Accounting finden Sie in der Manpage ipqosconf(1M).

Perl-Schnittstelle für libexacct

Mit der Perl-Schnittstelle können Sie Perl-Skripten erstellen, die vom exacct-Framework erstellte Accounting-Dateien lesen können. Auch lassen sich Perl-Skripten zum Schreiben von exacct-Dateien erstellen.

Die Schnittstelle entspricht in der Funktion der zu Grunde liegenden C API. Wenn möglich, werden die von der zu Grunde liegenden C API erfassten Daten als Perl-Datentypen dargestellt. Diese Funktion vereinfacht den Datenzugriff und macht das Packen und Entpacken des Puffers überflüssig. Darüber hinaus wird die gesamte Speicherverwaltung von der Perl-Bibliothek übernommen.

Die einzelnen Projekt-, Aufgabe- und exacct-bezogenen Funktionen werden in Gruppen aufgeteilt. Jede Funktionsgruppe befindet sich in einem separaten Perl-Modul. Jedes Modul beginnt mit dem standardmäßigen Sun-Präfix Sun::Solaris:: für Perl-Pakete. Alle von der Perl-Bibliothek exacct bereitgestellten Klassen befinden sich im Sun::Solaris::Exacct-Modul.

Die zu Grunde liegende libexacct(3LIB)-Bibliothek stellt die Vorgänge für Dateien im exacct-Format, Katalog-Tags und exacct-Objekte bereit. exacct-Objekte sind in zwei Typen unterteilt:

• Elemente, die Einzeldatenwerte darstellen (Skalare)

• Gruppen, die Elementlisten darstellen

In der folgenden Tabelle werden die einzelnen Module zusammenfassend beschrieben.

Beispiele, in denen die Verwendung der in der obigen Tabelle beschriebenen Module gezeigt wird, finden Sie unter Verwenden der Perl-Schnittstelle für libexacct.

Kapitel 5 Verwalten des Extended Accounting (Vorgehen)

In diesem Kapitel wird die Verwaltung des Extended Accounting beschrieben.

Eine Einführung in das Extended Accounting finden Sie in Kapitel 4Einführung in das Extended Accounting.

Verwalten des Extended Accounting (Übersicht der Schritte)

Verwenden des Extended Accounting

Benutzer können Extended Accounting verwalten (starten, beenden, Konfigurationsparameter ändern), wenn Sie über ein entsprechendes Rechteprofil für den zu verwaltenden Extended Accounting-Typ verfügen:

• Flow Management

• Process Management

• Task Management

So aktivieren Sie das Extended Accounting für Prozesse, Aufgaben und Flows

Mit dem Befehl acctadm aktivieren Sie das Extended Accounting für Aufgaben, Prozesse und Flows. Der optionale finale Parameter für acctadm gibt an, ob der Befehl an den Accounting-Komponenten eines Prozesses, einer Systemtask oder eines Flows ausgeführt werden soll.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Aktivieren Sie das Extended Accounting für Prozesse.

   # acctadm -e extended -f /var/adm/exacct/proc process

3. Aktivieren Sie das Extended Accounting für Aufgaben.

   # acctadm -e extended,mstate -f /var/adm/exacct/task task

4. Aktivieren Sie das Extended Accounting für Flows.

   # acctadm -e extended -f /var/adm/exacct/flow flow

Siehe auch

Weitere Informationen finden Sie unter acctadm(1M).

So aktivieren Sie das Extended Accounting mit einem Startskript

Aktivieren Sie das Extended Accounting für die ständige Ausführung, indem Sie das Skript /etc/init.d/acctadm mit /etc/rc2.d verknüpfen.

# ln -s /etc/init.d/acctadm /etc/rc2.d/Snacctadm
# ln -s /etc/init.d/acctadm /etc/rc2.d/Knacctadm

Die Variable n wird durch eine Zahl ersetzt.

Anschließend müssen Sie das Extended Accounting mindestens einmal manuell aktivieren, um die Konfiguration einzurichten.

Weitere Informationen zur Accounting-Konfiguration finden Sie unter Konfiguration des Extended Accounting.

So zeigen Sie den Extended Accounting-Status an

Zum Anzeigen des aktuellen Status des Extended Accounting geben Sie den Befehl acctadm ohne Argumente ein.

# acctadm
                 Task accounting: active
            Task accounting file: /var/adm/exacct/task
          Tracked task resources: extended
        Untracked task resources: none
              Process accounting: active
         Process accounting file: /var/adm/exacct/proc
       Tracked process resources: extended
     Untracked process resources: host
                 Flow accounting: active
            Flow accounting file: /var/adm/exacct/flow
          Tracked flow resources: extended
        Untracked flow resources: none

Im obigen Beispiel ist das Systemtask-Accounting im erweiterten Modus und im mstate-Modus aktiv. Prozess- und Flow-Accounting sind im erweiterten Modus aktiv.

In Bezug auf das Extended Accounting bezieht sich „microstate“ (mstate) auf die erweiterten Daten, die den Microstate-Prozessübergängen zugeordnet sind, die in der Prozessnutzungsdatei zur Verfügung stehen (siehe proc(4)). Diese Daten enthalten wesentlich mehr Details über die Aktivitäten des Prozesses als allgemeine oder erweiterte Datensätze.

So zeigen Sie die verfügbaren Accounting-Ressourcen an

Die verfügbaren Ressourcen variieren von System zu System und von Plattform zu Plattform. Mit dem Befehl acctadm und der Option -r können Sie die auf dem System verfügbaren Accounting-Ressourcengruppen anzeigen.

# acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag,
memory,mstatedisplays as one line
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid,zone
basic    taskid,projid,cpu,time
flow:
extended 
saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid
basic    saddr,daddr,sport,dport,proto,nbytes,npkts,action

So deaktivieren Sie das Prozess-, Aufgaben- und Flow-Accounting

Zum Deaktivieren des Prozess-, Aufgaben- und Flow-Accounting geben Sie jeweils den Befehl acctadm mit der Option-x ein.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Deaktivieren Sie das Prozess-Accounting.

   # acctadm -x process

3. Deaktivieren Sie das Aufgaben-Accounting.

   # acctadm -x task

4. Deaktivieren Sie das Flow-Accounting.

   # acctadm -x flow

5. Überprüfen Sie, ob Aufgaben-, Prozess-und Flow-Accounting deaktiviert wurden.

   # acctadm Task accounting: inactive Task accounting file: none Tracked task resources: extended Untracked task resources: none Process accounting: inactive Process accounting file: none Tracked process resources: extended Untracked process resources: host Flow accounting: inactive Flow accounting file: none Tracked flow resources: extended Untracked flow resources: none

Verwenden der Perl-Schnittstelle für libexacct

So drucken Sie rekursiv den Inhalt eines exacct-Objekts

Mit dem folgenden Code drucken Sie rekursiv den Inhalt eines exacct-Objekts. Diese Eigenschaft wird von der Bibliothek als Funktion Sun::Solaris::Exacct::Object::dump() bereitgestellt. Diese Eigenschaft ist auch über die Convenience-Funktion ea_dump_object() verfügbar.

sub dump_object
     {
             my ($obj, $indent) = @_;
             my $istr = '  ' x $indent;

             #
             # Retrieve the catalog tag.  Because we are 
             # doing this in an array context, the
             # catalog tag will be returned as a (type, catalog, id) 
             # triplet, where each member of the triplet will behave as 
             # an integer or a string, depending on context.
             # If instead this next line provided a scalar context, e.g.
             #    my $cat  = $obj->catalog()->value();
             # then $cat would be set to the integer value of the 
             # catalog tag.
             #
             my @cat = $obj->catalog()->value();

             #
             # If the object is a plain item
             #
             if ($obj->type() == &EO_ITEM) {
                     #
                     # Note: The '%s' formats provide s string context, so
                     # the components of the catalog tag will be displayed
                     # as the symbolic values. If we changed the '%s'
                     # formats to '%d', the numeric value of the components
                     # would be displayed.
                     #
                     printf("%sITEM\n%s  Catalog = %s|%s|%s\n", 
                        $istr, $istr, @cat);
                     $indent++;

                     #
                     # Retrieve the value of the item.  If the item contains
                     # in turn a nested exacct object (i.e., an item or
                     # group),then the value method will return a reference
                     # to the appropriate sort of perl object
                     # (Exacct::Object::Item or Exacct::Object::Group).
                     # We could of course figure out that the item contained
                     # a nested item orgroup by examining the catalog tag in
                     # @cat and looking for a type of EXT_EXACCT_OBJECT or
                     # EXT_GROUP.
                     #
                     my $val = $obj->value();
                     if (ref($val)) {
                             # If it is a nested object, recurse to dump it.
                             dump_object($val, $indent);
                     } else {
                             # Otherwise it is just a 'plain' value, so
                             # display it.
                             printf("%s  Value = %s\n", $istr, $val);
                     }

             #
             # Otherwise we know we are dealing with a group.  Groups
             # represent contents as a perl list or array (depending on
             # context), so we can process the contents of the group
             # with a 'foreach' loop, which provides a list context.
             # In a list context the value method returns the content
             # of the group as a perl list, which is the quickest
             # mechanism, but doesn't allow the group to be modified.
             # If we wanted to modify the contents of the group we could
             # do so like this:
             #    my $grp = $obj->value();   # Returns an array reference
             #    $grp->[0] = $newitem;
             # but accessing the group elements this way is much slower.
             #
             } else {
                     printf("%sGROUP\n%s  Catalog = %s|%s|%s\n",
                         $istr, $istr, @cat);
                     $indent++;
                     # 'foreach' provides a list context.
                     foreach my $val ($obj->value()) {
                             dump_object($val, $indent);
                     }
                     printf("%sENDGROUP\n", $istr);
             }
     }

So erstellen Sie einen neuen Gruppendatensatz und schreiben ihn in eine Datei

Mit dem folgenden Skript erstellen Sie einen neuen Gruppendatensatz und schreiben ihn in eine Datei namens /tmp/exacct.

#!/usr/bin/perl

use strict;
use warnings;
use Sun::Solaris::Exacct qw(:EXACCT_ALL);
# Prototype list of catalog tags and values.
     my @items = (
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_CREATOR      => "me"       ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_PID     => $$         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_UID     => $<         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_GID     => $(         ],
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_PROC_COMMAND => "/bin/rec" ],
     );

     # Create a new group catalog object.
     my $cat = ea_new_catalog(&EXT_GROUP | &EXC_DEFAULT | &EXD_NONE)

     # Create a new Group object and retrieve its data array.
     my $group = ea_new_group($cat);
     my $ary = $group->value();

     # Push the new Items onto the Group array.
     foreach my $v (@items) {
             push(@$ary, ea_new_item(ea_new_catalog($v->[0]), $v->[1]));
     }

     # Open the exacct file, write the record & close.
     my $f = ea_new_file('/tmp/exacct', &O_RDWR | &O_CREAT | &O_TRUNC)
        || die("create /tmp/exacct failed: ", ea_error_str(), "\n");
     $f->write($group);
     $f = undef;

So drucken Sie den Inhalt einer exacct-Datei

Mit dem folgenden Perl-Skript drucken Sie den Inhalt einer exacct-Datei.

#!/usr/bin/perl

     use strict;
     use warnings;
     use Sun::Solaris::Exacct qw(:EXACCT_ALL);

     die("Usage is dumpexacct <exacct file>\n") unless (@ARGV == 1);

     # Open the exact file and display the header information.
     my $ef = ea_new_file($ARGV[0], &O_RDONLY) || die(error_str());
     printf("Creator:  %s\n", $ef->creator());
     printf("Hostname: %s\n\n", $ef->hostname());

     # Dump the file contents
     while (my $obj = $ef->get()) {
             ea_dump_object($obj);
     }

     # Report any errors
     if (ea_error() != EXR_OK && ea_error() != EXR_EOF)  {
             printf("\nERROR: %s\n", ea_error_str());
             exit(1);
     }
     exit(0);

Beispiel einer Ausgabe von Sun::Solaris::Exacct::Object->dump()

Das Folgende ist ein Beispiel für eine Ausgabe, die durch das Ausführen von Sun::Solaris::Exacct::Object->dump() an der Datei erzeugt wird, die unter So erstellen Sie einen neuen Gruppendatensatz und schreiben ihn in eine Datei erstellt wurde.

Creator:  root
Hostname: localhost
GROUP
       Catalog = EXT_GROUP|EXC_DEFAULT|EXD_NONE
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_CREATOR
         Value = me
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_PID
         Value = 845523
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_UID
         Value = 37845
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_GID
         Value = 10
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_PROC_COMMAND
         Value = /bin/rec
ENDGROUP

Kapitel 6 Einführung in die Resource Controls

Nachdem Sie den Ressourcenverbrauch durch Arbeitslasten auf dem System gemäß der Beschreibung in Kapitel 4Einführung in das Extended Accounting ermittelt haben, können Sie Grenzwerte für die Ressourcennutzung einrichten. Grenzwerte verhindern, dass Arbeitslasten Ressourcen übermäßig verbrauchen. Zum Einrichten der Grenzwerte werden Resource Controls verwendet, die als Einschränkung eingesetzt werden.

In diesem Kapitel werden die folgenden Themen behandelt.

• Das Konzept von Resource Controls

• Konfigurieren von Resource Controls und Attributen

• Anwenden von Resource Controls

• Vorübergehendes Aktualisieren der Resource Control-Werte bei laufendem System

• Mit Resource Controls verwendete Befehle

Informationen zur Verwaltung von Resource Controls finden Sie in Kapitel 7Verwalten von Resource Controls (Vorgehen).

Neuerungen bei den Resource Controls in Solaris 10

Die folgende Liste der Resource Controls ersetzt die System V Interprocess Communication (IPC)-Tunables /etc/system:

• project.max-shm-ids

• project.max-msg-ids

• project.max-sem-ids

• project.max-shm-memory

• process.max-sem-nsems

• process.max-sem-ops

• process.max-msg-qbytes

Die folgenden Resource Controls für Ereignis-Ports wurden hinzugefügt:

• project.max-device-locked-memory

• project.max-port-ids

• process.max-port-events

Die folgende kryptografische Resource Control wurde hinzugefügt:

• project.max-crypto-memory

Die folgenden zusätzlichen Resource Controls wurden hinzugefügt:

• project.max-lwps

• project.max-tasks

• project.max-contracts

Weitere Informationen finden Sie unter Verfügbare Resource Controls.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Das Konzept von Resource Controls

Im Betriebssystem Solaris wurde das Konzept einer prozessbasierten Ressourceneinschränkung auf die in Kapitel 2Einführung in Projekte und Aufgaben beschriebenen Funktionen Aufgabe und Projekt erweitert. Diese Erweiterungen werden über Resource Controls (rctls) umgesetzt. Darüber hinaus sind Zuweisungen, die über die Tunables /etc/system eingestellt wurden, jetzt automatisiert oder können ebenfalls über Resource Controls konfiguriert werden.

Eine Resource Control ist durch das Präfix zone, project, task oder process gekennzeichnet. Resource Controls können systemweit überwacht werden. Die Werte von Resource Controls können bei laufendem System aktualisiert werden.

Eine Liste der standardmäßigen Resource Controls für dieses Release finden Sie unter Verfügbare Resource Controls. Informationen zu den verfügbaren zonenweiten Resource Controls finden Sie unter Ressourcentypeigenschaften.

Eine Liste der standardmäßigen Resource Controls für dieses Release finden Sie unter Verfügbare Resource Controls.

Maximaler Ressourcenverbrauch und Resource Controls

UNIX-Systeme verfügen traditionell über eine Funktion zur Begrenzung des maximalen Ressourcenverbrauchs (rlimit). Mit „rlimit“ können Administrator einen oder mehrere numerische Grenzwerte für die Ressourcen einrichten, die ein Prozess maximal verbrauchen darf. Diese Grenzwerte enthalten die verwendete CPU-Zeit pro Prozess, die Kerndateigröße pro Prozess und die maximale Heap-Größe pro Prozess. Heap-Größe ist der für das Prozessdatensegment zugewiesene Scratch-Speicher.

Resource Controls bilden u. a. Kompatibilitätsschnittstellen für den maximalen Ressourcenverbrauch. Vorhandene Anwendungen, für die ein maximaler Ressourcenverbrauch festgelegt wurde, laufen unverändert weiter. Diese Anwendungen können auf die gleiche Weise überwacht werden wie Anwendungen, die geändert wurden, um von den Vorteilen der Resource Controls profitieren zu können.

Prozessübergreifende Kommunikation und Resource Controls

Prozesse können über verschiedene Arten von prozessübergreifender Kommunikation (Interprocess Communication, IPC) miteinander kommunizieren. IPC ermöglicht die Übertragung oder Synchronisierung von Informationen zwischen Prozessen. Vor dem Solaris-Release 10 wurden die einstellbaren IPC-Parameter durch Hinzufügen eines Eintrags zur Datei /etc/system gesetzt. Die Resource Controls umfassen jetzt Funktionen, die das Verhalten der IPC-Funktionen des Kernel definieren. Diese Resource Controls ersetzen die /etc/system-Tunables.

Auf diesem Solaris-System können in der Datei /etc/system veraltete Parameter enthalten sein. In diesem Fall dienen die Parameter zur Initialisierung der Standardwerte für Ressourcenobjekte gemäß den vorigen Solaris-Versionen. Von der Verwendung der veralteten Parameter wird jedoch abgeraten

Um festzustellen, welche IPC-Objekte zur Nutzung durch ein Projekt beitragen, verwenden Sie den Befehl ipcs mit der Option -J. Eine Beispielanzeige finden Sie unter So verwenden Sie ipcs Weitere Informationen zum Befehl ipcs finden Sie unter ipcs(1).

Informationen zur Einstellung eines Solaris-Systems finden Sie im Oracle Solaris Tunable Parameters Reference Manual .

Einschränkungsmechanismen der Resource Controls

Resource Controls bieten einen Mechanismus zur Einschränkung der Systemressourcen. Mit diesem Mechanismus kann verhindert werden, dass Prozesse, Aufgaben, Projekte und Zonen bestimmte angegebene Systemressourcen verbrauchen. Das System lässt sich besser verwalten, da übermäßiger Ressourcenverbrauch verhindert wird.

Die Einschränkungsmechanismen können auch in Prozessen zur Kapazitätsplanung verwendet werden. Wenn eine Anwendung auf eine Einschränkung trifft, kann diese auch Informationen zu den Ressourcenanforderungen der Anwendung liefern, ohne dass diese Ressourcen unbedingt verweigert werden.

Projektattribute

Resource Controls können auch als einfache Attribute für die Ressourcenverwaltung verwendet werden. Beispielsweise wird die Anzahl der CPU-Shares, die einem Projekt in der Scheduling-Klasse Fair Share Scheduler (FSS) zur Verfügung stehen, von der Resource Control project.cpu-shares definiert. Da dem Projekt von der Resource Control eine feste Anzahl an Shares zugewiesen wird, werden die Aktionen, die dem Überschreiten der Resource Control zugeordnet sind, nicht angewendet. In diesem Zusammenhang wird der aktuelle Wert für die Resource Control project.cpu-shares als Attribut für das angegebene Projekt betrachtet.

Ein anderer Projektattributtyp dient zum Begrenzen des Speicherressourcenverbrauchs durch Prozesse, die an ein Projekt angehängt sind. Dieser Attribute haben das Präfix rcap, z. B. rcap.max-rss. Dieser Attributtyp wird wie eine Resource Control in der project-Datenbank konfiguriert. Während Resource Controls synchron vom Kernel durchgesetzt werden, werden Resource Caps (Speicherbegrenzungen) asynchron auf Benutzerebene über den Resource Capping Daemon rcapd durchgesetzt. Weitere Informationen zum rcapd finden Sie in Kapitel 10Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons und in der Manpage rcapd(1M).

Mit dem Attribut project.pool wird eine Pool-Bindung eines Projekt angegeben. Weitere Informationen zu Resource Pools finden Sie in Kapitel 12Einführung in Resource Pools.

Konfigurieren von Resource Controls und Attributen

Resource Controls werden über die project-Datenbank konfiguriert. Lesen Sie dazu Kapitel 2Einführung in Projekte und Aufgaben. Resource Controls und andere Attribute werden im letzten Feld eines project-Datenbankeintrags gesetzt. Die den einzelnen Resource Controls zugewiesenen Werte werden in Klammern eingeschlossen und erscheinen als durch Kommata getrennter Klartext. Die Werte in Klammern bilden eine „Aktionsklausel“. Jede Aktionsklausel setzt sich aus einem Schwellenwert, einer Berechtigungsstufe und einer Aktion zusammen, die einem bestimmten Schwellenwert zugeordnet ist. Jede Resource Control kann mehrere Aktionsklauseln enthalten, die ebenfalls durch Kommata voneinander getrennt sind. Der folgende Eintrag definiert taskbasiert eine Lightweight-Prozessgrenze und prozessbasiert einen Grenzwert für die maximale CPU-Zeit für ein Projekt. Wenn ein Prozess eine Stunde lang andauert, sendet die Resource Control process.max-cpu-time dem Prozess ein SIGTERM. Dauert der Prozess 1 Stunde und 1 Minute an, wird ein SIGKILL an den Prozess gesendet (siehe Tabelle 6–3).

development:101:Developers:::task.max-lwps=(privileged,10,deny);
  process.max-cpu-time=(basic,3600,signal=TERM),(priv,3660,signal=KILL)
typed as one line

Auf Systemen mit aktivierten Zonen werden zonenweite Resource Controls in einem etwas anderen Format in der Zonenkonfiguration angegeben. Weitere Informationen finden Sie unter Konfigurationsdaten in einer Zone.

Mit dem Befehl rctladm können Sie Echtzeitabfragen an Resource Controls mit globalem Geltungsbereich richten und Modifikationen daran vornehmen. Mit dem Befehl prctl können Sie Echtzeitabfragen an Resource Controls mit lokalem Geltungsbereich richten und Modifikationen daran vornehmen.

Weitere Informationen finden Sie unter Globale und lokale Aktionen mit Resource Control-Werten, rctladm(1M) und prctl(1).

Auf einem System mit installierten Zonen können Sie rctladm in einer nicht-globalen Zone nicht zum Ändern von Einstellungen verwenden. Mit rctladm können Sie in einer nicht-globalen Zone den globalen Logging-Status jeder Resource Control anzeigen.

Verfügbare Resource Controls

In der folgenden Tabelle ist eine Liste der standardmäßige Resource Controls für dieses Release aufgeführt.

Dabei wird die Ressource beschrieben, die von einer Resource Control eingeschränkt wird. Darüber hinaus sind die Standardeinheiten in der Tabelle aufgeführt, die von der project-Datenbank für diese Ressourcen verwendet werden. Es gibt zwei Arten von Standardeinheiten:

• Mengen stellen eine begrenzte Anzahl dar.

• Indizes stellen einen maximal gültigen Bezeichner dar.

Somit gibt project.cpu-shares die Anzahl der Shares an, auf die das Projekt Anrecht hat. process.max-file-descriptor gibt die maximale Anzahl an Dateien an, die einem Prozess vom Systemaufruf open(2) zugewiesen werden können.

Sie können die Standardwerte für Resource Controls auf einem System anzeigen, für das keine Resource Controls eingestellt oder geändert wurden. Ein solches System enthält ausschließlich Standardeinträge in der Datei /etc/system oder in der project-Datenbank. Zum Anzeigen der Werte verwenden Sie den Befehl prctl.

Zonenweite Resource Controls

Zonenweite Resource Controls schränken die gesamte Ressourcennutzung aller Prozesseinheiten innerhalb einer Zone ein. Zonenweite Resource Controls können auch mithilfe der globalen Eigenschaftennamen eingestellt werden. Dies wird unter Einrichten von zonenweiten Resource Controls und unter So konfigurieren Sie die Zone beschrieben.

Informationen zum Konfigurieren der zonenweiten Resource Controls finden Sie unter Ressourcentypeigenschaften und So konfigurieren Sie die Zone. Wie die zonenweiten Resource Controls in lx Branded Zones verwendet werden, können Sie unter So konfigurieren, prüfen und übernehmen Sie eine lx Branded Zone nachlesen.

Eine zonenweite Resource Control kann auch auf die globale Zone angewendet werden. Weitere Informationen finden Sie in Kapitel 17Einführung in die Konfiguration einer nicht-globalen Zone und unter Verwenden des Fair Share Scheduler auf einem Solaris-System mit installierten Zonen.

Unterstützung von Einheiten

Für alle Resource Controls sind globale Flags definiert, die den Typ aller Resource Controls kennzeichnen. Mit diesen Flags teilt das System Anwendungen, wie z. B. dem Befehl prctl, allgemeine Typinformationen mit. Anhand dieser Information können Anwendungen Folgendes feststellen:

• Die für eine Resource Control geltende Einheit

• Der korrekte Maßstab, wenn skalierte Werte zu interpretierten sind

Die folgenden globalen Flags sind verfügbar:

Skalierte Werte können mit Resource Controls verwendet werden. Das folgende Beispiel zeigt einen skalierten Schwellenwert:

task.max-lwps=(priv,1K,deny)

Einheitenmodifikatoren werden von den Befehlen prctl, projadd und projmod akzeptiert. Sie können Einheitenmodifikatoren nicht in der project-Datenbank verwenden.

Resource Control-Werte und Berechtigungsstufen

Der Schwellenwert für eine Resource Control ist der Punkt, an dem die Durchsetzung lokaler Aktionen ausgelöst wird oder globale Aktionen, z. B. eine Protokollierung, auftreten können.

Jeder Schwellenwert für eine Resource Control muss einer Berechtigungsstufe zugewiesen sein. Diese Berechtigungsstufe muss einen der folgenden drei Typen aufweisen.

• „basic“, dieser Typ kann vom Eigentümer des aufrufenden Prozesses bearbeitet werden

• „privileged“, dieser Typ kann nur von berechtigten Aufrufern (Superuser) bearbeitet werden

• „system“, dieser Typ ist für die Dauer der Betriebssysteminstanz feststehend

Eine Resource Control besitzt garantiert einen Systemwert, der entweder vom System oder dem Ressourcen-Provider definiert wird. Der Systemwert legt fest, wie viel der Ressource von der aktuellen Implementation des Betriebssystems bereitgestellt werden kann.

Es können beliebige viele „privileged“ Werte definiert werden, aber es ist nur ein „basic“ Wert zulässig. Vorgänge, die ohne Angabe eines „privileged“ Werts ausgeführt werden, wird standardmäßig ein „basic“ Wert zugeordnet.

Die Berechtigungsstufe eines Resource Control-Werts wird im Berechtigungsfeld des Resource Control-Block als RCTL_BASIC, RCTL_PRIVILEGED oder RCTL_SYSTEM definiert. Weitere Informationen finden Sie unter setrctl(2) Werte, denen die Berechtigungsstufen „basic“ und „privileged“ zugewiesen sind, können Sie mit dem Befehl prctl ändern.

Globale und lokale Aktionen mit Resource Control-Werten

Es gibt zwei Kategorien von Aktionen für Resource Control-Werte: global und lokal.

Globale Aktionen mit Resource Control-Werten

Globale Aktionen gelten für Resource Control-Werte jeder Resource Control in einem System. Mit dem Befehl rctladm, der in der Manpage rctladm(1M) ausführlich beschrieben ist, können Sie:

• Den globalen Status von aktiven System-Resource Controls anzeigen

• Globale Protokollierungsaktionen einrichten

Die globale Protokollierungsaktion für Resource Controls kann aktiviert oder deaktiviert werden. Weisen Sie der Aktion syslog einen bestimmten Wert zu, um einen Schweregrad zuzuweisen, syslog=Schweregrad. Mögliche Einstellungen für Schweregrad sind:

• debug

• info

• notice

• warning

• err

• crit

• alert

• emerg

Standardmäßig werden Verletzungen der Resource Controls nicht global protokolliert. Im Solaris-Release 10 5/08 wurde für Resource Controls, für die keine globalen Aktionen konfiguriert werden können, die Ebene n/a hinzugefügt.

Lokale Aktionen mit Resource Control-Werten

Lokale Aktionen werden für einen Prozess durchgeführt, der versucht, den Resource Control-Wert zu übersteigen. Jedem Schwellenwert, der für eine Resource Control eingerichtet wurde, können eine oder mehrere Aktionen zugewiesen werden. Es gibt drei Arten von lokalen Aktionen: none, deny und signal=. Diese drei Aktionen werden wie folgt verwendet:

none

Bei Ressourcenanforderungen, die größer sind als der Schwellenwert, wird keine Aktion durchgeführt. Mit dieser Aktion kann die Ressourcennutzung überwacht werden, ohne die Ausführung von Anwendungen zu beeinflussen. Sie können auch eine globale Nachricht aktivieren, die immer dann angezeigt wird, wenn die Resource Control überschritten wird. Der den Schwellenwert überschreitende Prozess wird davon nicht beeinflusst.

deny

Ressourcenanforderungen, die größer sind als der Schwellenwert, werden verweigert. Beispielsweise führt eine Resource Control task.max-lwps mit der Aktion deny dazu, dass ein fork-Systemaufruf fehlschlägt, wenn der neue Prozess den Wert der Resource Control überschreitet. Weitere Informationen finden Sie in der Manpage fork(2).

signal=

Sie können die Aktion einer globalen Signalnachricht aktivieren, wenn der Schwellenwert der Resource Control überschritten wird. Beim Überschreiten des Schwellenwerts wird ein Signal an den Prozess gesendet. Wenn der Prozess zusätzliche Ressourcen verbraucht, werden keine zusätzlichen Signale gesendet. Die verfügbaren Signale sind in Tabelle 6–3 aufgeführt.

Nicht alle Aktionen können an jeder Resource Control angewendet werden. Beispielsweise kann ein Prozess nicht die Anzahl der CPU-Shares überschreiten, die dem Projekt zugewiesen sind, bei dem der Prozess Mitglied ist. Aus diesem Grund ist die Aktion „deny“ für die Resource Control project.cpu-shares nicht zulässig.

Aufgrund der Implementierungseinschränkungen können die globalen Eigenschaften einer Resource Control den Bereich an verfügbaren Aktionen einschränken, die für diesen Schwellenwert eingerichtet werden können. (Weitere Informationen finden Sie in der Manpage rctladm(1M) Eine Liste der verfügbaren Signalaktionen finden Sie in der folgenden Tabelle. Weitere Informationen zu Signalen können Sie in der Manpage signal(3HEAD) nachlesen.

Flags und Eigenschaften von Resource Controls

Jede Resource Control auf einem System verfügt über ein bestimmtes Set zugewiesener Eigenschaften. Dieses Eigenschaftenset ist als eine Reihe von Flags definiert, die allen gesteuerten Instanzen dieser Ressource zugeordnet sind. Globale Flags können nicht bearbeitet werden, aber die Flags können mit rctladm oder dem Systemaufruf getrctl abgerufen werden.

Lokale Flags definieren das Standardverhalten und die Konfiguration eines bestimmten Schwellenwerts der Resource Control für einen bestimmten Prozess oder eine Prozessansammlung. Die lokalen Flags für einen Schwellenwert wirken sich nicht auf das Verhalten anderer definierter Schwellenwerte für die gleiche Resource Control aus. Demgegenüber wirken sich globale Flags auf das Verhalten jedes Werts aus, der einer bestimmten Resource Control zugeordnet ist. Lokale Flags können innerhalb der Einschränkungen durch die entsprechenden globalen Flags mit dem Befehl prctl oder dem Systemaufruf setrctl bearbeitet werden. Lesen Sie dazu setrctl(2).

Eine vollständige Liste der lokalen Flags, globalen Flags und deren Definitionen finden Sie unter rctlblk_set_value(3C).

Um das Systemverhalten beim Erreichen des Schwellenwerts einer bestimmten Resource Control festzulegen, zeigen Sie die globalen Flags der Resource Control an. Dazu verwenden Sie den Befehl rctladm. Um beispielsweise die Werte für die Resource Control process.max-cpu-time anzuzeigen, geben Sie Folgendes ein:

$ rctladm process.max-cpu-time
	process.max-cpu-time  syslog=off  [ lowerable no-deny cpu-time inf seconds ]

Die globalen Flags geben Folgendes an:

lowerable

Superuser-Berechtigungen sind nicht erforderlich, um privilegierte Werte für diese Resource Control zu senken.

no-deny

Auch wenn die Schwellenwerte überschritten werden, wird der Zugriff auf diese Resource Control niemals verweigert.

cpu-time

SIGXCPU kann gesendet werden, wenn Schwellenwerte für diese Resource Control erreicht wurden.

seconds

Der Zeit-Wert für die Resource Control.

no-basic

Resource Control-Werte mit dem Zugriffsprivileg basic können nicht eingestellt werden. Es sind nur Resource Control-Werte mit den entsprechenden Zugriffsprivilegien zulässig.

no-signal

Eine lokale Signalaktion kann nicht an Resource Control-Werten gesetzt werden.

no-syslog

Die globale syslog-Meldungsaktion kann für diese Resource Control nicht gesetzt werden.

deny

Die Ressourcenanforderung immer verweigern, wenn die Grenzwerte überschritten werden.

Zählung

Ein ganzzahliger Zählwert für die Resource Control.

bytes

Größeneinheit für die Resource Control.

Geben Sie den Befehl prctl ein, um die lokalen Werte und Aktionen für die Resource Control anzuzeigen.

$ prctl -n process.max-cpu-time $$
	process 353939: -ksh
	NAME    PRIVILEGE    VALUE    FLAG   ACTION              RECIPIENT
 process.max-cpu-time
         privileged   18.4Es    inf   signal=XCPU                 -
         system       18.4Es    inf   none 

Das Flag max (RCTL_LOCAL_MAXIMAL) ist für beide Schwellenwerte gesetzt, und das Flag inf (RCTL_GLOBAL_INFINITE) ist für diese Resource Control definiert. Ein inf-Wert hat eine unendliche Menge. Der Wert wird nie durchgesetzt. Daher stellen die konfigurierten Schwellenwerte unendliche Werte dar, die nie überschritten werden.

Durchsetzung von Resource Controls

Für eine Ressource können mehrere Resource Controls vorhanden sein. Eine Resource Control kann auf jeder Inhaltsstufe im Prozessmodell existieren. Wenn Resource Controls für die gleichen Ressourcen auf unterschiedlichen Inhaltsstufen aktiv sind, wird die Resource Control auf der niedrigsten Inhaltsstufe zuerst durchgesetzt. Aus diesem Grund wird die Aktion für process.max-cpu-time vor der Aktion für task.max-cpu-time ausgeführt, wenn beide Resource Controls gleichzeitig durchgesetzt werden.

Abbildung 6–1 Prozess-Collectives, Container-Beziehungen und zugehörige Resource Control-Sets

Globale Überwachung auf Resource Control-Ereignisse

Häufig ist der Ressourcenverbrauch von Prozessen unbekannt. Um mehr Informationen zu erhalten, können Sie die globalen Resource Control-Aktionen verwenden, die über den Befehl rctladm verfügbar sind. Geben Sie den Befehl rctladm ein, um eine syslog-Aktion für eine Resource Control einzurichten. Wenn dann eine von dieser Resource Control verwaltete Einheit auf einen Schwellenwert trifft, wird eine Systemmeldung auf der konfigurierten Protokollstufe aufgezeichnet. Weitere Informationen finden Sie in Kapitel 7Verwalten von Resource Controls (Vorgehen) und in der Manpage rctladm(1M).

Anwenden von Resource Controls

Jede in Tabelle 6–1 aufgeführte Resource Control kann einem Projekt entweder bei der Anmeldung zugewiesen werden, oder wenn newtask, su oder andere projektbezogene Startprogramme wie at, batch oder cron aufgerufen werden. Jeder initiierte Befehl wird in einer separaten Aufgabe mit dem Standardprojekt des aufrufenden Benutzers gestattet. Weitere Informationen finden Sie in den Manpages login(1), newtask(1), at(1), cron(1M) und su(1M).

Aktualisierungen der Einträge in der project-Datenbank, ob an der Datei /etc/project oder an einer Darstellung der Datenbank in einem Netzwerk-Namen-Service werden nicht an den derzeit aktiven Projekten angewendet. Die Aktualisierungen werden angewendet, wenn eine neue Aufgabe über eine Anmeldung oder newtask zum Projekt hinzugefügt wird.

Vorübergehendes Aktualisieren der Resource Control-Werte bei laufendem System

In der project-Datenbank geänderte Werte gelten nur für neue Aufgaben, die in einem Projekt gestartet werden. Sie können jedoch in die Befehle rctladm und prctl verwenden, um die Resource Controls bei laufendem System zu aktualisieren.

Aktualisieren des Protokollierungsstatus

Der Befehl rctladm wirkt sich systemweit auf den globalen Protokollierungsstatus jeder Resource Control aus. Mit diesem Befehl können Sie den globalen Status anzeigen und die Stufe der syslog-Protokollierung einstellen, wenn Resource Controls überschritten werden.

Aktualisieren von Resource Controls

Mit dem Befehl prctl können Sie die Werte und Aktionen von Resource Controls auf Prozess-, Aufgaben- oder Projektbasis anzeigen oder vorübergehend ändern. Als Eingabe wird eine Projekt-, Aufgaben- oder Prozess-ID verwendet. Der Befehl arbeitet auf der Stufe mit der Resource Control, auf der sie definiert ist.

Alle Änderungen an Werten und Aktionen werden unmittelbar übernommen. Diese Änderungen gelten jedoch nur für den aktuellen Prozess, die aktuelle Aufgabe oder das aktuelle Projekt. Die Änderungen werden nicht in der project-Datenbank aufgezeichnet. Wird das System neu gestartet, gehen die Änderungen verloren. Permanente Änderungen an Resource Controls müssen in der project-Datenbank vorgenommen werden.

Alle Einstellungen für Resource Controls, die in der project-Datenbank geändert werden können, können auch mit dem Befehl prctl geändert werden. Es können sowohl allgemeine als auch privilegierte Werte hinzugefügt oder gelöscht werden. Auch deren Aktionen können geändert werden. Standardmäßig wird der Typ „basic“ für alle Vorgänge angewendet, Prozesse und Benutzer mit Superuser-Berechtigungen können jedoch auch „privileged“ Resource Controls ändern. System-Resource Controls können nicht geändert werden.

Mit Resource Controls verwendete Befehle

In der folgenden Tabelle sind die Befehle aufgeführt, die mit Resource Controls verwendet werden können.

In der Manpage resource_controls(5) finden Sie Beschreibungen der Resource Controls, die über die Projektdatenbank zur Verfügung stehen, einschließlich Einheiten und Skalierungsfaktoren.

Kapitel 7 Verwalten von Resource Controls (Vorgehen)

In diesem Kapitel wird die Verwaltung von Resource Controls beschrieben.

Eine Einführung in die Resource Controls finden Sie in Kapitel 6Einführung in die Resource Controls.

Verwalten von Resource Controls (Übersicht der Schritte)

Einrichten von Resource Controls

So richten Sie die maximale Anzahl der LWPs für jede Aufgabe in einem Projekt ein

Dieses Verfahren fügt ein Projekt namens x-files zur Datei /etc/project hinzu und legt die maximale Anzahl der LWPs für eine Aufgabe fest, die in dem Projekt erstellt wird.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Geben Sie den Befehl projadd mit der Option -K ein, um ein Projekt mit der Bezeichnung x-files zu erstellen. Legen Sie die maximale Anzahl der LWPs für eine Aufgabe, die in dem Projekt erstellt wird, mit 3 fest.

   # projadd -K 'task.max-lwps=(privileged,3,deny)' x-files

3. Zeigen Sie den Eintrag in der Datei /etc/project mithilfe einer der folgenden Methoden an:

   • Geben Sie Folgendes ein:

     # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: task.max-lwps=(privileged,3,deny)

   • Geben Sie Folgendes ein:

     # cat /etc/project system:0:System::: . . . x-files:100::::task.max-lwps=(privileged,3,deny)

Beispiel 7–1 Beispielsitzung

Nach dem Implementieren der Schritte dieses Verfahrens kann der Superuser, wenn er durch Verbinden des Projekts mit newtask eine neue Aufgabe im Projekt x-files erstellt, nicht mehr als drei LWPs erstellen, solange diese Aufgabe ausgeführt wird. Dies wird in der folgenden, mit Anmerkungen versehenen Beispielsitzung gezeigt.

# newtask -p x-files csh

# prctl -n task.max-lwps $$
process: 111107: csh
NAME    PRIVILEGE    VALUE    FLAG   ACTION            RECIPIENT
task.max-lwps
        privileged       3       -   deny                      -
        system       2.15G     max   deny                      -
# id -p
uid=0(root) gid=1(other) projid=100(x-files)

# ps -o project,taskid -p $$
 PROJECT TASKID
 x-files    73

# csh        /* creates second LWP */

# csh        /* creates third LWP */

# csh        /* cannot create more LWPs */
Vfork failed
#

So werden mehrere Resource Controls in einem Projekt eingerichtet

Die Datei /etc/project kann Einstellungen für mehrere Resource Controls für jedes Projekt sowie mehrere Schwellenwerte für jede Resource Control enthalten. Schwellenwerte sind in den Aktionsklauseln definiert, die bei mehreren Werten durch Kommata voneinander getrennt sind.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Geben Sie den Befehl projmod mit den Optionen -s und -K ein, um die Resource Controls für das Projekt x-files einzustellen:

   # projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' x-filesone line in file

   Die folgenden Resource Controls werden eingerichtet:

   • Eine basic-Resource Control ohne Aktion mit Bezug auf die maximale Anzahl der LWPs pro Aufgabe.

   • Eine privilegierte deny-Resource Control mit Bezug auf die maximale Anzahl der LWPs pro Aufgabe. Diese Resource Control sorgt dafür, dass das Erstellen von LWPs über den Höchstwert hinaus fehlschlägt (wie vorherigen Beispiel So richten Sie die maximale Anzahl der LWPs für jede Aufgabe in einem Projekt ein gezeigt).

   • Ein Grenzwert für die maximale Anzahl der Dateideskriptoren pro Prozess auf der Stufe basic. Dieser Grenzwert lässt alle offenen Aufrufe fehlschlagen, die den Höchstwert übersteigen.

3. Zeigen Sie den Eintrag in der Datei mithilfe einer der folgenden Methoden an:

   • Geben Sie Folgendes ein:

     # projects -l . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: process.max-file-descriptor=(basic,128,deny) task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

   • Geben Sie Folgendes ein:

     # cat etc/project . . . x-files:100::::process.max-file-descriptor=(basic,128,deny); task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

Verwenden des Befehls prctl

Mit dem Befehl prctl erstellen Sie Echtzeitabfragen oder Änderungen von Resource Controls, die einem aktiven Prozess, einer Aufgabe oder einem Projekt im System zugeteilt sind. Weitere Informationen finden Sie in der Manpage prctl(1).

So verwenden Sie den Befehl prctl zum Anzeigen von Resource Control-Standardwerten

Dieses Verfahren muss auf einem System verwendet werden, bei dem keine Resource Controls eingestellt oder geändert wurden. Es können nur nicht standardmäßige Einträge in der Datei /etc/system oder in der project-Datenbank vorliegen.

1. Verwenden Sie den Befehl prctl an einem beliebigen Prozess, z. B. der aktuell ausgeführten Shell.

   # prctl $$ process: 100337: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-port-events privileged 65.5K - deny - system 2.15G max deny - process.crypto-buffer-limit system 16.0EB max deny - process.max-crypto-sessions system 18.4E max deny - process.add-crypto-sessions privileged 100 - deny - system 18.4E max deny - process.min-crypto-sessions privileged 20 - deny - system 18.4E max deny - process.max-msg-messages privileged 8.19K - deny - system 4.29G max deny - process.max-msg-qbytes privileged 64.0KB - deny - system 16.0EB max deny - process.max-sem-ops privileged 512 - deny - system 2.15G max deny - process.max-sem-nsems privileged 512 - deny - system 32.8K max deny - process.max-address-space privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-descriptor basic 256 - deny 100337 privileged 65.5K - deny - system 2.15G max deny - process.max-core-size privileged 8.00EB max deny - system 8.00EB max deny - process.max-stack-size basic 8.00MB - deny 100337 privileged 8.00EB - deny - system 8.00EB max deny - process.max-data-size privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-size privileged 8.00EB max deny,signal=XFSZ - system 8.00EB max deny - process.max-cpu-time privileged 18.4Es inf signal=XCPU - system 18.4Es inf none - task.max-cpu-time system 18.4Es inf none - task.max-lwps system 2.15G max deny - project.max-contracts privileged 10.0K - deny - system 2.15G max deny - project.max-device-locked-memory privileged 499MB - deny - system 16.0EB max deny - project.max-port-ids privileged 8.19K - deny - system 65.5K max deny - project.max-shm-memory privileged 1.95GB - deny - system 16.0EB max deny - project.max-shm-ids privileged 128 - deny - system 16.8M max deny - project.max-msg-ids privileged 128 - deny - system 16.8M max deny - project.max-sem-ids privileged 128 - deny - system 16.8M max deny - project.max-tasks system 2.15G max deny - project.max-lwps system 2.15G max deny - project.cpu-shares privileged 1 - none - system 65.5K max none - zone.max-lwps system 2.15G max deny - zone.cpu-shares privileged 1 - none - system 65.5K max none -

So verwenden Sie den Befehl prctl zum Anzeigen von Informationen zu einer bestimmten Resource Control

1. Zeigen Sie den maximalen Dateideskriptor für die aktuell ausgeführte Shell an.

   # prctl -n process.max-file-descriptor $$ process: 110453: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-file-descriptor basic 256 - deny 110453 privileged 65.5K - deny - system 2.15G max deny

So verwenden Sie den Befehl prctl zum temporären Ändern eines Wertes

In diesem Beispielverfahren wird mit dem Befehl prctl ein neuer privilegierter Wert hinzugefügt, um zu verhindern, dass mehr als drei LWPs pro Projekt für das x-files-Projekt verwendet werden. Das Ergebnis ist mit dem Resultat unter So richten Sie die maximale Anzahl der LWPs für jede Aufgabe in einem Projekt ein vergleichbar.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Geben Sie newtask ein, um dem Projekt x-files eine neue Aufgabe hinzuzufügen.

   # newtask -p x-files

3. Geben Sie den Befehl id mit der Option -p ein, um zu überprüfen, ob der Beitritt zum richtigen Projekt erfolgte.

   # id -p uid=0(root) gid=1(other) projid=101(x-files)

4. Fügen Sie einen neuen privilegierten Wert für project.max-lwps hinzu, der die Anzahl der LWPs auf drei begrenzt.

   # prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files

5. Überprüfen Sie das Ergebnis.

   # prctl -n project.max-lwps -i project x-files process: 111108: csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.max-lwps privileged 3 - deny - system 2.15G max deny -

So verwenden Sie den Befehl prctl zum Herabsetzen eines Resource Control-Werts

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Geben Sie den Befehl prctl mit der Option -r ein, um den niedrigsten Wert der Resource Control process.max-file-descriptor zu ändern.

   # prctl -n process.max-file-descriptor -r -v 128 $$

So verwenden Sie den Befehl prctl zum Anzeigen, Ersetzen und Überprüfen eines Resource Control-Werts in einem Projekt

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Zeigen Sie den Wert der Resource Control project.cpu-shares im Projekt group.staff an.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 1 - none - system 65.5K max none

3. Ersetzen Sie den aktuellen Wert für project.cpu-shares von 1 durch den Wert 10.

   # prctl -n project.cpu-shares -v 10 -r -i project group.staff

4. Zeigen Sie den Wert der Resource Control project.cpu-shares im Projekt group.staff an.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 10 - none - system 65.5K max none

Verwenden von rctladm

So verwenden Sie rctladm

Mit dem Befehl rctladm können Sie Echtzeitabfragen und Modifikationen des globalen Status von Resource Controls durchführen. Weitere Informationen finden Sie in der Manpage rctladm(1M).

Sie können beispielsweise den Befehl rctladm mit der Option -e eingeben, um das globale Attribut syslog einer Resource Control zu aktivieren. Wenn der Schwellenwert der Resource Control überschritten wird, protokolliert das System eine Benachrichtigung auf der angegebenen syslog-Stufe. Um das globale Attribut syslog der Resource Control process.max-file-descriptor zu aktivieren, geben Sie Folgendes ein:

# rctladm -e syslog process.max-file-descriptor

Der Befehl rctladm ohne Argumente zeigt die globalen Flags (einschließlich des Flags für den globalen Typ) für jede Resource Control an.

# rctladm
process.max-port-events     syslog=off  [ deny count ]
process.max-msg-messages    syslog=off  [ deny count ]
process.max-msg-qbytes      syslog=off  [ deny bytes ]
process.max-sem-ops         syslog=off  [ deny count ]
process.max-sem-nsems       syslog=off  [ deny count ]
process.max-address-space   syslog=off  [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=off  [ lowerable deny count ]
process.max-core-size       syslog=off  [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off  [ lowerable deny no-signal bytes ]
.
.
.

Verwenden von ipcs

So verwenden Sie ipcs

Mit dem Dienstprogramm ipcs können Sie Informationen zur aktiven prozessübergreifenden Kommunikation (Interprocess Communication, IPC) anzeigen. Weitere Informationen finden Sie in der Manpage ipcs(1).

Geben Sie den Befehl ipcs mit der Option -J ein, um anzuzeigen, welcher Projekt-Grenzwert einem IPC-Objekt zugeordnet ist.

# ipcs -J
    IPC status from <running system> as of Wed Mar 26 18:53:15 PDT 2003
T         ID      KEY        MODE       OWNER    GROUP    PROJECT
Message Queues:
Shared Memory:
m       3600      0       --rw-rw-rw-   uname    staff    x-files
m        201      0       --rw-rw-rw-   uname    staff    x-files
m       1802      0       --rw-rw-rw-   uname    staff    x-files
m        503      0       --rw-rw-rw-   uname    staff    x-files
m        304      0       --rw-rw-rw-   uname    staff    x-files
m        605      0       --rw-rw-rw-   uname    staff    x-files
m          6      0       --rw-rw-rw-   uname    staff    x-files
m        107      0       --rw-rw-rw-   uname    staff    x-files
Semaphores:
s          0      0       --rw-rw-rw-   uname    staff    x-files

Kapazitätswarnungen

Mit einer globalen Aktion für eine Resource Control können Sie benachrichtigt werden, wenn ein Element durch einen zu niedrig eingestellten Resource Control-Wert behindert wird.

Angenommen, Sie möchten feststellen, ob ein Webserver über ausreichend CPUs für die typische Arbeitslast verfügt. Sie können die sar-Daten auf CPU-Zeit im Wartezustand und den Lastdurchschnitt analysieren. Sie können aber auch die Extended Accounting-Daten auswerten, um die Anzahl der gleichzeitigen Prozesse zu ermitteln, die für den Webserver-Prozess ausgeführt werden.

Der einfachste Ansatz ist jedoch, eine Aufgabe für den Webserver zu erstellen. Dann richten Sie eine globale Aktion mit dem Befehl syslog ein, um immer dann benachrichtigt zu werden, wenn eine Aufgabe die für die Kapazitäten des Computers eingerichtete Anzahl an LWPs überschreitet.

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

So stellen Sie fest, ob einem Webserver ausreichend CPU-Kapazität zugeordnet ist

1. Geben Sie den Befehl prctl ein, um eine privilegierte Resource Control (mit einem Superuser als Eigentümer) für die Aufgaben einzurichten, die einen httpd-Prozess enthalten. Begrenzen Sie die Gesamtzahl der LWPs für jede Aufgabe auf 40 und deaktivieren Sie alle lokalen Aktionen.

   # prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd`

2. Aktivieren Sie die globale Aktion eines Systemprotokolls für die Resource Control task.max-lwps.

   # rctladm -e syslog task.max-lwps

3. Überwachen Sie, ob die Arbeitslast die Resource Control auslöst.

   In diesem Fall werden /var/adm/messages wie die Folgende angezeigt:

   Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19

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.

Kapitel 9 Verwalten des Fair Share Scheduler (Vorgehen)

In diesem Kapitel wird die Verwendung des Fair Share Scheduler (FSS) beschrieben.

Eine Einführung zum FSS finden Sie in Kapitel 8Einführung in den Fair Share Scheduler. Weitere Informationen zu Scheduling-Klassen bei installierten Zonen finden Sie unter Scheduling-Klasse in einer Zone.

Verwalten des Fair Share Scheduler (Übersicht der Schritte)

Überwachen des FSS

Mit dem in der Manpage prstat(1M) ausführlich beschriebenen Befehl prstat können Sie die CPU-Nutzung durch aktive Projekte überwachen.

Sie können die Extended Accounting-Daten für Aufgaben verwenden, um Statistiken der einzelnen Projekte zum Betrag der CPU-Ressourcen zu beziehen, die über einen längeren Zeitraum verbraucht werden. Weitere Informationen finden Sie in Kapitel 4Einführung in das Extended Accounting.

So überwachen Sie die CPU-Nutzung durch Projekte

1. Zum Überwachen der CPU-Nutzung durch die auf einem System ausgeführten Projekte verwenden Sie den Befehl prstat mit der Option -J.

   % prstat -J

So überwachen Sie die CPU-Nutzung durch Projekte in Prozessorsets

1. Zum Überwachen der CPU-Nutzung durch Projekte in einer Liste von Prozessorsets geben Sie Folgendes ein:

   % prstat -J -C pset-list

   dabei steht pset-list für eine Liste der durch Kommata getrennten Prozessorset-IDs.

Konfigurieren des FSS

Die gleichen Befehle, die Sie für andere Scheduling-Klasse im Solaris-System verwenden, können auch für den FSS eingesetzt werden. Sie können die Scheduler-Klasse festlegen, die Parameter des Scheduler konfigurieren und die Eigenschaften bestimmter Prozesse einstellen.

Zum Neustarten des Scheduler-Service geben Sie den Befehl svcadm restart ein. Weitere Informationen finden Sie unter svcadm(1M).

So legen Sie FSS als standardmäßige Scheduling-Klasse fest

Der FSS muss als standardmäßiger Scheduler auf dem System eingerichtet sein, damit die Zuweisung von CPU-Shares wirksam ist.

Mit einer Kombination der Befehle priocntl und dispadmin stellen Sie sicher, dass der FSS unmittelbar und auch nach einem Neustart der standardmäßige Scheduler wird.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Legen Sie FSS als standardmäßigen Scheduler für das System fest.

   # dispadmin -d FSS

   Diese Änderung wirkt sich nach dem nächsten Neustart aus. Nach dem Neustart wird jeder Prozess auf dem System in der FSS-Scheduling-Klasse ausgeführt.

3. Die folgende Konfiguration wird unmittelbar und ohne einen Neustart wirksam.

   # priocntl -s -c FSS -i all

So verschieben Sie manuelle Prozesse aus der TS-Klasse in die FSS-Klasse

Sie können Prozesse manuell aus einer Scheduling-Klasse in eine andere Scheduling-Klasse verschieben, ohne die standardmäßige Scheduling-Klasse zu ändern oder das System neu zu booten. Dieses Verfahren zeigt, wie Sie Prozesse manuell aus der TS-Scheduling-Klasse in die FSS-Scheduling-Klasse verschieben.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Verschieben Sie den init-Prozess (pid 1) in die FSS-Scheduling-Klasse.

   # priocntl -s -c FSS -i pid 1

3. Verschieben Sie alle Prozesse aus der TS-Scheduling-Klasse in die FSS-Scheduling-Klasse.

   # priocntl -s -c FSS -i class TS

   ---

   Hinweis –

   Nach dem Neustart werden alle Prozesse wieder in der TS-Scheduling-Klasse ausgeführt.

   ---

So verschieben Sie Prozesse manuell aus allen Benutzerklassen in die FSS-Klasse

Eventuell verwenden Sie eine andere Standard-Klasse als die TS-Scheduling-Klasse. Vielleicht wird das System in einer Fensterumgebung ausgeführt, die standardmäßig die IA-Klasse verwendet. Sie können alle Prozesse manuell in die FSS-Scheduling-Klasse verschieben, ohne die standardmäßige Scheduling-Klasse zu ändern oder das System neu zu booten.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Verschieben Sie den init-Prozess (pid 1) in die FSS-Scheduling-Klasse.

   # priocntl -s -c FSS -i pid 1

3. Verschieben Sie alle Prozesse aus den aktuellen Scheduling-Klassen in die FSS-Scheduling-Klasse.

   # priocntl -s -c FSS -i all

   ---

   Hinweis –

   Nach dem Neustart werden alle Prozesse wieder in der standardmäßigen Scheduling-Klasse ausgeführt.

   ---

So verschieben Sie die Prozesse eines Projekts manuell in die FSS-Klasse

Sie können die Prozesse eines Projekts manuell aus der aktuellen Scheduling-Klasse in die FSS-Scheduling-Klasse verschieben.

1. Melden Sie sich als Superuser an oder nehmen Sie eine entsprechende Rolle an.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Verschieben Sie Prozesse, die in der Projekt-ID 10 ausgeführt werden, in die FSS-Scheduling-Klasse.

   # priocntl -s -c FSS -i projid 10

   Nach dem Neustart werden die Prozesse des Projekts wieder in der standardmäßigen Scheduling-Klasse ausgeführt.

So stellen Sie die Scheduler-Parameter ein

Mit dem Befehl dispadmin können Sie die Parameter eines Prozess-Schedulers bei laufendem System anzeigen oder ändern. Beispielsweise können Sie den Befehl dispadmin eingeben, um den Zeit-Quantumwert des FSS-Schedulers zu prüfen und einzustellen. Zeit-Quantum ist die Zeit, die ein Thread ausgeführt werden darf, bevor er die Kontrolle über den Prozessor abgeben muss.

Zum Anzeigen des aktuellen Zeit-Quantums für den FSS-Scheduler bei laufendem System geben Sie Folgendes ein:

$ dispadmin -c FSS -g
#
# Fair Share Scheduler Configuration
#
RES=1000
#
# Time Quantum
#
QUANTUM=110

Wenn Sie die Option -g verwenden, können Sie auch die Option -r angeben, um die Auflösung festzulegen, die beim Drucken der Zeit-Quantumswerte verwendet wird. Wenn keine Auflösung angegeben ist, werden die Zeit-Quantumswerte standardmäßig als Millisekunden angezeigt.

$ dispadmin -c FSS -g -r 100
#
# Fair Share Scheduler Configuration
#
RES=100
#
# Time Quantum
#
QUANTUM=11

Zum Einstellen der Scheduling-Parameter der FSS-Scheduling-Klasse geben Sie dispadmin -s ein. Die Werte in Datei müssen in dem Format vorliegen, das von der Option -g ausgegeben wird. Diese Werte überschreiben die aktuellen Werte im Kernel. Geben Sie Folgendes ein:

$ dispadmin -c FSS -s file

Kapitel 10 Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons

Mit dem Resource Capping Daemon rcapd können Sie den Speicherverbrauch durch Prozesse steuern, die in Projekten ausgeführt werden, für die Resource Caps (Ressourcenbegrenzungen) definiert sind.

Solaris 10 8/07: Wenn Zonen auf dem System ausgeführt werden, können Sie den rcapd von der globalen Zone aus einsetzen, um den Speicherverbrauch in nicht-globalen Zonen zu regulieren. Lesen Sie dazu Kapitel 18Planen und Konfigurieren von nicht-globalen Zonen (Vorgehen).

In diesem Kapitel werden folgende Themen behandelt.

• Einführung in den Resource Capping Daemon

• Funktionsweise von Memory Resource Caps

• Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte

• rcapd-Konfiguration

• Überwachen der Ressourcenauslastung mit rcapstat

• Mit rcapd verwendete Befehle

Informationen zu Verfahren, bei denen der rcapd eingesetzt wird, finden Sie in Kapitel 11Verwalten des Resource Capping Daemons (Vorgehen).

Neuerungen bei der Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons

Solaris 10: Sie können jetzt den Befehl projmod verwenden, um das Attribut rcap.max-rss in der Datei /etc/project einzurichten.

Solaris 10 11/06: Es wurden Informationen zum Aktivieren und Deaktivieren des Resource Capping Daemons als ein Service in der Solaris Service Management Facility (SMF) hinzugefügt.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Einführung in den Resource Capping Daemon

Eine Resource Cap (Speicherbegrenzung) ist ein oberer Grenzwert, der für den Verbrauch einer Ressource, z. B. von reellem Arbeitsspeicher, eingerichtet wird. Dabei werden Memory Caps für den reellen Speicher auf Projektbasis unterstützt.

Der Resource Capping Daemon und die dazugehörigen Dienstprogramme stellen Mechanismen bereit, mit denen eine Memory Cap für den reellen Speicher durchgesetzt und verwaltet werden kann.

Wie eine Resource Control kann eine Memory Resource Cap mithilfe von Attributen für Projekteinträge in der project-Datenbank definiert werden. Während Resource Controls synchron über den Kernel durchgesetzt werden, werden Memory Resource Caps asynchron auf Benutzerebene über den Resource Capping Daemon durchgesetzt. Bei asynchroner Durchsetzung tritt aufgrund des vom Daemon verwendeten Sampling-Intervalls immer eine kurze Verzögerung auf.

Weitere Informationen zu rcapd finden Sie in der Manpage rcapd(1M) Informationen zu Projekten und der project-Datenbank finden Sie in Kapitel 2Einführung in Projekte und Aufgaben und in der Manpage project(4) Weitere Informationen zu Resource Controls finden Sie in Kapitel 6Einführung in die Resource Controls.

Funktionsweise von Memory Resource Caps

Der Daemon misst in regelmäßigen Intervallen die Ressourcenauslastung durch Projekte, für die eine Memory Resource Cap eingerichtet wurde. Das Sampling-Intervall des Daemons wird vom Administrator festgelegt. Weitere Informationen finden Sie unter Festlegen der Messintervalle Wenn die Speicherauslastung durch das System den Schwellenwert für die Memory Cap-Durchsetzung überschreitet und andere Bedingungen erfüllt sind, führt der Daemon Maßnahmen aus, um den Ressourcenverbrauch durch Projekte mit Memory Caps zu reduzieren, bis der Schwellenwert oder ein darunter liegender Wert erreicht ist.

Das virtuelle Speichersystem teilt den reellen Speicher in Segmente auf, die als Pages (Seiten) bezeichnet werden. Pages sind die grundlegende Einheit des reellen Arbeitsspeichers im Solaris-Subsystem zur Speicherverwaltung. Um Daten aus einer Datei in den Speicher einzulesen, liest das virtuelle Speichersystem jeweils eine Page ein; man sagt auch, es erfolgt ein Page-in einer Datei. Zur Reduzierung des Ressourcenverbrauchs kann der Daemon ein Page-out bzw. eine Verlegung von selten genutzten Pages auf ein Swap-Gerät, einen Bereich außerhalb des reellen Speichers, durchführen.

Der Daemon verwaltet den reellen Speicher durch Regulieren der Resident Set-Größe der Arbeitslast eines Projekts in Relation zur Working Set-Größe. Ein Resident Set umfasst mehrere Pages, die im reellen Speicher festgespeichert sind. Ein Working Set umfasst mehrere Pages, die von der Arbeitslast des Projekts während des Verarbeitungszyklus aktiv genutzt werden. Das Working Set ändert sich über die Zeit, abhängig vom Betriebsmodus des Prozesses und dem Typ der verarbeiteten Daten. Im Idealfall hat jede Arbeitslast Zugriff auf ausreichend reellen Speicher, so dass das zugehörige Working Set resident bleiben kann (und nicht ausgelagert wird). Jedoch kann das Working Set auch die Nutzung von sekundären Festplattenspeicher umfassen. Dieser Bereich enthält Speicher, der nicht in den reellen Speicher passt.

Es kann nur jeweils eine Instanz von rcapd ausgeführt werden.

Attribute zur Begrenzung der Nutzung des reellen Speichers für Projekte

Zum Definieren einer Memory Resource Cap für ein Projekt stellen Sie eine Resident Set Size (RSS)-Cap ein, indem Sie das folgende Attribut zum project-Datenbankeintrag hinzufügen:

rcap.max-rss

Die Gesamtmenge des reellen Speichers in Byte, der Projektprozessen zur Verfügung steht.

Beispielsweise stellt die folgende Zeile in der Datei /etc/project eine RSS-Cap von 10 GB für ein Projekt namens db ein.

db:100::db,root::rcap.max-rss=10737418240

Das System rundet den angegebenen Cap-Wert eventuell auf die Größe einer Page ab.

Mit dem Befehl projmod können Sie das Attribut rcap.max-rss in der Datei /etc/project einstellen:

# projmod -s -K rcap.max-rss=10GB db

Die Datei /etc/project enthält dann die folgende Zeile:

db:100::db,root::rcap.max-rss=10737418240

rcapd-Konfiguration

Mit dem Befehl rcapadm konfigurieren Sie den Resource Capping Daemon. Sie können die folgenden Aktionen durchführen:

• Einrichten eines Schwellenwertes für die Cap-Durchsetzung

• Einrichten der Intervalle für Vorgänge, die vom rcapd durchgeführt werden

• Aktivieren oder Deaktivieren des Resource Capping

• Anzeigen des aktuellen Status des konfigurierten Resource Capping Daemon

Zum Konfigurieren des Daemons müssen Sie als Superuser angemeldet sein oder über das „Process Management“-Profil verfügen. Das „Process Management“-Profil enthält die Prozessmanager-Rolle und die Systemadministrator-Rolle.

Konfigurationsänderungen können gemäß des Konfigurationsintervalls (siehe rcapd-Vorgangsintervalle) oder bei Bedarf durch Senden von SIGHUP (siehe Manpage kill(1)) in den rcapd eingebracht werden.

Erfolgt die Eingabe ohne Argumente, zeigt rcapadm den aktuellen Status des Resource Capping Daemons an, sofern dieser konfiguriert wurde.

In den folgenden Unterabschnitten werden die Cap-Durchsetzung, Cap-Werte und die Intervalle für rcapd-Vorgänge beschrieben.

Verwenden des Resource Capping Daemons auf einem System mit installierten Zonen

Sie können die Resident Set Size (RSS)-Nutzung einer Zone durch Einstellen der Ressource capped-memory während der Zonenkonfiguration einrichten. Weitere Informationen finden Sie unter Solaris 10 8/07: Steuerung des reellen Speichers und der capped-memory-Ressource. Zur Durchsetzung von Memory Caps für Projekte in einer Zone (einschließlich der globalen Zone) führen Sie den Befehl rcapd in der Zone aus.

Sie können die Menge an Speicher, die von einer angegebenen Zone maximal beansprucht werden kann, temporär bis zum nächsten Neustart begrenzen. Lesen Sie dazu So legen Sie eine temporäre Resource Cap für eine Zone fest.

Wenn Sie rcapd in einer Zone verwenden, um den Speicherverbrauch durch Projektprozesse zu regulieren, für die Resource Caps definiert wurden, müssen Sie den Daemon in dieser Zone konfigurieren.

Beim Einrichten von Memory Caps für Anwendungen in unterschiedlichen Zonen muss allgemein nicht berücksichtigt werden, dass die Anwendungen in unterschiedlichen Zonen gespeichert sind. Die Ausnahme sind Services, die in allen Zonen ausgeführt werden. In allen Zonen ausgeführte Services verbrauchen Speicher. Dieser Speicherverbrauch muss bei der Ermittelung der erforderlichen Größe des reellen Speichers für ein System und der Memory Caps berücksichtigt werden.

Sie können rcapd nicht in einer lx Branded Zone ausführen. Sie können den Daemon jedoch von der globalen Zone aus verwenden, um den Speicher in der Branded Zone zu begrenzen.

Schwellenwert für die Memory Cap-Durchsetzung

Der Schwellenwert für die Memory Cap-Durchsetzung ist ein Prozentsatz der Systemspeicherauslastung, bei dem eine Cap-Durchsetzung ausgelöst wird. Wenn das System diese Auslastung überschreitet, werden die Memory Caps durchgesetzt. Der von Anwendungen und Kernel genutzte reelle Speicher ist in diesem Prozentsatz enthalten. Der Prozentsatz der Auslastung legt fest, wie Memory Caps durchgesetzt werden.

Um Memory Caps durchzusetzen, kann Speicher von Projekt-Arbeitslasten ausgelagert werden (Page-out).

• Speicher wird ausgelagert, um den Betrag des Speichers zu reduzieren, der bei einer bestimmten Arbeitslast über die Memory Cap hinausgeht.

• Speicher kann ausgelagert werden, um den Anteil an reellem Speicher zu reduzieren, der über den Memory Cap-Schwellenwert des Systems hinaus genutzt wird.

Eine Arbeitslast kann reellen Speicher bis ihrer Memory Cap nutzen. Eine Arbeitslast kann weiteren Speicher nutzen, solange die Systemspeicherauslastung unter dem Memory Cap-Schwellenwert bleibt.

Informationen zum Einrichten eines Schwellenwerts für die Memory Cap-Durchsetzung finden Sie unter So richten Sie einen Schwellenwert für die Memory Cap-Durchsetzung ein.

Festlegen der Memory Cap-Werte

Ist der Schwellenwert eines Projekts zu niedrig angesetzt, steht eventuell nicht genügend Speicher für die Arbeitslast bereit, um unter normalen Bedingungen effektiv zu arbeiten. Das auftretende Paging (da die Arbeitslast mehr Speicher benötigt) hat negative Auswirkungen auf die Systemleistung.

Projekte, deren Memory Caps zu hoch eingerichtet wurden, verbrauchen eventuell den verfügbaren reellen Speicher, bevor ihre Memory Cap überschritten sind. In diesem Fall wird der reelle Speicher vom Kernel und nicht von rcapd verwaltet.

Bei der Festlegung von Memory Caps müssen Sie die folgenden Faktoren berücksichtigen.

Auswirkungen auf das E/A-System

Der Daemon kann versuchen, die Nutzung des reellen Speichers durch eine Projekt-Arbeitslast zu reduzieren, wenn die gemessene Nutzung die Memory Cap des Projekts überschreitet. Während der Cap-Durchsetzung werden die Swap-Geräte und andere Geräte verwendet, die von der Arbeitslast zugewiesene Dateien enthalten. Die Leistung der Swap-Geräte ist ein wichtiger Faktor für die Ermittlung der Leistung einer Arbeitslast, die ihren Memory Cap-Schwellenwert regelmäßig überschreitet. Die Ausführung der Arbeitslast ähnelt dem Ausführen der Arbeitslast auf einem Computer, dessen reeller Speicher der Memory Cap der Arbeitslast entspricht.

Auswirkungen auf die CPU-Nutzung

Die CPU-Nutzung durch den Daemon hängt von der Anzahl der Prozesse in der Projekt-Arbeitslast, für die das Capping durchgeführt wird, sowie von der Größe der Arbeitslast-Adressräume ab.

Ein kleiner Teil der CPU-Zeit des Daemons wird für das Messen der Nutzung durch jede Arbeitslast aufgewendet. Das Hinzufügen von Prozessen zu Arbeitslasten verlängert die Zeit, die für das Messen der Nutzung aufgewendet werden muss.

Ein weiterer Teil der CPU-Zeit des Daemons wird für die Durchsetzung von Memory Caps aufgewendet, wenn diese überschritten werden. Die aufgewendete Zeit ist proportional zur Größe des betroffenen virtuellen Speichers. Die aufgewendete CPU-Zeit verlängert oder verkürzt sich bei Änderungen der Gesamtgröße des Arbeitslast-Adressraums. Diese Daten werden in der Spalte vm der rcapstat-Ausgabe aufgeführt. Weitere Informationen finden Sie unter Überwachen der Ressourcenauslastung mit rcapstat und in der Manpage rcapstat(1).

Berichte zum Shared Memory

Der Daemon rcapd meldet den RSS von Speicherseiten, die mit anderen Prozessen gemeinsam genutzt werden bzw. im gleichen Prozess mehrmals zugewiesen sind, als verhältnismäßig genauen Schätzwert. Wenn Prozesse in unterschiedlichen Projekten den gleichen Speicherbereich gemeinsam nutzen, wird dieser Speicherplatz zum RSS-Gesamtwert für alle Projekte, die auf diesen Speicher zugreifen, hinzugerechnet.

Dieser Schätzwert ist beispielsweise für Datenbanken nützlich, die Shared Memory ausgiebig verwenden. Bei Datenbanken können Sie zur Festlegung eines geeigneten Anfangsstandardwerts mithilfe der Optionen -J bzw. -Z des Befehls prstat eine Stichprobe des Speicherbedarfs eines Projekts ermitteln. Weitere Informationen finden Sie in der Manpage prstat(1M).

rcapd-Vorgangsintervalle

Sie können die Intervalle für die regelmäßig vom rcapd ausgeführten Vorgänge ändern.

Alle Intervalle werden in Sekunden angegeben. Die rcapd-Vorgänge und die zugehörigen Standardintervalle sind in der folgenden Tabelle angegeben.

Informationen zum Einrichten der Intervalle finden Sie unter So richten Sie Vorgangsintervalle ein.

Festlegen der rcapd-Suchintervalle

Mit dem Suchintervall wird festgelegt, wie oft rcapd nach neuen Prozessen sucht. Bei Systemen mit vielen aktiven Prozessen dauert das Suchen in der Liste länger. In diesem Fall sollte das Intervall vergrößert werden, um die insgesamt aufgewendete CPU-Zeit zu reduzieren. Das Suchintervall muss jedoch mindestens der Zeit entsprechen, die ein Prozess existieren muss, um zu einer Arbeitslast mit Memory Cap beizutragen. Ist das Suchintervall zu lang, kann rcapd bei Arbeitslasten, die sehr viele kurzlebige Prozesse ausführen, eventuell nicht alle erforderlichen Prozesse erfassen.

Festlegen der Messintervalle

Das mit rcapadm konfigurierte Messintervall ist der kürzeste Zeitraum, den rcapd zwischen dem Messen einer Ressourcennutzung durch eine Arbeitslast und dem Durchsetzen der Memory Cap wartet, wenn diese überschritten wird. Wenn Sie dieses Intervall reduzieren, setzt rcapd in den meisten Fällen die Memory Cap häufiger durch, was wiederum zu erhöhtem E/A-Datenverkehr aufgrund von Paging führen kann. Andererseits kann ein kürzeres Intervall die Auswirkungen eines von einer Arbeitslast verursachten plötzlichen Anstiegs der Ressourcennutzung auf andere Arbeitslasten verringern. Das Zeitfenster zwischen Messungen, in dem die Arbeitslast Speicher uneingeschränkt verbrauchen und möglicherweise Speicher von anderen Arbeitslasten mit Memory Cap wegnehmen könnte, wird eingeengt.

Ist das für rcapstat eingerichtete Messintervall kürzer als das für rcapd mit rcapadm, könnte die Ausgabe bei einigen Intervallen null sein. Dies liegt daran, dass rcapd die Statistiken nicht häufiger als das für rcapadm eingerichtete Intervall aktualisiert. Das für rcapadm eingerichtete Intervall ist unabhängig von dem Messintervall, das von rcapstat verwendet wird.

Überwachen der Ressourcenauslastung mit rcapstat

Mit rcapstat überwachen Sie die Ressourcenauslastung durch Projekte, für die eine Memory Cap eingerichtet wurde. Ein Beispiel für einen rcapstat-Bericht finden Sie unter Erstellen von Berichten mit rcapstat.

Sie können das Messintervall für den Bericht und die Häufigkeit festlegen, wie oft Statistiken wiederholt werden.

Intervall

Legt das Messintervall in Sekunden fest. Das Standardintervall ist 5 Sekunden.

Zählung

Legt die Häufigkeit fest, wie oft Statistiken wiederholt werden. In der Standardeinstellung meldet rcapstat Statistiken, bis ein Signal zur Beendigung empfangen wurde oder der Prozess rcapd beendet wird.

Die Paging-Statistiken im ersten Bericht von rcapstat zeigen die Aktivität seit dem Starten des Daemons. Nachfolgende Berichte spiegeln die Aktivität nach der Veröffentlichung des jeweils letzten Berichts wider.

Die folgende Tabelle enthält Definitionen der Spaltenüberschriften eines rcapstat-Berichts.

Mit rcapd verwendete Befehle

Kapitel 11 Verwalten des Resource Capping Daemons (Vorgehen)

In diesem Kapitel werden die Verfahren zum Konfigurieren und Verwenden des Resource Capping Daemons rcapd beschrieben.

Eine Einführung in den rcapd finden Sie in Kapitel 10Einführung in die Steuerung des reellen Arbeitsspeichers mithilfe des Resource Capping Daemons.

Konfigurieren und Verwenden des Resource Capping Daemons (Übersicht der Schritte)

Verwalten des Resource Capping Daemons mit rcapadm

In diesem Abschnitt werden die Verfahren zum Konfigurieren und Verwenden des Resource Capping Daemons mit dem Befehl rcapadm beschrieben. Weitere Informationen finden Sie in rcapd-Konfiguration und in der Manpage rcapadm(1M). Auch das Verwenden von rcapadm zum Festlegen einer temporären Resource Cap für eine Zone wird behandelt.

Erfolgt die Eingabe ohne Argumente, zeigt rcapadm den aktuellen Status des Resource Capping Daemons an, sofern dieser konfiguriert wurde.

So richten Sie einen Schwellenwert für die Memory Cap-Durchsetzung ein

Memory Caps können so konfiguriert werden, dass sie erst dann durchgesetzt werden, wenn der für Prozesse verfügbare reelle Speicher zu gering wird. Weitere Informationen finden Sie unter Schwellenwert für die Memory Cap-Durchsetzung.

Der Mindestwert (und die Standardeinstellung) ist 0; dies bedeutet, dass Memory Caps immer durchgesetzt werden. Zum Einrichten eines anderen Mindestwerts führen Sie das folgende Verfahren aus.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Geben Sie den Befehl rcapadm mit der Option -c ein, um einen anderen Wert für die Speicherauslastung einzurichten, ab dem eine Memory Cap durchgesetzt wird.

   # rcapadm -c percent

   percent liegt im Bereich von 0 bis 100. Höhere Werte sind weniger einschränkend. Ein höherer Wert bedeutet, dass Projekt-Arbeitslasten mit Memory Caps ausgeführt werden können, ohne dass die Memory Caps durchgesetzt werden, bis die Systemspeicherauslastung diesen Schwellenwert überschreitet.

Siehe auch

Wie die aktuelle Speicherauslastung und der Schwellenwert für die Memory Cap-Durchsetzung angezeigt werden, können Sie unter Erstellen von Berichten zur Speicherauslastung und dem Schwellenwert für die Durchsetzung der Memory Cap nachlesen.

So richten Sie Vorgangsintervalle ein

rcapd-Vorgangsintervalle enthält Informationen über die Intervalle, in denen die regelmäßig von rcapd durchgeführten Vorgänge ausgeführt werden. Zum Einstellen der Vorgangsintervalle mit rcapadm führen Sie die folgenden Schritte aus.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Verwenden Sie die Option -i, um das Intervall einzurichten.

   # rcapadm -i interval=value,...,interval=value

   ---

   Hinweis –

   Alle Intervallwerte werden in Sekunden angegeben.

   ---

So aktivieren Sie das Resource Capping

Es gibt drei Möglichkeiten, das Resource Capping auf einem System zu aktivieren. Das Aktivieren des Resource Capping stellt auch die Standardwerte in der Datei /etc/rcap.conf ein.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Aktivieren Sie den Resource Capping Daemon mit einer der folgenden Methoden:

   • Aktivieren Sie das Resource Capping mit dem Befehl svcadm.

     # svcadm enable rcap

   • Um den Resource Capping Daemon so zu aktivieren, dass er unmittelbar und bei jedem Neustart des Systems gestartet wird, geben Sie Folgendes ein:

     # rcapadm -E

   • Um den Resource Capping Daemon bei einem Neustart zu starten, ohne dass er unmittelbar gestartet wird, geben Sie die Option -n an:

     # rcapadm -n -E

So deaktivieren Sie das Resource Capping

Es gibt drei Möglichkeiten, das Resource Capping auf einem System zu deaktivieren.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Deaktivieren Sie den Resource Capping Daemon auf eine der folgenden Arten:

   • Deaktivieren Sie das Resource Capping mit dem Befehl svcadm.

     # svcadm disable rcap

   • Um den Resource Capping Daemon so zu deaktivieren, dass er unmittelbar deaktiviert und bei einem Neustart des Systems nicht gestartet wird, geben Sie Folgendes ein:

     # rcapadm -D

   • Um den Resource Capping Daemon zu deaktivieren, ohne ihn unmittelbar zu stoppen, geben Sie die Option -n an:

     # rcapadm -n -D

   ---

   Tipp –

   Sicheres Deaktivieren des Resource Capping Daemons

   ---

   Geben Sie den Befehl svcadm oder den Befehl rcapadm mit der Option -D ein, um den rcapd sicher zu deaktivieren. Wenn der Daemon beendet wird (siehe die Manpage kill(1)), könnten Prozesse mit dem Status „stopped“ zurückbleiben, die dann manuell neu gestartet werden müssen. Um einen Prozess weiter auszuführen, verwenden Sie den Befehl prun. Weitere Informationen finden Sie in der Manpage prun(1).

So legen Sie eine temporäre Resource Cap für eine Zone fest

Mit dieser Vorgehensweise wird der Speicher begrenzt, der von einer angegebenen Zone maximal beansprucht werden kann. Dieser Wert gilt nur bis zum nächsten Neustart. Um eine dauerhafte Begrenzung festzulegen, verwenden Sie den Befehl zonecfg.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil.

2. Legen Sie eine Speichergrenze von 512 MB für die Zone my-zone fest.

   # rcapadm -z testzone -m 512M

Erstellen von Berichten mit rcapstat

Mit dem Befehl rcapstat erstellen Sie Berichte zu den Resource Capping-Statistiken. Überwachen der Ressourcenauslastung mit rcapstat beschreibt, wie Sie den Befehl rcapstat zum Erstellen von Berichten verwenden. Dieser Abschnitt enthält darüber hinaus Beschreibungen der Spaltenüberschriften in einem Bericht. Diese Informationen finden Sie auch in der Manpage rcapstat(1).

Die folgenden Unterabschnitte enthaltenen Beispiele, mit denen das Erstellen eines Berichts für einen bestimmten Zweck verdeutlicht wird.

Erstellen von Berichten mit Memory Cap- und Projektinformationen

In diesem Beispiel werden Memory Caps für zwei Projekte definiert, die zwei verschiedenen Benutzern zugeordnet sind. user1 hat eine Memory Cap von 50 MB, user2 eine Memory Cap von 10 MB.

Der folgende Befehl erzeugt fünf Berichte in einem Messintervall von 5 Sekunden.

user1machine% rcapstat 5 5
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M   50M    0K 3312K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K 

Die ersten drei Zeilen dieser Ausgabe bilden den ersten Bericht, der Memory Cap- und Projekt-Informationen für die zwei Projekte sowie Paging-Statistiken ab dem Start von rcapd enthält. Die Spalten at und pg enthalten Werte größer Null für user1 und Null für user2. Dies deutet darauf hin, dass user1 seinen Grenzwert für einen bestimmten Zeitraum im Verlauf des Daemons überschritten hat, user2 jedoch nicht.

Die nachfolgenden Berichte zeigen keine wichtige Aktivität.

Überwachen der RSS eines Projekts

Das folgende Beispiel zeigt das Projekt user1, in dem eine RSS über der zugehörigen RSS-Memory Cap vorliegt.

Der folgende Befehl erzeugt fünf Berichte in einem Messintervall von 5 Sekunden.

user1machine% rcapstat 5 5

    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M  220M  5528K  2764K
376565   user1      3 6249M 6144M 6144M    0M  131M  4912K  1637K
376565   user1      3 6249M 6171M 6144M   27M  147M  6048K  2016K
376565   user1      3 6249M 6146M 6144M 4872M  174M  4368K  1456K
376565   user1      3 6249M 6156M 6144M   12M  161M  3376K  1125K

Das Projekt user1 hat drei Prozesse, die aktiv reellen Speicher nutzen. Die positiven Werte in der Spalte pg weisen daraufhin, dass der rcapd ständig Speicher auslagert, während er versucht, die Memory Cap einzuhalten, indem die Speicherauslastung durch Projektprozesse gesenkt wird. rcapd ist jedoch nicht in der Lage, die RSS unter dem Memory Cap-Wert zu halten. Dies wird durch die wechselnden rss-Werte verdeutlicht, die keine entsprechende Reduzierung zeigen. Sobald Speicher ausgelagert wird, nutzt die Arbeitslast den Speicher neu und der RSS-Wert steigt wieder an. Dies bedeutet, dass der gesamte residente Speicher des Projekts aktiv genutzt wird und die Working Set-Größe (WSS) größer als die Memory Cap ist. Aus diesem Grund ist der rcapd gezwungen, einen Teil des Working Sets auszulagern, um die Memory Cap einzuhalten. In diesem Zustand treten weiterhin zahlreiche Page-Faults und somit erhöhtes E/A auf, bis eines der Folgenden eintritt:

• Die WSS wird kleiner.

• Die Memory Cap wird angehoben.

• Die Anwendung ändert das Speicherzugriffsmuster.

In dieser Situation könnte ein kürzeres Messintervall die Diskrepanz zwischen dem RSS- und dem Cap-Wert reduzieren, da der rcapd gezwungen wäre, die Arbeitslast häufiger zu messen und Memory Caps häufiger durchzusetzen.

Ein Page-Fault tritt immer dann auf, wenn entweder eine neue Page erstellt oder von einem Swap-Gerät eingelesen werden muss.

Festlegen der Working Set-Größe eines Projekts

Das folgende Beispiel schließt an das vorherige Beispiel an und verwendet das gleiche Projekt.

Das vorherige Beispiel zeigt, dass das Projekt user1 mehr reellen Speicher nutzt als seine Memory Cap gestattet. Dieses Beispiel zeigt, wie viel Speicher die Projekt-Arbeitslast benötigt.

user1machine% rcapstat 5 5
    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M    0K   689M     0K
376565   user1      3 6249M 6144M 6144M    0K    0K     0K     0K
376565   user1      3 6249M 6171M 6144M   27M    0K    27M     0K
376565   user1      3 6249M 6146M 6144M 4872K    0K  4816K     0K
376565   user1      3 6249M 6156M 6144M   12M    0K    12M     0K
376565   user1      3 6249M 6150M 6144M 5848K    0K  5816K     0K
376565   user1      3 6249M 6155M 6144M   11M    0K    11M     0K
376565   user1      3 6249M 6150M   10G   32K    0K    32K     0K
376565   user1      3 6249M 6214M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K

Inmitten des Zyklus wurde die Memory Cap des Projekts user1 von 6 GB auf 10 GB erhöht. Dieser Anstieg stoppt die Durchsetzung der Memory Cap und gestattet ein Anwachsen der Resident Set-Größe, begrenzt nur durch andere Prozesse und der Größe des reellen Speichers in dem Computer. Die Spalte rss könnte sich stabilisieren, um die Working Set-Größe (WSS) des Projekts widerzuspiegeln, in diesem Beispiel 6247M. Dies ist der geringste Memory Cap-Wert, der eine Ausführung der Projektprozesse ohne ständig auftretende Page-Faults gestattet.

Während die Memory Cap für user1 bei 6 s liegt, sinkt die RSS bei einem 5-Sekunden-Messintervall. E/A steigt an, während der rcapd Speicher der Arbeitslast auslagert. Kurz nach Abschluss des Auslagerns werden die Pages von der Arbeitslast, die diese Pages benötigt, wieder eingelesen. Dieser Zyklus wiederholt sich, bis die Memory Cap auf 10 GB angestiegen ist, etwa in der Mitte des Beispiels. Dann stabilisiert sich die RSS bei 6,1 GB. Da die RSS jetzt unter der Memory Cap liegt, tritt kein weiteres Paging mehr auf. Die aufgrund des Pagings auftretenden E/A-Vorgänge stoppen ebenfalls. Somit benötigt das Projekt 6,1 GB zur Ausführung der im Überwachungszeitraum angefallenen Arbeiten.

Lesen Sie hierzu auch die Manpages vmstat(1M) und iostat(1M).

Erstellen von Berichten zur Speicherauslastung und dem Schwellenwert für die Durchsetzung der Memory Cap

Mit der Option -g für den Befehl rcapstat erstellen Sie Berichte zu Folgendem:

• Die aktuelle Speicherauslastung als Prozentwert des im System installierten reellen Speichers

• Der mit rcapadm eingerichtete Schwellenwert für die Durchsetzung einer Memory Cap

Mit der Option -g wird am Ende des Berichts für jedes Intervall eine Zeile zur Speicherauslastung und Memory Cap-Durchsetzung gedruckt.

# rcapstat -g
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%

Kapitel 12 Einführung in Resource Pools

In diesem Kapitel werden die folgenden Themen behandelt:

• Resource Pools, die zur Partitionierung von Computerressourcen verwendet werden

• Dynamic Resource Pools (DRPs), mit denen die Ressourcenzuweisung von Resource Pools dynamisch eingestellt wird, um vorgegebene Systemziele zu erreichen

Ab Solaris-Release 10 11/06 sind Resource Pools und Dynamic Resource Pools Services der Solaris Service Management-Funktion (SMF). Jeder dieser Services wird separat aktiviert.

In diesem Kapitel werden folgende Themen behandelt:

• Einführung in Resource Pools

• Einführung in die Dynamic Resource Pools

• Allgemeine Informationen zum Aktivieren und Deaktivieren von Resource Pools und Dynamic Resource Pools

• In Zonen verwendete Resource Pools

• Verwenden von Pools

• Resource Pools-Framework

• Implementieren von Pools auf einem System

• project.pool – Attribut

• SPARC: Dynamic Reconfiguration-Vorgänge und Resource Pools

• Erstellen von Pool-Konfigurationen

• Direktes Bearbeiten der dynamischen Konfiguration

• poold – Übersicht

• Verwalten von Dynamic Resource Pools

• Konfigurationseinschränkungen und -ziele

• poold-Merkmale, die konfiguriert werden können

• So arbeitet die dynamische Ressourcenzuweisung

• Verwenden von poolstat zur Überwachung der Pools und der Ressourcenauslastung

• Mit Resource Pools verwendete Befehle

Verfahren zur Nutzung dieser Funktionen finden Sie in Kapitel 13Erstellen und Verwalten von Resource Pools (Vorgehen).

Neuerungen bei den Resource Pools und den Dynamic Resource Pools

Solaris 10: Resource Pools umfassen jetzt einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. Dynamic Resource Pools vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten.

Sie können jetzt den Befehl projmod verwenden, um das Attribut project.pool in der Datei /etc/project einzurichten.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Solaris 10 11/06: Resource Pools und Dynamic Resource Pools sind jetzt SMF-Services.

Einführung in Resource Pools

Resource Pools ermöglichen Ihnen, bestimmte Arbeitslasten voneinander zu trennen, so dass sich der Arbeitslast-Verbrauch bestimmter Ressourcen nicht überschneidet. Diese Ressourcenreservierung hilft dabei, eine vorhersagbare Performance bei Systemen mit gemischten Arbeitslasten zu erreichen.

Resource Pools bieten einen persistenten Mechanismus für die Konfiguration eines Prozessorsets (pset) und optional für die Zuweisung einer Scheduling-Klasse.

Abbildung 12–1 Resource Pool-Framework

Sie können sich einen Pool als eine besondere Art der Bindung von verschiedenen Ressourcensets vorstellen, die auf einem System zur Verfügung stehen. Sie können Pools erstellen, die verschiedene Arten von möglichen Ressourcenkombinationen darstellen:

Durch Gruppieren mehrerer Partitionen bieten Pools einen Handle, der bestimmten benannten Arbeitslasten zugewiesen werden kann. Jedem Projekteintrag in der Datei /etc/project kann ein bestimmter Pool zugewiesen sein. Dies wird mit dem Attribut project.pool angegeben.

Wenn Pools aktiviert sind, bilden ein Standard-Resource Pool und ein Standard-Prozessorset die Basiskonfiguration. Weitere benutzerdefinierte Pools und Prozessorsets können erstellt und der Konfiguration hinzugefügt werden. Eine CPU kann nur einem Prozessorset angehören. Benutzerdefinierte Pools und Prozessorsets können permanent gelöscht werden. Der Standard-Resource Pool und das Standard-Prozessorset können nicht permanent gelöscht werden.

Beim Standard-Resource Pool ist die Eigenschaft pool.default auf true gesetzt. Beim Standard-Prozessorset ist die Eigenschaft pset.default auf true gesetzt. Somit können der Standard-Resource Pool und das Standard-Prozessorset auch dann identifiziert werden, wenn ihre Namen geändert wurden.

Der Mechanismus der benutzerdefinierten Pools dient primär für große Computer mit mehr als vier CPUs. Jedoch können auch kleine Computer von dieser Funktion profitieren. Auf kleinen Computern können Sie Pools erstellen, die nicht-kritische Ressourcenpartitionen gemeinsam nutzen. Die Pools sind nur basierend auf kritischen Ressourcen getrennt.

Einführung in die Dynamic Resource Pools

Dynamic Resource Pools bieten einen Mechanismus zum Einstellen der Ressourcenzuweisungen jedes Pools als Reaktion auf Systemereignisse und Änderungen bei den Arbeitslasten der Anwendungen. DRPs vereinfachen und reduzieren die Anzahl der Entscheidungen, die ein Administrator treffen muss. Einstellungen werden automatisch vorgenommen, um die von einem Administrator festgelegten Leistungsziele des Systems einzuhalten. Änderungen an der Konfiguration werden protokolliert. Diese Funktionen werden primär über den Ressourcen-Controller poold ausgeführt, einem Systemdaemon, der immer dann aktiv sein sollte, wenn eine dynamische Ressourcenzuweisung erforderlich ist. poold ermittelt in regelmäßigen Abständen die Systemlast und stellt fest, ob eine Intervention erforderlich ist, damit das System die optimale Leistung hinsichtlich des Ressourcenverbrauchs beibehalten kann. Die poold-Konfiguration befindet sich in der libpool-Konfiguration. Weitere Informationen zu poold finden Sie in der Manpage poold(1M).

Allgemeine Informationen zum Aktivieren und Deaktivieren von Resource Pools und Dynamic Resource Pools

Wie Sie Resource Pools und Dynamic Resource Pools aktivieren bzw. deaktivieren, können Sie unter Aktivieren und Deaktivieren von Pools nachlesen.

In Zonen verwendete Resource Pools

Solaris 10 8/07: Alternativ zum Zuweisen einer Zone zu einem konfigurierten Resource Pool auf dem System können Sie den Befehl zonecfg eingeben, um einen temporären Pool zu erstellen, der nur über die Ausführung der Zone wirksam ist. Weitere Informationen finden Sie unter Solaris 10 8/07: dedicated-cpu-Ressource.

Auf einem System mit aktivierten Zonen kann eine nicht-globale Zone einem Resource Pool verbunden werden, obwohl der Pool nicht unbedingt exklusiv einer bestimmten Zone zugewiesen sein muss. Darüber hinaus können Sie einzelne Prozesse in nicht-globalen Zonen nicht mit dem Befehl poolbind aus der globalen Zone heraus an einen anderen Pool binden. Wie Sie eine nicht-globale Zone mit einem Pool verbinden, lesen Sie unter Konfigurieren, Prüfen und Übernehmen einer Zone.

Wenn Sie eine Scheduling-Klasse für einen Pool einrichten und dann eine nicht-globale Zone mit diesem Pool verbinden, verwendet die Zone standardmäßig diese Scheduling-Klasse.

Wenn Sie Dynamic Resource Pools verwenden, ist der Geltungsbereich einer ausführenden Instanz von poold auf die globale Zone beschränkt.

Das in einer nicht-globalen Zone ausgeführte Dienstprogramm poolstat zeigt nur Informationen zu dem Pool an, der mit der Zone verbunden ist. Wenn der Befehl pooladm ohne Argumente in einer nicht-globalen Zone ausgeführt wird, werden nur Informationen zu dem Pool angezeigt, der mit der Zone verbunden ist.

Weitere Informationen zu den Resource Pool-Befehlen finden Sie unter Mit Resource Pools verwendete Befehle.

Verwenden von Pools

Resource Pools stellen einen vielseitigen Mechanismus dar, der für viele verschiedene administrative Szenarios verwendet werden kann.

Stapelrechner-Server

Nutzen Sie die Funktionen von Pools, um einen Server in zwei Pools aufzuteilen. Ein Pool dient für Anmeldesitzungen und interaktives Arbeiten durch das Timesharing von Benutzern. Der andere Pool dient für Jobs, die über das Stapelsystem übermittelt werden.

Anwendungs- oder Datenbankserver

Partitionieren Sie die Ressourcen für interaktive Anwendungen gemäß den Anforderungen der Anwendungen.

Phasenweises Einschalten von Anwendungen

Bestimmen Sie die Erwartungshaltung von Benutzern.

Sie können zunächst einen Computer bereitstellen, der nur einen Teil der Services ausführt, die dieser Computer letztlich bereitstellen soll. Wenn die auf Reservierungen basierenden Mechanismen der Ressourcenverwaltung beim online schalten des Computers nicht hergestellt sind, könnten sich Probleme bei den Benutzern einstellen.

Beispielsweise optimiert der Fair Share Scheduler die CPU-Auslastung. Die Reaktionszeiten eines Computers, der nur eine Anwendung ausführt, können fälschlich als sehr schnell interpretiert werden. Benutzer erfahren diese Reaktionszeiten nicht mehr, wenn mehrere Anwendungen geladen werden. Mit separaten Pools für jede Anwendung können Sie einen Grenzwert für die Anzahl der CPUs einrichten, die einer Anwendung zur Verfügung stehen, bevor Sie alle Anwendungen bereitstellen.

Komplexe Timesharing-Server

Partitionieren Sie einen Server, der große Benutzerzahlen unterstützt. Die Serverpartitionierung bietet einen Isolationsmechanismus, der zu einer besser vorhersehbaren Reaktionszeit für den einzelnen Benutzer führt.

Durch das Aufteilen von Benutzern in Gruppen, die an separate Pools gebunden sind, und das Verwenden des Fair Share Schedulers (FSS) können Sie CPU-Zuweisungen so anpassen, dass sie bestimmte Benutzergruppen mit einer höheren Priorität bevorzugen. Diese Zuweisung kann auf der Benutzerrolle, auf dem Accounting Chargeback oder anderen basieren.

Arbeitslasten, die sich saisonal ändern

Mit Resource Pools können Sie Anpassungen für einen sich ändernden Bedarf vornehmen.

Vielleicht treten am Standort vorhersagbare Änderungen des Arbeitslastbedarfs über längere Zeiten ein, z. B. monatlich, vierteljährlich oder jährlich. In diesem Fall können Sie durch Aufrufen von pooladm von einem cron-Job aus zwischen mehreren Pool-Konfigurationen wechseln. (Lesen Sie dazu Resource Pools-Framework.)

Echtzeitanwendungen

Erstellen Sie mithilfe des RT-Scheduler und zugewiesenen Prozessorressourcen einen Echtzeit-Pool.

Systemauslastung

Setzen Sie von Ihnen eingerichteten Systemziele durch.

Mit dem automatisierten Pools-Daemon können Sie die verfügbaren Ressourcen identifizieren und Arbeitslasten überwachen, um festzustellen, wenn die von Ihnen angegebenen Ziele nicht mehr eingehalten werden. Der Daemon führt, sofern möglich, korrigierende Maßnahmen durch. Andernfalls kann der Zustand protokolliert werden.

Resource Pools-Framework

Die Konfigurationsdatei /etc/pooladm.conf enthält die Beschreibung der Static Pool-Konfiguration. Eine statische Konfiguration stellt dar, wie ein Administrator ein System unter Berücksichtigung der Resource Pools konfigurieren möchte. Es kann ein alternativer Dateiname verwendet werden.

Wenn die Service Management Facility (SMF) oder der Befehl pooladm - e zum Aktivieren des Resource Pools-Framework verwendet wird und die Datei /etc/pooladm.conf vorhanden ist, wird die in dieser Datei enthaltene Konfiguration für das System angewendet.

Der Kernel enthält Informationen zur Disposition von Ressourcen innerhalb des Resource Pools-Framework. Dies wird als dynamische Konfiguration bezeichnet. Sie repräsentiert die Resource Pools für ein bestimmtes System zu einem bestimmten Zeitpunkt. Die dynamische Konfiguration kann mit dem Befehl pooladm angezeigt werden. Beachten Sie, dass die Reihenfolge, in der die Eigenschaften für Pools und Ressourcensets angezeigt werden, variieren kann. Änderungen an der dynamischen Konfiguration können wie folgt vorgenommen werden:

• Indirekt, durch Anwenden einer statischen Konfigurationsdatei

• Direkt mit dem Befehl poolcfg und der Option -d

Es können mehrere Konfigurationsdateien für statische Pools vorhanden sein, die zu unterschiedlichen Zeiten aktiviert werden. Mit dem Befehl pooladm von einem cron-Job aus können Sie zwischen den verschiedenen Pool-Konfigurationen wechseln. Weitere Informationen zum Dienstprogramm cron finden Sie in der Manpage cron(1M).

In der Standardeinstellung ist das Resource Pools-Framework nicht aktiviert. Zum Erstellen oder Ändern einer dynamischen Konfiguration müssen Resource Pools aktiviert sein. Statische Konfigurationsdateien können auch dann mit dem Befehl poolcfg oder libpool bearbeitet werden, wenn das Resource Pools-Framework deaktiviert ist. Wenn keine Pools aktiv ist, können auch keine statischen Konfigurationsdateien erstellt werden. Weitere Informationen zur Konfigurationsdatei finden Sie unter Erstellen von Pool-Konfigurationen.

Die Befehle, die mit Resource Pools und dem Systemdaemon poold verwendet werden können, sind in den folgenden Manpages beschrieben:

• pooladm(1M)

• poolbind(1M)

• poolcfg(1M)

• poold(1M)

• poolstat(1M)

• libpool(3LIB)

/etc/pooladm.conf – Inhalt

Alle Resource Pool-Konfigurationen, einschließlich der dynamischen Konfiguration, können die folgenden Elemente enthalten.

system

Eigenschaften, die sich auf das Gesamtverhalten des Systems auswirken

pool

Eine Resource Pool-Definition

pset

Eine Prozessorset-Definition

cpu

Eine Prozessor-Definition

Alle diese Elemente besitzen Eigenschaften, die geändert werden können, um Status und Verhalten des Resource Pools-Frameworks zu manipulieren. Beispielsweise gibt die Pool-Eigenschaft pool.importance die relative Wichtigkeit eines bestimmten Pools an. Diese Eigenschaft wird zur Auflösung eines möglichen Konflikts um Ressourcen verwendet. Weitere Informationen finden Sie unter libpool(3LIB).

Eigenschaften von Pools

Die Funktion Pools unterstützt benannte, typisierte Eigenschaften, die für einen Pool, eine Ressource oder eine Komponente eingerichtet werden können. Administratoren können für verschiedene Pool-Elemente zusätzliche Eigenschaften speichern. Dabei wird der Namespace einer Eigenschaft ähnlich einem Projektattribut verwendet.

Beispielsweise kennzeichnet der folgende Kommentar, dass ein bestimmtes pset einer bestimmten Datatree-Datenbank zugewiesen wurde.

Datatree,pset.dbname=warehouse

Weitere Informationen zu Eigenschaftentypen finden Sie unter poold-Eigenschaften.

Eine Reihe von speziellen Eigenschaften ist für die interne Verwendung reserviert und kann nicht geändert oder entfernt werden. Weitere Informationen finden Sie in der Manpage libpool(3LIB).

Implementieren von Pools auf einem System

Benutzerdefinierte Pools können mithilfe einer der folgenden Methoden auf einem System implementiert werden.

• Beim Booten der Solaris-Software prüft das Skript init, ob die Datei /etc/pooladm.conf vorhanden ist. Wenn diese Datei gefunden wurde und Pools aktiviert sind, wird pooladm aufgerufen, um diese Konfigurationsdatei als aktive Pool-Konfiguration zu übernehmen. Das System erstellt eine dynamische Konfiguration, um die in der Datei /etc/pooladm.conf angeforderte Organisation widerzuspiegeln und partitioniert die Computerressourcen entsprechend.

• Wenn das Solaris-System ausgeführt wird, kann eine Pool-Konfiguration entweder aktiviert werden (falls sie noch nicht vorhanden ist) oder mit dem Befehl pooladm geändert werden. In der Standardeinstellung wirkt sich der Befehl pooladm auf die Datei /etc/pooladm.conf aus. Sie können jedoch einen alternativen Speicherort und Dateinamen angeben, um eine andere Datei zum Aktualisieren der Pool-Konfiguration zu verwenden.

Weitere Informationen zum Aktivieren und Deaktivieren von Resource Pools finden Sie unter Aktivieren und Deaktivieren von Pools. Pools können nicht deaktiviert werden, wenn benutzerdefinierte Pools oder Ressourcen verwendet werden.

Zum Konfigurieren von Resource Pools müssen Sie als Superuser angemeldet sein oder über das Process Management-Profil verfügen. Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil.

Der Ressource-Controller poold wird mit den Dynamic Resource Pools gestartet.

project.pool – Attribut

Das Attribut project.pool kann einem Projekteintrag in der Datei /etc/project hinzugefügt werden, um diesem Eintrag einem bestimmten Pool zuzuweisen. Neue Arbeiten, die im Rahmen eines Projekts gestartet werden, sind dann an diesen Pool gebunden. Weitere Informationen finden Sie in Kapitel 2Einführung in Projekte und Aufgaben.

Beispielsweise können Sie den Befehl projmod eingeben, um das Attribut project.pool für das Projekt sales in der Datei /etc/project einzurichten:

# projmod -a -K project.pool=mypool sales

SPARC: Dynamic Reconfiguration-Vorgänge und Resource Pools

Mit der Dynamic Reconfiguration (DR) können Sie Hardware bei laufendem System neu konfigurieren. Ein DR-Vorgang kann einen bestimmten Ressourcentyp vergrößern, verkleinern oder keine Auswirkungen zeigen. Da die DR verfügbaren Ressourcenmengen beeinflussen kann, müssen die Pools in diese Vorgänge mit einbezogen werden. Wenn ein DR-Vorgang initiiert wird, wird die Konfiguration vom Pools-Framework validiert.

Wenn der DR-Vorgang fortgesetzt werden kann, ohne dass die aktuelle Pool-Konfiguration ungültig wird, wird die private Konfigurationsdatei aktualisiert. Eine ungültige Konfiguration kann von den verfügbaren Ressourcen nicht unterstützt werden.

Wird die Pool-Konfiguration durch den DR-Vorgang ungültig, schlägt der Vorgang fehl und Sie werden über eine Nachricht an das Nachrichtenprotokoll informiert. Wenn Sie den Abschluss der Konfiguration erzwingen möchten, müssen Sie die DR-Durchsetzungsoption verwenden. Die Pool-Konfiguration wird dann so modifiziert, dass sie der neuen Ressourcenkonfiguration entspricht. Weitere Informationen zum DR-Prozess und der Durchsetzungsoption finden Sie im Benutzerhandbuch zur Dynamic Reconfiguration der Sun-Hardware.

Wenn Sie Dynamic Resource Pools verwenden, kann eine Partition die Resource Control poold bei aktivem Daemon verlassen. Weitere Informationen finden Sie unter Identifizieren eines Ressourcenmangels.

Erstellen von Pool-Konfigurationen

Die Konfigurationsdatei enthält eine Beschreibung der auf dem System zu erstellenden Pools. Die Datei beschreibt die Elemente, die manipuliert werden können.

• system

• pool

• pset

• cpu

Weitere Informationen zu den manipulierbaren Elementen finden Sie in der Manpage poolcfg(1M).

Wenn Pools aktiviert sind, können Sie auf zwei Arten eine strukturierte /etc/pooladm.conf-Datei erstellen.

• Geben Sie den Befehl pooladm mit der Option -s ein, um die Ressourcen auf den aktuellen Systemen zu erfassen und die Ergebnisse in eine Konfigurationsdatei zu schreiben.

  Dies ist die bevorzugte Methode. Hierbei werden alle aktiven Ressourcen und Komponenten auf dem System aufgezeichnet, die über die Pools-Funktionen manipuliert werden können. Zu diesen Ressourcen gehören auch bereits vorhandene Prozessorset-Konfigurationen. Anschließend können Sie die Konfiguration bearbeiten, um die Prozessorsets umzubenennen oder gegebenenfalls zusätzliche Pools zu erstellen.

• Geben Sie den Befehl poolcfg mit der Option-c und die Unterbefehle discover oder create system name ein, um eine neue Pool-Konfiguration zu erstellen.

  Diese Optionen wurden zur Abwärtskompatibilität mit früheren Versionen beibehalten.

Geben Sie den Befehl poolcfg oder libpool ein, um die Datei /etc/pooladm.conf zu bearbeiten. Bearbeiten Sie diese Dateien nicht direkt.

Direktes Bearbeiten der dynamischen Konfiguration

Sie können die CPU-Ressourcentypen in der dynamischen Konfiguration direkt bearbeiten, indem Sie den Befehl poolcfg mit der Option -d eingeben. Zur Übertragung von Ressourcen gibt es zwei Methoden.

• Sie können eine allgemeine Anfrage erstellen, um alle verfügbaren identifizierten Ressourcen zwischen Sets zu übertragen.

• Sie können Ressourcen mit bestimmten IDs an ein Ziel-Set übertragen. Beachten Sie, dass sich die System-IDs von Ressourcen ändern können, wenn die Ressourcenkonfiguration modifiziert oder ein System neu gebootet wird.

Ein Beispiel finden Sie unter Übertragen von Ressourcen.

Beachten Sie, dass die Übertragung einer Ressource eine Aktion vonpoold auslösen könnte. Weitere Informationen finden Sie unter poold – Übersicht.

poold – Übersicht

Der Ressourcen-Controller für Pools, poold, verwendet die Systemziele und überwachbare Statistiken, um die von Ihnen angegebenen Ziele bei der Systemleistung einzuhalten. Dieser Systemdaemon muss stets aktiv sein, wenn eine dynamische Zuordnung von Ressourcen erforderlich ist.

Der Ressourcen-Controller poold identifiziert verfügbare Ressourcen und überwacht dann Arbeitslasten, um festzustellen, wenn die Systemauslastungsziele nicht mehr eingehalten werden. poold berücksichtigt in diesem Fall alternative Konfigurationen und leitet Korrekturmaßnahmen ein. Wenn möglich, werden die Ressourcen neu konfiguriert, so dass die Ziele eingehalten werden können. Ist dies nicht möglich, protokolliert der Daemon, dass die benutzerdefinierten Ziele nicht mehr eingehalten werden können. Nach einer Neukonfiguration setzt der Daemon die Überwachung der Arbeitslastziele fort.

poold verwaltet ein Protokoll über den Verlauf der Entscheidungen. Mithilfe dieses Verlaufsprotokolls werden mögliche Neukonfigurationen eliminiert, die in der Vergangenheit zu keinen Verbesserungen geführt haben.

Beachten Sie, dass eine Neukonfigurationen auch asynchron ausgelöst werden kann, wenn die Arbeitslastziele oder die auf dem System verfügbaren Ressourcen geändert wurden.

Verwalten von Dynamic Resource Pools

Der DRP-Service wird von der Service Management Facility (SMF) unter der Servicebezeichnung svc:/system/pools/dynamic verwaltet.

Administrative Maßnahmen an diesem Service, z. B. Aktivieren, Deaktivieren oder Anfordern eines Neustart können mithilfe des Befehlssvcadm vorgenommen werden. Der Status des Services kann mithilfe des Befehls svcs abgefragt werden. Weitere Informationen finden Sie in den Manpages svcs(1) und svcadm(1M).

Die SMF-Schnittstelle ist die bevorzugte Methode zur Steuerung der DRP, aus Gründen der Abwärtskompatibilität können aber auch die folgenden Methoden verwendet werden.

• Wenn keine dynamische Ressourcenzuordnung erforderlich ist, kann poold mit dem Signal SIGQUIT oder SIGTERM gestoppt werden. Jedes dieser Signale führt zum ordnungsgemäßen Beenden von poold.

• Obwohl poold Änderungen an den Ressourcen- oder Pool-Konfigurationen automatisch erfasst, können Sie mithilfe des Signals SIGHUP eine Neukonfiguration erzwingen.

Konfigurationseinschränkungen und -ziele

Wenn Sie Änderungen an einer Konfiguration vornehmen, hält sich poold an Ihre Anweisungen. Sie geben diese Anweisungen als Einschränkungen und Ziele ein. poold ermittelt anhand Ihrer Angaben den relativen Wert verschiedener Konfigurationsmöglichkeiten in Relation zur vorhandenen Konfiguration. poold ändert dann die Ressourcenzuweisungen der aktuellen Konfiguration, und erstellt so neue Konfigurationen, die als Kandidaten zur Übernahme gelten.

Konfigurationseinschränkungen

Einschränkungen reduzieren die Anzahl möglicher Konfigurationen, indem sie einige potentielle Änderungen eliminieren, die an einer Konfiguration vorgenommen werden können. Die folgenden Einschränkungen stehen zur Verfügung. Sie werden in der libpool-Konfiguration angegeben.

• Die maximalen und minimalen CPU-Zuweisungen

• Fixierte Komponenten, die nicht aus einem Set verschoben werden können

Weitere Informationen zu den Pools-Eigenschaften finden Sie in der Manpage libpool(3LIB) und unter Eigenschaften von Pools.

pset.min-Eigenschaft und pset.max-Eigenschafteneinschränkungen

Diese beiden Eigenschaften legen Grenzwerte (Maximum und Minimum) für die Anzahl der Prozessoren fest, die einem Prozessorset zugewiesen werden können. Weitere·Informationen zu diesen Eigenschaften finden Sie in Tabelle 12–1.

Im Rahmen dieser Einschränkungen können die Ressourcen einer Ressourcenpartition beliebigen anderen Ressourcenpartitionen in der gleichen Solaris-Instanz zugeordnet werden. Der Zugriff auf diese Ressourcen erfolgt durch das Binden an einen Pool, der dem Ressourcenset zugewiesen ist. Das Binden erfolgt entweder bei der Anmeldung oder manuell durch einen Administrator, der über die Berechtigung PRIV_SYS_RES_CONFIG verfügt.

cpu.pinned-Eigenschafteneinschränkung

Die Eigenschaft cpu-pinned kennzeichnet, dass eine bestimmte CPU nicht durch DRP aus dem aktuellen Prozessorset verschoben werden darf. Sie können diese libpool-Eigenschaft einrichten, um die Cache-Auslastung für eine bestimmte Anwendung zu maximieren, die innerhalb eines Prozessorsets ausgeführt wird.

Weitere Informationen zu dieser Eigenschaft finden Sie in Tabelle 12–1.

pool.importance-Eigenschafteneinschränkung

Die Eigenschaft pool.importance beschreibt die relative Wichtigkeit eines Pools gemäß der Definition durch den Administrator.

Konfigurationsziele

Ziele werden ähnlich wie Einschränkungen angegeben. Das vollständige Ziel-Set ist in Tabelle 12–1 dokumentiert.

Es gibt zwei Kategorien von Zielen.

Arbeitslastabhängig

Ein arbeitslastabhängiges Ziel ändert sich mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das Ziel utilization. Der Wert für die Auslastung (utilization) eines Ressourcensets ändert sich je nach der im Set aktiven Arbeitslast.

Arbeitslastunabhängig

Ein arbeitslastabhängiges Ziel ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird. Ein Beispiel wäre das CPU-Ziel locality. Die ausgewertete Messung der Lokalität (locality) eines Ressourcensets ändert sich nicht mit der Arbeitslast, die auf einem System ausgeführt wird.

Sie können drei Arten von Zielen definieren.

Ziele werden in den Eigenschaftenstrings der libpool-Konfiguration gespeichert. Die Eigenschaftennamen lauten wie folgt:

• system.poold.objectives

• pset.poold.objectives

Ziele haben die folgende Syntax:

• objectives = objective [; objective]*

• objective = [n:] keyword [op] [value]

Alle Ziele können ein optionales Präfix für die Wichtigkeit aufnehmen. Diese Wichtigkeit dient als ein Multiplikator für das Ziel und erhöht somit die Bedeutung des Beitrags zur Auswertung der Zielfunktion. Der Bereich erstreckt sich von 0 bis INT64_MAX (9223372036854775807). Wenn kein Wert angegeben ist, lautet der Standardwert für die Wichtigkeit 1.

Einige Elementtypen unterstützen mehrere Zieltypen. Ein Beispiel hierfür ist pset. Für diese Elemente können Sie mehrere Zieltypen angeben. Außerdem können Sie mehrere Auslastungsziele für ein einzelnespset-Element angeben.

Anwendungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.

wt-load-Ziel

Das Ziel wt-load begünstigt Konfigurationen, bei denen die Ressourcenzuordnungen mit den Ressourcenauslastungen übereinstimmen. Wenn dieses Ziel aktiv ist, erhält ein Ressourcenset, das mehr Ressourcen verwendet, mehr Ressourcen. wt-load bedeutet weighted load (gewichtete Last).

Verwenden Sie dieses Ziel, wenn Sie mit den Einschränkungen zufrieden sind, die Sie mithilfe der Minimum- und Maximum-Eigenschaften eingerichtet haben, und wenn der Daemon die Ressourcen innerhalb dieser Einschränkungen frei manipulieren soll.

locality-Ziel

Das Ziel locality wirkt sich auf den Einfluss aus, den die Lokalität (über die Daten der Locality Group (lgroup gemessen) auf die ausgewählte Konfiguration hat. Eine alternative Definition für Lokalität ist Latenz. Eine lgroup beschreibt CPU- und Speicherressourcen. Die lgroup wird vom Solaris-System verwendet, um den zeitlichen Abstand zwischen Ressourcen zu ermitteln. Weitere Informationen zur Locality Group-Abstraktion finden Sie unter Locality Groups Overview in Programming Interfaces Guide.

Dieses Ziel kann einen der folgenden drei Werte annehmen:

tight

Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality maximiert wird.

loose

Bei dieser Einstellung werden Konfigurationen bevorzugt, bei denen die Resource Locality minimiert wird.

none

Bei dieser Einstellung hat die Resource Locality keinen Einfluss auf die bevorzugte Konfiguration. Dies ist der Standardwert für das Ziel locality.

Im Allgemeinen sollte das Ziel locality auf tight gesetzt sein. Um die Speicherbandbreite zu maximieren bzw. den Einfluss von DR-Vorgängen auf ein Ressourcenset zu minimieren, können Sie dieses Ziel auf loose setzen oder die Standardeinstellung von none beibehalten.

utilization-Ziel

Das Ziel utilization begünstigt Konfigurationen, die den Partitionen Ressourcen zuordnen, die das angegebene Auslastungsziel nicht erreichen.

Dieses Ziel wird mithilfe von Operatoren und Werten angegeben. Folgende Operatoren stehen zur Verfügung:

<

Der „Kleiner-als“-Operator gekennzeichnet, dass der angegebene Wert den maximalen Zielwert darstellt.

>

Der „Größer-als“-Operator gekennzeichnet, dass der angegebene Wert den minimalen Zielwert darstellt.

~

Der „Circa“-Operator kennzeichnet, dass der angegebene Wert ein Zielwert ist, für den eine gewisse Schwankung akzeptabel ist.

Bei einem pset kann nur ein Auslastungsziel für jeden Operatortyp festgelegt werden.

• Wenn der Operator ~ festgelegt ist, können die Operatoren < und > nicht verwendet werden.

• Wenn die Operatoren < und > festgelegt sind, kann der Operator ~ nicht verwendet werden. Die Einstellungen des <-Operators und des >-Operators schließen sich gegenseitig nicht aus.

Sie können einen <- und einen >-Operator zusammen verwenden, um einen Bereich zu erstellen. Die Werte werden validiert, um sicherzustellen, dass sie einander nicht überschneiden.

Beispiel für Konfigurationsziele

In dem folgenden Beispiel wird poold zum Auswerten der folgenden Eigenschaften für das pset verwendet:

• Die utilization muss zwischen 30 % und 80 % gehalten werden.

• Die locality muss für jedes Prozessorset maximiert sein.

• Die Ziele müssen die Standardwichtigkeit von 1 annehmen.

Beispiel 12–1 poold-Beispielziel

pset.poold.objectives "utilization > 30; utilization < 80; locality tight"

Weitere Nutzungsbeispiele finden Sie unter So definieren Sie Konfigurationsziele.

poold-Eigenschaften

Es gibt vier Eigenschaftenkategorien:

• Konfiguration

• Einschränkung

• Ziel

• Zielparameter

poold-Merkmale, die konfiguriert werden können

Die folgenden Aspekte des Daemon-Verhaltens können konfiguriert werden.

• Überwachungsintervall

• Protokollierungsebene

• Speicherort des Protokolls

Diese Optionen werden in der Pool-Konfiguration angegeben. Sie können die Protokollierungsebene auch mit dem Befehl poold von der Befehlszeile aus ändern.

poold-Überwachungsintervall

Mit dem Eigenschaftennamen system.poold.monitor-interval geben Sie einen Wert in Millisekunden an.

poold-Protokollierungsinformationen

Mit der Protokollierung werden drei Informationskategorien bereitgestellt. In den Protokollen werden die folgenden Kategorien aufgeführt:

• Konfiguration

• Überwachung

• Optimierung

Mit dem Eigenschaftennamen system.poold.log-level geben Sie die Protokollierungsparameter an. Wenn diese Eigenschaft nicht angegeben ist, lautet die standardmäßige Protokollierungsebene NOTICE. Die Parameterebenen sind hierarchisch angeordnet. Bei der Protokollierungsebene DEBUG protokolliert poold alle definierten Meldungen. Die Ebene INFO stellt den meisten Administratoren alle wichtigen Informationen zur Verfügung.

Sie können den Befehl poold mit der Option -l an der Befehlszeile eingeben und einen Parameter hinzufügen, um die Ebene der erzeugten Protokollierungsinformationen festzulegen.

Die folgenden Parameter sind verfügbar:

• ALERT

• CRIT

• ERR

• WARNING

• NOTICE

• INFO

• DEBUG

Die Parameterebenen entsprechend direkt ihren syslog-Äquivalenten. Weitere Informationen zur Verwendung von syslog finden Sie unter Speicherort des Protokolls.

Informationen zum Konfigurieren der poold--Protokollierung finden Sie unter So richten Sie die Protokollierungsebene für poold ein.

Konfiguration der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

ALERT

Probleme beim Zugriff auf die libpool-Konfiguration oder ein anderer fundamentaler und unerwarteter Fehler bei der libpool-Funktion. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

CRIT

Probleme aufgrund unerwarteter Fehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

ERR

Probleme mit benutzerdefinierten Parametern, die Vorgänge steuern, zum Beispiel nicht auflösbare, widersprüchliche Auslastungsziele für ein Ressourcenset. Erfordert administrative Maßnahmen zur Berichtigung der Ziele. poold versucht Korrekturmaßnahmen einzuleiten, indem widersprüchlichen Ziele ignoriert werden, aber bestimmte Fehler führen dazu, dass der Daemon beendet wird.

WARNING

Warnungen hinsichtlich der Einstellungen von Konfigurationsparametern, die zwar technisch korrekt, für die vorgegebene Ausführungsumgebung jedoch ungeeignet sind. Ein Beispiel ist das Fixieren aller CPU-Ressourcen, so dass poold CPU-Ressourcen nicht zwischen Prozessorsets verschieben kann.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die zum Debuggen der Konfigurationsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Überwachen der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

CRIT

Probleme aufgrund unerwarteter schwerwiegender Überwachungsfehler. Der Daemon wird beendet und es sind sofortige administrative Maßnahmen erforderlich.

ERR

Probleme aufgrund eines unerwarteten Überwachungsfehlers. Es sind eventuell Maßnahmen des Administrators erforderlich.

NOTICE

Meldungen über Wechsel der Resource Control-Region.

INFO

Meldungen zu den Ressourcen-Auslastungsstatistiken.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Überwachungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Optimieren der Informationsprotokollierung

Die folgenden Meldungsarten können erzeugt werden:

WARNING

Es können Meldungen zu Problemen angezeigt werden, um optimale Entscheidungen zu treffen. Beispiele hierfür sind Ressourcensets, die durch vorgegebene Mindest- und Höchstwerte oder die Anzahl der fixierten Komponenten zu stark eingeschränkt sind.

Es können Meldungen bei Problemen angezeigt werden, wenn eine optimale Neuzuordnung aufgrund unvorhersehbarer Einschränkungen nicht durchgeführt werden kann. Beispiele hierfür sind das Entfernen des letzten Prozessors von einem Prozessorset, das einen gebundenen Ressourcenverbraucher enthält.

NOTICE

Es können Meldungen über nutzbare Konfigurationen oder Konfigurationen angezeigt werden, die durch das Überschreiben des Entscheidungsverlaufs nicht implementiert werden können.

INFO

Es können Meldungen über mögliche alternative Konfigurationen angezeigt werden.

DEBUG

Es können Meldungen mit ausführlichen Informationen angezeigt werden, die beim Debuggen der Optimierungsverarbeitung erforderlich sind. Diese Informationen werden von Administratoren nicht immer genutzt.

Speicherort des Protokolls

Mit der Eigenschaft system.poold.log-location können Sie den Speicherort der protokollierten Ausgabe von poold angeben. Sie können den Speicherort desSYSLOG für die poold-Ausgabe angeben (lesen Sie dazu syslog(3C)).

Wenn diese Eigenschaft nicht gesetzt ist, lautet der standardmäßige Speicherort der protokollierten Ausgabe von poold /var/log/pool/poold.

Erfolgt der Aufruf von poold von der Befehlszeile, wird diese Eigenschaft nicht verwendet. Protokolleinträge werden auf dem aufrufenden Terminal in stderr geschrieben.

Protokollmanagement mit logadm

Wenn poold aktiv ist, enthält die Datei logadm.conf einen Eintrag zur Verwaltung der Standarddatei /var/log/pool/poold. Dieser Eintrag lautet:

/var/log/pool/poold -N -s 512k

Weitere Informationen finden Sie in den Manpages logadm(1M) und logadm.conf(4).

So arbeitet die dynamische Ressourcenzuweisung

In diesem Abschnitt werden der Prozess und die Faktoren beschrieben, die poold zum dynamischen Zuweisen von Ressourcen verwendet.

Allgemeine Informationen zu verfügbaren Ressourcen

Verfügbaren Ressourcen sind alle Ressourcen, die innerhalb des Geltungsbereichs des poold-Prozesses zur Nutzung zur Verfügung stehen. Der Geltungsbereich einer Steuerung ist maximal eine einzelne Solaris-Instanz.

Auf einem System mit aktivierten Zonen ist der Geltungsbereich der ausgeführten poold-Instanz auf die globale Zone beschränkt.

Ermitteln der verfügbaren Ressourcen

Resource Pools umfassen alle Systemressourcen, die für den Verbrauch durch Anwendungen zur Verfügung stehen.

Bei einer ausgeführten Solaris-Instanz muss ein Ressourcentyp, z. B. eine CPU, einer einzelnen Partition zugeordnet sein. Es können eine oder mehrere Partitionen für jeden Ressourcentyp vorhanden sein. Jede Partition enthält ein einmaliges Ressourcenset.

Beispielsweise kann ein Computer mit vier CPUs und zwei Prozessorsets das folgende Setup haben:

pset 0: 0 1

pset 1: 2 3

dabei stellen 0, 1, 2 und 3 hinter dem Doppelpunkt die CPU-IDs dar. Beachten Sie, dass die zwei Prozessorsets alle vier CPUs aufnehmen.

Der gleiche Computer kann das folgende Setup nicht aufweisen:

pset 0: 0 1

pset 1: 1 2 3

Dieses Setup ist nicht möglich, da CPU 1 nur in einem pset erscheinen kann.

Ressourcen sind von anderen Partitionen als der, zu der sie gehören, nicht zugänglich.

Zum Erfassen der verfügbaren Ressourcen fragt poold die aktive Pool-Konfiguration ab, um Partitionen zu finden. Alle Ressourcen in allen Partitionen werden summiert, um die insgesamt zur Verfügung stehenden Ressourcen für jeden gesteuerten Ressourcentyp zu ermitteln.

Diese erfassten Ressourcen verwendet poold als Basiszahl für Berechnungen. Jedoch gelten bestimmte Einschränkungen für diese Zahl, die die Flexibilität von poold beim Erstellen der Zuweisungen beschränken. Informationen zu den verfügbaren Einschränkungen finden Sie unter Konfigurationseinschränkungen.

Identifizieren eines Ressourcenmangels

Der Steuerungsbereich von poold ist definiert als das verfügbare Ressourcenset, für das poold die primäre Verantwortung für effiziente Partitionierung und Verwaltung übernimmt. Es gibt jedoch noch weitere Mechanismen, die Ressourcen innerhalb dieses Steuerungsbereichs manipulieren können und sich so auf eine Konfiguration auswirken. Wenn eine Partition während poold aktiv ist, aus dem Steuerungsbereich entfernt wird, versucht poold die Steuerung durch eine vorsichtige Manipulation der verfügbaren Ressourcen wiederzustellen. Wenn poold keine zusätzlichen Ressourcen innerhalb des Geltungsbereichs lokalisieren kann, protokolliert der Daemon Informationen über den Ressourcenmangel.

Ermitteln der Ressourcenauslastung

poold wendet im Allgemeinen die meiste Zeit damit auf, die Ressourcenauslastung innerhalb des Steuerungsbereichs zu beobachten. Durch diese Überwachung wird sichergestellt, dass die arbeitslastabhängigen Ziele erreicht werden.

Beispielsweise werden bei Prozessorsets alle Messungen über alle Prozessoren in einem Set durchgeführt. Die Ressourcenauslastung zeigt den Anteil der Zeit, den die Ressource über das Messintervall genutzt wurde. Die Ressourcenauslastung wird als ein Prozentwert zwischen 0 und 100 angezeigt.

Identifizieren von Steuerungsverletzungen

Die unter Konfigurationseinschränkungen und -ziele beschriebenen Direktiven dienen zum Erfassen einer bevorstehenden Situation, bei der das System die vorgegebenen Ziele nicht mehr erreicht. Diese Ziele stehen in einem direkten Zusammenhang mit der Arbeitslast.

Eine Partition, die benutzerdefinierte Ziele nicht erreicht, wird als eine Steuerungsverletzung bezeichnet. Es gibt zwei Arten von Steuerungsverletzungen: synchrone und asynchrone.

• Eine synchrone Ziel-Verletzung wird vom Daemon während der Arbeitslastüberwachung festgestellt.

• Eine asynchrone Ziel-Verletzung erfolgt unabhängig von der Überwachungsaktion des Daemons.

Die folgenden Ereignisse können asynchrone Ziel-Verletzungen auslösen:

• Ressourcen, die einem Steuerungsbereich hinzugefügt oder daraus entfernt werden.

• Der Steuerungsbereich wird neu konfiguriert.

• Der Ressourcen-Controller poold wird neu gestartet.

Die Beiträge von Zielen, die in keiner Beziehung zur Arbeitslast stehen, werden zwischen einzelnen Auswertungen von Zielen als gleichbleibend konstant betrachtet. Ziele, die in keiner Beziehung zur Arbeitslast stehen, werden nur dann neu ausgewertet, wenn aufgrund einer asynchronen Verletzung eine neue Auswertung ausgelöst wird.

Feststellen einer geeigneten Korrekturmaßnahme

Stellt der Ressourcen-Controller fest, dass es einem Ressourcenverbraucher an Ressourcen mangelt, werden zunächst die Ressourcen erhöht, um die Leistung zu verbessern.

Alternative Konfigurationen, mit denen sich die in der Konfiguration für den Steuerungsbereich angegebenen Ziele erreichen lassen, werden geprüft und ausgewertet.

Dieser Prozess wird über die Zeit weiter angepasst, da die Ergebnisse der Ressourcenänderungen überwacht und jede Ressourcenpartition auf deren Reaktionsfähigkeit geprüft wird. Mithilfe des Entscheidungsverlaufs können Neukonfigurationen eliminiert werden, die in der Vergangenheit zu keinen Verbesserungen geführt haben. Andere Informationen, z. B. Prozessnamen und Mengen, werden zur weiteren Auswertung der Verlaufsdaten herangezogen.

Wenn der Daemon keine Korrekturmaßnahmen ausführen kann, wird der Zustand protokolliert. Weitere Informationen finden Sie unter poold-Protokollierungsinformationen.

Verwenden von poolstat zur Überwachung der Pools und der Ressourcenauslastung

Mit dem Dienstprogramm poolstat wird die Ressourcenauslastung überwacht, wenn Pools auf dem System aktiviert sind. Dieses Dienstprogramm prüft wiederholt alle aktiven Pools auf dem System und zeichnet Statistiken basierend auf dem ausgewählten Ausgabemodus auf. Mithilfe der poolstat-Statistiken können Sie feststellen, welche Ressourcenpartitionen stark ausgelastet sind. Sie können diese Statistiken analysieren, um Entscheidungen über neue Ressourcenzuordnungen zu treffen, wenn das System mehr Ressourcen bereitstellen muss.

Das Dienstprogramm poolstat enthält Optionen, mit denen bestimmte Pools untersucht und Ressourcenset-spezifische Statistiken erstellt werden können.

Wenn Zonen auf dem System implementiert sind und Sie poolstat in einer nicht-globalen Zone verwenden, werden Informationen zu den Ressourcen angezeigt, die dem Pool der Zone zugeordnet sind.

Weitere Informationen zum Dienstprogramm poolstat finden Sie in der Manpage poolstat(1M) poolstat-Aufgaben- und Nutzungsinformationen finden Sie unter Verwenden von poolstat zum Erstellen von Statistiken über Pool-bezogene Ressourcen.

poolstat-Ausgabe

In der Standardeinstellung umfass die Ausgabe von poolstat eine Überschrift und eine Zeile für jeden Pool. Eine Pool-Zeile beginnt mit der Pool-ID und dem Namen des Pools, gefolgt von einer Spalte mit statistischen Daten zu dem Prozessorset, das an den Pool angehängt ist. Ressourcensets, die an mehrere Pools angehängt sind, werden mehrmals aufgeführt, jeweils einmal für jeden Pool.

Die Spaltenüberschriften lauten wie folgt:

id

Pool-ID.

pool

Pool-Name.

rid

Ressourcenset-ID.

rset

Ressourcenset-Name.

type

Ressourcenset-Typ.

min

Minimale Ressourcenset-Größe.

max

Maximale Ressourcenset-Größe.

size

Aktuelle Ressourcenset-Größe.

used

Eine Messung, wie viel des Ressourcensets derzeit verwendet wird.

Diese Nutzung wird als Prozentsatz der Ressourcensetauslastung multipliziert mit der Größe des Ressourcensets berechnet. Falls ein Ressourcenset während des letzten Messintervalls neu konfiguriert wurde, wird dieser Wert nicht aufgeführt. Ein nicht aufgeführter Wert erscheint als Strich (-).

load

Die absolute Darstellung der Last, die auf dem Ressourcenset liegt.

Weitere Informationen zu dieser Eigenschaft finden Sie in der Manpage libpool(3LIB).

Die Ausgabe von poolstat kann wie folgt angepasst werden:

• Die Reihenfolge der Spalten

• Die angezeigten Überschriften

Einstellen des Intervalls der poolstat-Ausführung

Sie können Einstellen, wie häufig die von poolstat durchgeführten Vorgänge ausgeführt werden. Sie können das Messintervall für den Bericht und die Häufigkeit festlegen, wie oft Statistiken wiederholt werden:

Intervall

Sie können die Intervalle für die regelmäßig von poolstat ausgeführten Vorgänge einstellen. Alle Intervalle werden in Sekunden angegeben.

Zählung

Legt die Häufigkeit fest, wie oft Statistiken wiederholt werden. Standardmäßig erfasst poolstat Statistiken nur einmal.

Wenn Intervall und Zählung nicht angegeben sind, werden die Statistiken nur einmal erfasst. Wenn Intervall angegeben und Zählung nicht angegeben ist, werden die Statistiken unendlich erfasst.

Mit Resource Pools verwendete Befehle

Die in der folgenden Tabelle aufgeführten Befehle stellen die primäre administrative Schnittstelle zu den Pools dar. Informationen zum Verwenden dieser Befehle auf einem System mit aktivierten Zonen finden Sie unter In Zonen verwendete Resource Pools.

Eine Bibliothek-API wird für libpool bereitgestellt (lesen Sie dazu die Manpage libpool(3LIB) Die Bibliothek kann von Programmen zur Bearbeitung von Pool-Konfigurationen verwendet werden.

Kapitel 13 Erstellen und Verwalten von Resource Pools (Vorgehen)

In diesem Kapitel wird das Einrichten und Verwalten von Resource Pools auf einem System beschrieben.

Eine Einführung in das Thema der Resource Pools finden Sie in Kapitel 12Einführung in Resource Pools.

Verwalten von Dynamic Resource Pools (Übersicht der Schritte)

Aktivieren und Deaktivieren von Pools

Ab Solaris-Release 10 11/06 können Sie die Resource Pools- und Dynamic Resource Pools-Services auf dem System mit dem Befehl svcadm aktivieren bzw. deaktivieren. Eine Beschreibung dieses Befehls finden Sie in der Manpage svcadm(1M).

Mit dem in der Manpage pooladm(1M) ausführlich beschriebenen Befehl pooladm können Sie:

• Pools aktivieren, so dass sie bearbeitet werden können

• Pools deaktivieren, so dass sie nicht bearbeitet werden können

Wenn ein System aufgerüstet wird und das Resource Pools-Framework aktiviert und die Datei /etc/pooladm.conf vorhanden ist, wird der Pools-Service aktiviert und die in der Datei enthaltene Konfiguration für das System übernommen.

Solaris 10 11/06 und höher: So aktivieren Sie die Resource Pools mit dem Befehl svcadm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Aktivieren Sie den Resource Pools-Service.

   # svcadm enable system/pools:default

Solaris 10 11/06 und höher: So deaktivieren Sie die Resource Pools mit dem Befehl svcadm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Deaktivieren Sie den Resource Pools-Service.

   # svcadm disable system/pools:default

Solaris 10 11/06 und höher: So aktivieren Sie die Dynamic Resource Pools mit dem Befehl svcadm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter Configuring RBAC (Task Map) in System Administration Guide: Security Services „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Aktivieren Sie den Dynamic Resource Pools-Service.

   # svcadm enable system/pools/dynamic:default

Beispiel 13–1 Abhängigkeit des Dynamic Resource Pools-Services vom Resource Pools-Service

In diesem Beispiel wird gezeigt, dass Sie zunächst die Resource Pools aktivieren müssen, wenn Sie DRP ausführen möchten.

Es besteht eine Abhängigkeit zwischen Resource Pools und Dynamic Resource Pools. DRP ist jetzt ein von den Resource Pools abhängiger Service. DRP kann unabhängig vom Resource Pools-Service aktiviert und deaktiviert werden.

Im Folgenden wird gezeigt, dass sowohl Resource Pools als auch Dynamic Resource Pools derzeit deaktiviert sind:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:32:26 svc:/system/pools/dynamic:default
disabled       10:32:26 svc:/system/pools:default

Aktivieren Sie die Dynamic Resource Pools:

# svcadm enable svc:/system/pools/dynamic:default
# svcs -a | grep pool
disabled       10:39:00 svc:/system/pools:default
offline        10:39:12 svc:/system/pools/dynamic:default

Der DRP-Service ist noch immer offline.

Geben Sie die Option -x des Befehls svcs ein, um festzustellen, warum der DRP-Service offline ist:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:39:00 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:39:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Aktivieren Sie den Resource Pools-Service, so dass der DRP-Service ausgeführt werden kann:

# svcadm enable svc:/system/pools:default

Wenn der Befehl svcs *pool* verwendet wird, zeigt das System Folgendes an:

# svcs *pool*
STATE          STIME    FMRI
online         10:40:27 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Beispiel 13–2 Auswirkungen auf Dynamic Resource Pools, wenn der Resource Pools-Service deaktiviert ist

Wenn beide Services online sind und Sie den Resource Pools-Service deaktivieren:

# svcadm disable svc:/system/pools:default 

Wenn der Befehl svcs *pool* verwendet wird, zeigt das System Folgendes an:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default
# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Schließlich wird der DRP-Service offline geschaltet, weil der Resource Pools-Service deaktiviert wurde:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
offline        10:41:12 svc:/system/pools/dynamic:default

Ermitteln Sie, warum der DRP-Service offline ist:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:41:05 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:41:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Resource Pools müssen gestartet sein, damit DRP ausgeführt werden können. Beispielsweise können Resource Pools mit dem Befehl pooladm und der Option -e gestartet werden:

# pooladm -e

Jetzt zeigt der Befehl svcs *pool* Folgendes an:

# svcs *pool*
STATE          STIME    FMRI
online         10:42:23 svc:/system/pools:default
online         10:42:24 svc:/system/pools/dynamic:default

Solaris 10 11/06 und höher: So deaktivieren Sie den Dynamic Resource Pools-Service mit dem Befehl svcadm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Deaktivieren Sie den Dynamic Resource Pools-Service.

   # svcadm disable system/pools/dynamic:default

So aktivieren Sie Resource Pools mit dem Befehl pooladm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Aktivieren Sie die Pools.

   # pooladm -e

So deaktivieren Sie Resource Pools mit dem Befehl pooladm

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Deaktivieren Sie die Pools.

   # pooladm -d

Konfigurieren von Pools

So erstellen Sie eine statische Konfiguration

Geben Sie die Option -s für /usr/sbin/pooladm ein, um eine statische Konfigurationsdatei zu erstellen, die der aktuellen dynamischen Konfiguration entspricht. Sofern kein anderer Dateiname angegeben wurde, wird der standardmäßige Speicherort /etc/pooladm.conf verwendet.

Übernehmen Sie die Konfiguration mit dem Befehl pooladm und der Option -c. Dann geben Sie den Befehl pooladm mit der Option -s ein, um die statische Konfiguration so zu aktualisieren, dass sie dem Status der dynamischen Konfiguration entspricht.

Das neue Funktionsmerkmal pooladm -s sollte dem älteren Befehl poolcfg -c discover zum Erstellen einer neuen Konfiguration, die der dynamischen Konfiguration entspricht, vorgezogen werden.

Bevor Sie beginnen

Aktivieren Sie die Pools auf dem System.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Aktualisieren Sie die statische Konfigurationsdatei so, dass sie der aktuellen dynamischen Konfiguration entspricht.

   # pooladm -s

3. Zeigen Sie den Inhalt der Konfigurationsdatei in lesbarer Form an.

   Beachten Sie, dass die Konfiguration vom System erstellte Standardelemente enthält.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line

4. Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.

   # pooladm -c

5. (Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:

   # pooladm -s /tmp/backup

So modifizieren Sie eine Konfiguration

Um die Konfiguration zu verbessern, erstellen Sie ein Prozessorset namens pset_batch und einen Pool namens pool_batch. Dann verbinden Sie Pool und Prozessorset über eine Zuordnung.

Denken Sie daran, dass Sie Unterbefehlsargumente mit Leerzeichen in Anführungszeichen stellen müssen.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Erstellen Sie das Prozessorset pset_batch.

   # poolcfg -c 'create pset pset_batch (uint pset.min = 2; uint pset.max = 10)'

3. Erstellen Sie den Pool pool_batch.

   # poolcfg -c 'create pool pool_batch'

4. Verbinden Sie Pool und Prozessorset über eine Zuordnung.

   # poolcfg -c 'associate pool pool_batch (pset pset_batch)'

5. Zeigen Sie die bearbeitete Konfiguration an.

   # poolcfg -c info system tester string system.comment kernel state int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment pset pset_batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.

   # pooladm -c

7. (Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:

   # pooladm -s /tmp/backup

So ordnen Sie einen Pool einer Scheduling-Klasse zu

Sie können einen Pool einer Scheduling-Klasse zuordnen, so dass alle an den Pool gebundenen Prozesse diesen Scheduler verwenden. Dazu setzen Sie die Eigenschaft pool.scheduler auf den Namen des Schedulers. Im folgenden Beispiel wird der Pool pool_batch dem Fair Share Scheduler (FSS) zugeordnet.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

2. Bearbeiten Sie den Pool pool_batch, um ihm dem FSS zuzuordnen.

   # poolcfg -c 'modify pool pool_batch (string pool.scheduler="FSS")'

3. Zeigen Sie die bearbeitete Konfiguration an.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

4. Übernehmen Sie die Konfiguration unter /etc/pooladm.conf :

   # pooladm -c

5. (Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:

   # pooladm -s /tmp/backup

So richten Sie Konfigurationseinschränkungen ein

Einschränkungen reduzieren die Anzahl möglicher Konfigurationen, indem sie einige potentielle Änderungen eliminieren, die an einer Konfiguration vorgenommen werden können. Im folgenden Verfahren wird gezeigt, wie Sie die Eigenschaft cpu.pinned einrichten.

In den folgenden Beispielen ist cpuid eine ganze Zahl.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Ändern Sie die Eigenschaft cpu.pinned in der statischen oder dynamischen Konfiguration:

   • Ändern Sie die Boot-Konfiguration (die statische Konfiguration) :

     # poolcfg -c 'modify cpu <cpuid> (boolean cpu.pinned = true)'

   • Ändern Sie die laufende (dynamische) Konfiguration, ohne die Boot-Konfiguration zu ändern:

     # poolcfg -dc 'modify cpu <cpuid> (boolean cpu.pinned = true)'

So definieren Sie Konfigurationsziele

Sie können Ziele für poold angeben, die beim Durchführen von Korrekturmaßnahmen berücksichtigt werden sollen.

Im folgenden Verfahren ist das Ziel wt-load so gesetzt, dass poold versucht, die Ressourcenzuordnung an die Ressourcenauslastung anzupassen. Das Ziel locality ist deaktiviert, um das Erreichen dieses Konfigurationsziels zu unterstützen.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Ändern Sie das System tester, um das Ziel wt-load zu bevorzugen.

   # poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")'

3. Deaktivieren Sie das Ziel locality für das standardmäßige Prozessorset.

   # poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")'

4. Deaktivieren Sie das Ziel locality für das Prozessorset pset_batch.

   # poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")'

5. Zeigen Sie die bearbeitete Konfiguration an.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true string pset.poold.objectives locality none cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality none cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.

   # pooladm -c

7. (Optional) Um die dynamische Konfiguration in die statische Konfigurationsdatei namens /tmp/backup zu kopieren, geben Sie Folgendes ein:

   # pooladm -s /tmp/backup

So richten Sie die Protokollierungsebene für poold ein

Zum Festlegen der Protokollierungsebene für poold richten Sie die Eigenschaft system.poold.log-level in der poold-Konfiguration ein. Die poold-Konfiguration befindet sich in der libpool-Konfiguration. Weitere Informationen finden Sie unter poold-Protokollierungsinformationen und in den Manpages poolcfg(1M) und libpool(3LIB).

Sie können den Befehl poold auch an der Befehlszeile eingeben, um die Protokollierungsebene für poold festzulegen.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Legen Sie die Protokollierungsebene mit dem Befehl poold und der Option -l sowie einem Parameter, z. B. INFO fest.

   # /usr/lib/pool/poold -l INFO

   Informationen zu den verfügbaren Parametern finden Sie unter poold-Protokollierungsinformationen. Die standardmäßige Protokollierungsebene ist NOTICE.

So verwenden Sie Befehlsdateien mit poolcfg

Der Befehl poolcfg mit der Option -f kann eine Textdatei aufnehmen, die poolcfg-Unterbefehlsargumente für die Option -c enthält. Diese Methode eignet sich insbesondere dann, wenn Sie die durchzuführenden Vorgänge einrichten möchten. Bei der Verarbeitung von mehreren Befehlen wird die Konfiguration nur dann aktualisiert, wenn alle Befehle erfolgreich ausgeführt wurden. Bei großen oder komplexen Konfigurationen ist diese Technik eventuell besser geeignet als das Aufrufen einzelner Unterbefehle.

In Befehlsdateien kennzeichnet das #-Zeichen den Rest der Zeile als Kommentar.

1. Erstellen Sie die Eingabedatei poolcmds.txt.

   $ cat > poolcmds.txt create system tester create pset pset_batch (uint pset.min = 2; uint pset.max = 10) create pool pool_batch associate pool pool_batch (pset pset_batch)

2. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zum Erstellen der Rolle sowie zum Zuweisen einer Rolle zu einem Benutzer finden Sie unter „Managing RBAC (Task Map)“ im System Administration Guide: Security Services.

3. Führen Sie den folgenden Befehl aus:

   # /usr/sbin/poolcfg -f poolcmds.txt

Übertragen von Ressourcen

Geben Sie das Unterbefehlsargument transfer für die Option -c des Befehls poolcfg mit der Option -d ein, um Ressourcen im Kernel zu übertragen. Die Option -d gibt an, dass der Befehl direkt am Kernel ausgeführt wird und keine Eingabe aus einer Datei erhält.

Im folgenden Verfahren werden zwei CPUs aus dem Prozessorset pset1 in das Prozessorset pset2 im Kernel verschoben.

So verschieben Sie CPUs zwischen Prozessorsets

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Verschieben Sie zwei CPUs von pset1 nach pset2.

   Die Unterklauseln from und to können in beliebiger Reihenfolge verwendet werden. Für jeden Befehl wird nur jeweils eine Unterklausel to und from unterstützt.

   # poolcfg -dc 'transfer 2 from pset pset1 to pset2'

Beispiel 13–3 Alternative Methode zum Verschieben von CPUs zwischen Prozessorsets

Wenn bestimmte bekannte IDs eines Ressourcentyps übertragen werden, kann auch eine alternative Syntax verwendet werden. Beispielsweise weist der folgende Befehl die zwei CPUs mit den IDs 0 und 2 dem Prozessorset pset_large zu:

# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)"

Fehlerbehebung

Falls eine Übertragung fehlschlägt, weil nicht genügend Ressourcen verfügbar sind, um die Anforderung zu erfüllen oder die angegebenen IDs nicht gefunden werden können, zeigt das System eine Fehlermeldung an.

Aktivieren und Entfernen von Pool-Konfigurationen

Mit dem Befehl pooladm können Sie eine bestimmte Pool-Konfiguration aktivieren oder die aktuelle aktive Pool-Konfiguration entfernen. Weitere Informationen zu diesem Befehl finden Sie in der Manpage pooladm(1M).

So aktivieren Sie eine Pool-Konfiguration

Zum Aktivieren der Konfiguration in der standardmäßigen Konfigurationsdatei /etc/pooladm.conf geben Sie den Befehl pooladm mit der Option -c für „Konfiguration übernehmen“ ein.”

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Übernehmen Sie die Konfiguration unter /etc/pooladm.conf.

   # pooladm -c

3. (Optional) Kopieren Sie die dynamische Konfiguration in eine statische Konfigurationsdatei, z. B. /tmp/backup.

   # pooladm -s /tmp/backup

So validieren Sie eine Konfiguration vor der Übernahme

Mit der Option -n und der Option -c können Sie prüfen, was bei einer Validierung geschieht. Die Konfiguration wird dabei nicht tatsächlich übernommen.

Der folgende Befehl versucht, die Konfiguration unter /home/admin/newconfig zu validieren. Alle erfassten Fehler werden angezeigt, die Konfiguration selbst wird jedoch nicht modifiziert.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Validieren Sie die Konfiguration, bevor Sie sie übernehmen.

   # pooladm -n -c /home/admin/newconfig

So entfernen Sie eine Pool-Konfiguration

Zum Entfernen der aktuellen, aktiven Konfiguration und Wiederherstellen des Standardzustands aller zugeordneten Ressourcen, z. B. Prozessorsets, geben Sie die Option -x für „Konfiguration entfernen“ ein.”

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Entfernen Sie die aktuelle aktive Konfiguration.

   # pooladm -x

   Mit der Option -x für den Befehl pooladm werden alle benutzerdefinierten Elemente aus der dynamischen Konfiguration entfernt. Alle Ressourcen nehmen wieder den Standardstatus an, und alle Pool-Bindungen werden durch eine Bindung mit dem Standard-Pool ersetzt.

Mischen von Scheduling-Klassen innerhalb eines Prozessorsets

Prozesse in den Klassen TS und IA können im gleichen Prozessorset gemischt werden. Das Mischen anderer Scheduling-Klassen innerhalb eines Prozessorsets kann zu unerwarteten Ergebnissen führen. Wenn der Befehl pooladm -x dazu führt, dass Scheduling-Klassen innerhalb eines Prozessorsets gemischt werden, verwenden Sie den Befehl priocntl ein, um laufende Prozesse in eine andere Scheduling-Klasse zu verschieben. Lesen Sie dazu So verschieben Sie manuelle Prozesse aus der TS-Klasse in die FSS-Klasse. Lesen Sie auch die Manpage priocntl(1).

Einrichten von Pool-Attributen und Binden an einen Pool

Durch Einrichten eines project.pool-Attributs können Sie einen Resource Pool einem Projekt zuordnen.

Sie können einen laufenden Prozess auf zwei Arten an einen Pool binden:

• Verwenden Sie den unter poolbind(1M) beschriebenen Befehl poolbind, um einen bestimmten Prozess an einen benannten Resource Pool zu binden.

• Geben Sie das Attribut project.pool in die project-Datenbank ein, um die Pool-Bindung für eine neue Anmeldesitzung oder eine Aufgabe zu identifizieren, die über den Befehl newtask gestartet wird. Lesen Sie auch die Manpages newtask(1), projmod(1M) und project(4).

So binden Sie Prozesse an einen Pool

Im folgenden Verfahren wird der Befehl poolbind mit der Option -p verwendet, um einen Prozess (in diesem Fall die aktuelle Shell) manuell an einen Pool namens ohare zu binden.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Binden Sie manuell einen Prozess an einen Pool:

   # poolbind -p ohare $$

3. Überprüfen Sie die Pool-Bindung des Prozesses mit dem Befehl poolbind und der Option -q.

   $ poolbind -q $$ 155509 ohare

   Das System zeigt die Prozess-ID und die Pool-Bindung an.

So binden Sie Aufgaben oder Projekte an einen Pool

Zum Binden von Aufgaben oder Projekten an einen Pool verwenden Sie den Befehl poolbind mit der Option -i. Im folgenden Beispiel werden alle Prozesse im Projekt airmiles an den Pool laguardia gebunden.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Binden Sie alle Prozesse im Projekt airmiles an den Pool laguardia.

   # poolbind -i project -p laguardia airmiles

So richten Sie das Attribute project.pool für ein Projekt ein

Mit dem Attribut project.pool können Sie die Prozesse eines Projekts an einen Resource Pool binden.

1. Melden Sie sich als Superuser an oder nehmen Sie eine Rolle an, die das Process Management-Profil beinhaltet.

   Beispielsweise beinhaltet die Rolle des Systemadministrators das Process Management-Profil. Weitere Informationen zu Rollen finden Sie unter Using the Solaris Management Tools With RBAC (Task Map) in System Administration Guide: Basic Administration.

2. Fügen Sie jedem Eintrag in der project-Datenbank das Attribut project.pool hinzu.

   # projmod -a -K project.pool=poolname project

So verwenden Sie project-Attribute zum Binden eines Projekts an einen anderen Pool

Angenommen, Sie haben eine Konfiguration mit zwei Pools, studio und backstage. Die Datei /etc/project enthält Folgendes:

user.paul:1024::::project.pool=studio
user.george:1024::::project.pool=studio
user.ringo:1024::::project.pool=backstage
passes:1027::paul::project.pool=backstage

Bei dieser Konfiguration werden Prozesse, die von dem Benutzer paul gestartet werden, standardmäßig an den Pool studio gebunden.

Der Benutzer paul kann die Pool-Bindung für von ihm gestartete Prozesse ändern. paul kann den Befehl newtask verwenden, um Arbeiten auch an den Pool backstage zu binden, indem sie im Projekt passes gestartet werden.